You may recall that in our promotion process, we identified two events within the life cycle that were meant to trigger the pipeline:

• Pull requests
• Tag release

Some may wonder why only these events were specifically chosen. If you recall the process, the developers are expected to manually run tests on their local environment, so there is not an absolute need to trigger the pipeline every time someone delivers code to their own branch. However, when initiating the process of delivering the code to the master branch, it is important to validate that the code can be built, deployed, and tested before accepting changes to the master branch. The same goes with tagging a release—this is an indication that a new version has been cut, and so it makes sense to rerun the pipeline one last time to publish the deployment unit (the smart contract package, in our case).

In any case, this is the guideline we have set for our pipeline, but other teams may choose different approaches. The reader should consider this a guideline and not a definitive approach to continuous delivery.