With these concepts defined, let's turn our attention to the promotion process of our application. As we are using Git as our software configuration management tool, we will leverage its social coding features to support our promotion process:

• We can use Git issues to record new features or bug fixes
• We can use Git branches to isolate proposed modifications
• Git GPG is used to sign every commit and tag
• Pull requests are used to enforce governance

The following diagram summarizes the process we will use to configure our application:

We will now go through the process in detail and focus on the issue of trust and the provenance of the code. As we've been discussing, since smart contracts are at the heart of blockchain networks, we need to ensure that we closely track their evolution to avoid unfortunate events. From that perspective, we will want to have traceability from the requirements (Git issues) all the way to the deployment.

As such, every code modification should start with the creation of a Git issue. It should properly identify what its scope is—feature request or bug fix—and then describe precisely what work is expected.

We will cover the governance aspect in a few chapters, but for now we can assume that the issue will have been prioritized and work will be assigned according to the consortium's priority.

Once the developer is assigned to work on the issue, his first step will be to create a temporary Git branch to track all code changes related to this Git issue. Code modification should never be done on the master branch as it represents the stable version of the code, and new features and bug fixes should be reviewed before their integration into the stable stream.

It is expected that developers will run all the appropriate tests within their own local environments and only commit back to the branch when code is ready and all unit tests complete successfully.

When the time comes to commit the changes, Git provides a feature that allows you to sign all your work using GPG. What is GPG, you ask? It stands for GNU Privacy Guard, and it is an open implementation of the openpgp standard. It basically provides a tool that helps you sign and encrypt data using your own private key. Git has implemented GPG to allow developers to sign their work. Each commit or tag can be signed using the GPG key of the author, thereby providing nonrepudiation of commits.

Why sign code modification using GPG? Some may say this is an overhead, but consider that the code being modified represents a legal contract and is at the root of the trust of the network. From this point of view, it might be desirable to ensure that the identity of authors is proven beyond a doubt.

Using single-factor authentication for normal commits may not be sufficient to prove their authorship; consider all the reports on the internet of people spoofing the identities of others.

Without signed commits, we can imagine a situation where a rogue developer modifies a smart contract for their own benefit and gets away by claiming they were not the real author of the code change. Such an event would jeopardize the viability of the network and far outweigh the inconvenience of signing commits.

Now that the developer has signed the commits, they are ready to submit a pull request. The pull request has been configured to check the following criteria:

• The temporary branch is up to date with the content from the master
• Every commit is signed
• The code owners have reviewed and accepted the code changes
• The continuous integration pipeline has successfully completed

The pipeline will be automatically triggered when the pull request is created. Once all the conditions are met, then one of the code owners may merge the code with the master branch and commit those changes (while signing the commit, of course).

In a real-life scenario, the consortium would have additional environments (user acceptance environment, staging environment, and so on) where the complete solution stack would be tested.

The final step described in the diagram focuses on tagging the release. The idea here is that a single release may be built from a series of multiple pull requests. When the consortium is ready to release a new version, it should tag it to represent the official version being deployed.

It is on this event that the pipeline will be triggered again, but with a different objective: build, test, sign, and publish the smart contract to an artifact repository. This artifact repository could be one of many popular solutions out there, but in our case, for simplicity's sake, we will attach the smart contract to a Git release.

Some of you may wonder why we are not deploying directly on the network. Again, the intent is to maintain a clear delineation between the centralized build process and the decentralized nature of the network. Each organization can be notified of the new smart contract to deploy, pull the archive, validate against the signature, and deploy it.

In summary, here are a few points on the promotion process:

• Every code change is tied to a change request
• Developers sign their modification using GPG
• Master branch integrity is preserved by the pull request process
• The pipeline builds and tests the code for pull requests
• The pipeline publishes the smart contract to the artifact repository when changes are tagged
• Each organization receives a notification when a new version is available

In the next section, we will start configuring the continuous integration pipeline we have just defined.