Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Continuous Delivery

Pattern

A reusable solution you can apply to your work.

Also known as: CD

Understand This First

Context

This is an operational pattern that builds on Continuous Integration and changes the relationship between development and release. Continuous delivery means keeping your software in a state where it could be released to production at any time. Every commit that passes CI is a release candidate. The decision to release is a business decision, not a technical hurdle.

This is different from Continuous Deployment, which goes one step further by releasing automatically. Continuous delivery gives you the capability to release on demand; continuous deployment exercises that capability on every commit.

In agentic coding, continuous delivery means that the rapid pace of agent-generated changes can flow to production as fast as the team is comfortable, without waiting for a scheduled release window.

Problem

Your team can merge and test code continuously, but releasing to production is still a manual, infrequent, stressful event. Releases happen monthly or quarterly, bundling dozens of changes together. Each release is large, risky, and hard to debug when something goes wrong. How do you make releasing software a routine, low-risk activity rather than a scheduled ceremony?

Forces

  • Large, infrequent releases are risky because they contain many changes, making it hard to identify which change caused a problem.
  • Business stakeholders want control over when features ship, which seems to require batching.
  • Keeping software always releasable requires discipline in testing, configuration, and feature management.
  • The deployment pipeline itself must be robust and well-tested to support release on demand.

Solution

Build a deployment pipeline that can take any passing commit from the main branch and deploy it to production with a single action. This means automating everything between “code passes tests” and “code runs in production”: building artifacts, running integration tests, deploying to staging, running smoke tests, and deploying to production.

The pipeline should be fully automated up to the point of the production deployment decision. That final decision — “yes, ship it” — can be a manual approval (a button click, a merged PR, or an approved release) or it can be automated, at which point you have Continuous Deployment.

To keep software always releasable, use Feature Flags to decouple deployment from feature exposure. Code for an unfinished feature can be deployed to production as long as the feature flag keeps it hidden from users. This eliminates the need for long-lived feature branches and the merge pain they cause.

When working with an agent, continuous delivery means you can ship the agent’s improvements as soon as they pass the pipeline. You don’t have to batch them with other work or wait for a release window.

How It Plays Out

A team practicing continuous delivery deploys to production two or three times per week. Each deployment contains one to three changes. When a bug appears, the team knows it was introduced in the last day or two, in one of a handful of commits. Finding and fixing it takes hours instead of days.

A company has a contractual obligation to deliver a feature by a specific date. With continuous delivery, the feature is developed behind a feature flag, deployed to production incrementally over two weeks, tested in production by internal users, and then exposed to the customer on the agreed date by flipping the flag. The release day is uneventful.

Note

Continuous delivery does not mean you have to deploy every commit. It means you can deploy any commit. The difference is between “we deploy when we choose to” and “we deploy when we are finally ready to.” The former is a position of strength; the latter is a position of anxiety.

Example Prompt

“Set up a GitHub Actions workflow that runs tests and builds the app on every push to main. If all checks pass, deploy to the staging environment automatically. Production deploys should wait for manual approval.”

Consequences

Continuous delivery makes releases routine and low-risk. Small, frequent deployments are easier to understand, test, and roll back. Teams get faster feedback from real users. Business stakeholders gain the flexibility to release when the timing is right rather than when the code is finally stable enough.

The cost is significant investment in automation, testing, and pipeline infrastructure. The team must maintain the discipline of keeping the main branch always releasable, which means no broken tests, no half-finished features without flags, and no “we’ll fix it before the release” shortcuts. The pipeline itself becomes critical infrastructure that must be monitored and maintained.

  • Depends on: Continuous Integration — CI is the foundation that validates every commit.
  • Depends on: Deployment — the deployment pipeline must be fully automated.
  • Enables: Continuous Deployment — removing the manual release decision.
  • Uses: Feature Flag — flags decouple deployment from feature exposure.
  • Enables: Rollback — frequent small deployments make rollbacks simpler and lower-risk.