Part 3. Part 1 was trunk-based development. Part 2 was continuous integration. Trunk-based development and CI enable Continuous Delivery.
What it is
Continuous Delivery means the head of master/main is always kept in a deployable state. The functionality is releasable to users, on demand, whenever the business decides.
Release is a business decision. The code is always ready to go. The question is whether you want to release it now.
On "CD won't work here." Every organisation thinks it is special. There are special rules and regulations that mean CD is not possible at their particular company. Despite evidence to the contrary from the research output from DORA data across thousands of organisations, including regulated industries, government, and finance. The rules blocking CD may or may not really exist, but they are rarely examined closely enough to find out.
How to actually do it
CD is the result of everything before it working together:
- Trunk-based development - everyone commits to trunk, decoupling strategies keep incomplete work hidden
- Continuous integration - every commit is verified by a fast automated build and test suite
- Automated deployment - deploying is a scripted, repeatable, non-event
- Monitoring and rollback - you can detect problems quickly and recover quickly
When any of these are missing, teams batch up changes, deploy infrequently, and accumulate risk.
Deploy and release are separate
Deploy: the code made it through to production.
Release: users are experiencing the change.
These are two different events. The gap between them should be a deliberate business decision, not an accident or a "big bang" release. When it is, risk accumulates.
You can deploy many times before releasing. Each deploy is a technical (non) event. Code moves to production, behind a feature flag or dark launch. Release is the human decision to make the change visible to users.
"Done" means released to end users. Not the dev environment, or done but "waiting for QA".
Tracking it with Mainline
The world's premier upcoming project management tool for teams that don't suck and are really good looking, Mainline, separates deploy and release as distinct events in a story's lifecycle.
- Deploy events are recorded via webhook from your pipeline. Automated, system-level, no human action needed. The deploy count on each story shows how many times code has been pushed to production.
- Release is a human decision. Someone on the team marks the story as released when users are experiencing the change.
- Inventory shows the gap - stories that have been deployed but not released. In Flight (0-3 days) is normal. Aging (4+ days) is worth noticing. Stale means a decision hasn't been made.
The goal is that nothing sits in inventory by accident. Every unreleased story should be a conscious decision, not a forgotten deploy.
The progression
Trunk-based development enables continuous integration. Continuous integration enables continuous delivery. Each practice builds on the last.
The practices are a chain, and the weakest link determines what is actually possible. A team developing on feature branches has a ceiling regardless of what else it does well.
This is part of the Mainline documentation. Mainline is a project management tool for teams that ship continuously.
