Paul Hammant's Blog: Examining CI, CD and branching models
This builds on Trunk, CI, Builds, Environments, and Integration from six months ago, and is mostly graphical in an attempt to correlate environment names branching models and CI infrastructure available for automated builds and test runs of various types. Of course, the build isn’t “just compile” anymore, it is all possible scriptable build and functional test steps.
Slower release cadences first, and fastest last.
Traditional CI
Shown here with pull request branches and release branches. Otherwise, trunk (master) is the most important branch. The goal for developers & QA automators aim to get their code integrated (merged) there as quickly as possible, given other constraints.
There’s an older tradition for smaller dev teams where the pull-request branches are not used, and that developers ensure that they don’t break the trunk/master through rigor alone. Locking trunk/master while the “who actually broke it” and what to do about it happens was the early response to bad commits.
Some teams will call this shared dev environment the “Integration env”. Some companies are still allowing developers to deploy to the Integration environment themselves, bypassing the CI infrastructure and segregation of duties. Call me to dig you out of that hole.
Continuous Review
Google pioneered the pull-request model internally (without branches) for their “continuous reviews” in the early 2000’s. Guido van Rossum demoed Mondrian in a recorded tech talk in 2006 that was released on the old Google videos platform in 2007. Rietveld and Gerrit were how Mondrian reached open source land some months after GitHub made it regular for the entire industry with temporary real branches (from the moment they launched in early 2008). As mentioned Mondrian was dealing with patch-sets effectively stored in a database because Perforce did not offer a lightweight branch choice then.
Continuous Delivery into QA
Continuous Delivery into UAT would be exactly the same but with QA replaced with UAT throughout. It’s very rare that team may have a Dev, QA, and UAT environments on the way to production, though they may have multiple QA environments that receive concurrent deployments. Each with a different combination of flag/toggle states (supportable and expected permutations only (ref: Concurrent Development of Consecutive Releases).
Continuous Deployment into Prod
Every commit or small batch of commits results in a deployment into prod, with humans unable to intervene and say “no”. Only if all build steps pass, of course:
Concepts I otherwise skimmed over
- Release Cadences: In a trunk correlated practices chart
- Concurrent Development of Consecutive Releases: see the case study on consulting company site, and As I wrote on the Trunk-Based Development site
- Microcosm Environments: Three articles on my blog
- Continuous Reviews: Nine or so articles on my blog
- Not your grandfather’s “build”: Article on my blog
Reminder
GitFlow isn’t a form of Trunk-Based Development. Contact me if you want a plan to get from there to much better, or because your dev team throughput should be higher. Services offered worldwide :)