The pipeline is the product
Most engineering organizations underrate how much their delivery pipeline shapes the work that gets done. Slow pipelines produce big, batched, risky deployments. Fast pipelines produce small, boring, frequent ones — and the team's behavior follows.
When we set up CI/CD for a client, the goal is for the pipeline to disappear into the background.
What we put in place
- Trunk-based development with short-lived branches and automated checks per commit
- Signed artifacts so what runs in production is provably what was reviewed
- Ephemeral preview environments for every pull request, torn down on merge
- One-command rollback — usually a deployment record flip, not a re-deploy
- Deployment metrics on the same dashboard as product metrics
The metrics we care about
Frequency, lead time, change failure rate, mean time to recovery. The DORA four are not novel, but very few teams measure them honestly. We instrument them on day one and watch them move.
What a good CI/CD month looks like
Twenty to a hundred deployments per service. Most of them noticed only because a flag flipped. The team spending its energy on the work, not on shipping the work.
A pipeline you have to think about is a pipeline that is still under construction.