There are a few ways and techniques that can be applied to ensure that every organization is notified that a business network is ready to be updated.

The one thing that is for certain is that manual notification is not an option; as the number of smart contracts and participants grows, you need a reliable notification process.

The following diagram depicts a potential process for deploying a business network following the delivery of a new release:

As we've previously discussed, we do not distribute the BNA as this would create the opportunity for someone to tamper with the archive. Instead, the notification only informs every organization of the existence of a new release and lets the consortium retrieve and deploy the archive.

This is effectively what the concept of the release listener is doing: listening for notification and then issuing a request to GitHub to retrieve the archive of the new release.

The release listener could be implemented to listen for events coming from one of two sources:

• GitHub webhooks: By providing the URL of the release listener, GitHub webhooks can be configured to send a JSON message on specific events. In our case, it would be the Release event.
• Travis CI notification: There is also a concept similar to the webhook in Travis CI. There are also other mechanism, such as Atom feed and Slack integration, that may be more suitable to your team.

The choice of the mechanism really depends on your business requirements but, generally, the use of GitHub webhooks would be preferable as they are triggered by the actual event we are interested in: the release of a new version of the smart contract.