From constantly broken production to constantly late releases to release trains to continuous delivery

Deploy and fix → constantly broken production

“F**k It, Ship It” (lifehacker.com)

Individuals and teams unilaterally release to production and constantly break things. This is not a historical oddity; it still happens.

Strict deployment controls and change management → constantly late releases

Introducing strict deployment controls and change management limits how many changes are broken simultaneously but inevitably leads to constantly late releases

In response to constantly broken production, many organisations try to compensate by introducing strict production deployment controls and change management. This doesn’t necessarily improve the quality of each production release but it at least slows down how many things are broken at the same time. This almost inevitably leads to constantly late releases.

Release trains → learn discipline and decoupling (if done correctly)

Spotify Engineering Culture (part 1) — Crisp’s Blog

With a release train, “All releases happen on a fixed and reliable schedule regardless of whether all expected features are ready (the train doesn’t wait for you — if you miss it you wait for the next one).”

The purpose of a release train is to encourage the discipline required to safely release more frequently, which includes automated testing practices and appropriate decoupling of the technology and product capabilities. A common mistake when implementing release trains is to overly emphasise centralised coordination instead of addressing issues with quality and decoupling.

Continuous delivery/deployment → safely release on-demand

Continuous Delivery vs Continuous Deployment — Crisp’s Blog

With sufficient quality discipline and decoupling, releases can safely happen on-demand without any coordinated schedule.