A typical build may have to clear several hurdles before it can be considered fit for release. For example:
- Unit tests
- Static and dynamic metric thresholds (e.g. toxicity, coverage)
- Packaging
- Integration tests
- UI tests
- Performance tests
- Regression tests
- Deployment tests (install, uninstall, upgrade)
- Manual exploratory tests
- Regulatory, compliance checks
- Clearance from UAT, staging
Each of these hurdles may be viewed as a promotion level for the build (although, in practice, formal promotion levels are more coarse-grained). These promotion levels may be activated automatically (by the success of the previous level) or manually (by approved promoters). Note that these levels are very different from what is encountered in a source promotion model.
Avoid source or stream promotion models
In an earlier post, we said: “Deploy packages, not just a tag, branch or binary”. With respect to promotions, we could say:
“Promote packages, not just a tag, branch/stream or binary”
Promoting at the level of source (rather than package) violates the build-once rule - one of the key principles outlined in the CD book:
“...the binaries you release should be the same binaries that have been through the rest of your deployment pipeline, so you can be sure that what you release is what you tested. Apart from the fact that nobody has tested the binaries that came from the release stream, there is also a chance that differences could be introduced in the build process, perhaps by the operations team using a different minor revision of the compiler or a different version of some dependency. Such differences can lead to bugs in production that take days to track down.”
Because of this, a source/stream promotion model is fundamentally unfit for the world of continuous delivery:
“One of the objectives of the deployment pipeline is to allow frequent check-ins to mainline on large teams which may result in temporary instabilities, while still allowing you to get rock-solid releases out of the door. In this sense, the deployment pipeline is antithetical to the source promotion model. The main advantage of the deployment pipeline lies in the rapid feedback you get on the effect of every change on the fully integrated application—something that is impossible in the source promotion model.”
Use your CI/CD server to manage promotions
Source based promotion models probably made more sense in a pre-CD era when the version control system was the only source of truth for the level of readiness of a codebase. Today, the CD tool is a more appropriate system of record for builds (and deployments) and their promotions. Again, the CD book backs this up:
“The other essential facility that must be provided by the tool you use to manage your deployment pipeline is the ability, for each stage, to see which builds have passed all the previous stages in the pipeline and are hence ready for the next stage. It should then be possible to choose one of these builds and press a button to have it deployed. This process is known as promotion.
Promoting builds at the press of a button is what turns the deployment pipeline into a pull system, giving everybody involved in the delivery process the ability to manage their own work”
Model your promotion process into the CD tool
In general, a build/deployment pipeline is also a promotion pipeline. Go’s support for pipelines and stages with automatic or manual approvals makes it easy to model and visualize your promotion process into the CD value stream. A stage runs only when the previous stage has passed - this is like an automatic promotion gate. Manual stage approvals may also be used where needed.
Modeling promotion levels (P1...P4) itno the CD value stream
Go 13.3
Go 13.3 adds more support by letting you store your packages in a first-class external package repository and yet activating different promotion levels within the tool. We now have three ways of activating a promotion level manually or automatically:
- Stage n activating stage n+1
- Pipeline X activating Pipeline Y (pipeline dependency)
- Pipeline Y getting activated by the updation of a package in a package repository (package material dependency)
There are situations when we could use either #2 or #3 above to model a promotion. The package material docs has a section on this.
Support for package material has been implemented as an extension point. Plugins written to this extension point can provide support for different types of repositories. A yum plugin is bundled along with Go Server 13.3. Other non-bundled package material plugins are listed here.
Happy packaging and promoting!