continuous-delivery

Continuous Delivery

Continuous delivery means every merged change is, by default, in a shippable state — a human decision (or, in continuous deployment, no decision at all) is the only thing standing between a commit and production. The discipline this demands is upstream of the deploy pipeline itself: if main isn't always releasable, "delivery" is a lie and someone will eventually hit "deploy" on a broken build.

Most teams' real bottleneck isn't the deploy mechanics, it's the courage to trust that main is always good enough to ship.

Every commit on the default branch should be deployable at any moment — if it isn't, that's a defect in the pipeline, not a reason to slow down releases.

1. Make "always releasable" a property of main, not a hope

This means trunk-based development or short-lived branches, feature flags for incomplete work instead of long-lived feature branches (see feature-flags), and a CI signal from ci-pipelines that's trusted enough that green means go. If merging to main regularly breaks things, the fix is smaller PRs and better CI coverage, not a slower delivery cadence — slowing down delivery treats the symptom and lets the branch rot further between merges.

• Small, frequent merges beat big, infrequent ones — smaller diffs are easier to verify and easier to revert.
• Incomplete features ship dark behind a flag rather than living on a branch for weeks.
• A red main is a stop-the-line event, fixed or reverted before other work continues.

Done when: any commit on main can be deployed to production without someone first checking "is this actually safe."

2. Automate promotion through environments, gate deliberately

The path from build to production usually passes through named environments (dev, staging, prod) or through automated checks that substitute for them. Each gate should exist because it catches something CI structurally cannot — real infrastructure, real data volumes, a human sign-off for regulatory reasons — not as ceremony inherited from a pre-automation era. An untested manual approval step that always gets rubber-stamped is worse than no gate: it adds latency and gives false confidence that a human is actually checking.