Continuous Delivery

There was a long stretch where shipping happened once a quarter and counted as an event. Three months of accumulated changes went out on a Friday night, and the team stayed reachable through the weekend.

When something broke, nobody could find the cause. With 300 changes released at once, isolating the one that broke a screen took a full day on its own. Rolling back to the previous version would have erased the 299 healthy changes along with it, so teams usually patched in a hurry instead. The hurried patch produced a different problem in the next release, and by the third quarter nobody could say which of the last four releases a given bug had come from.

That creates a loop. The rarer the releases, the more goes out at once; the more that goes out, the riskier it gets; and the risk argues for releasing even less often. Continuous delivery exists to run that loop backwards. Turn shipping from an event that requires preparation into an ordinary state that's always available, and the batch size falls — and a smaller batch is a smaller risk.

The procedure is fixed at five steps. Everything from the moment code merges to the moment it could ship belongs to machines, and the five steps exist to shrink the human part down to a single action at the end.

1. Merge often. Continuous integration (CI) — merging everyone's changes into the shared branch at least daily — is the prerequisite. Keep a branch alive for two weeks and merge day produces a pile of conflicts, which means the shared branch isn't shippable for days afterward. Trunk-based development is that prerequisite written down as a rule.
2. Let a machine check every merge. A pipeline chains build and test in order, and a failing step stops there instead of passing anything downstream. Broken code is filtered out here, minutes after it was written, while the person who wrote it still remembers what they were doing.
3. Build the output once. The artifact that comes out of the build is the same one used for testing and for production. Rebuilding per environment risks shipping something other than what passed the checks, and that gap is invisible until production behaves differently from staging.
4. Promote it to an environment that resembles production. Staging gets a quick confirmation that the core paths are alive, and anything caught there never reaches a customer.
5. Leave it standing, ready to go. That's where the machine's part ends. A person decides only the moment. Everything that could have been decided earlier already was, which is why the decision on the day is small enough to make in a sentence.

Holding that procedure together takes one more condition: unfinished work sitting in the shared branch must not block a release. So half-built features ship turned off behind a feature flag — the code is in production, invisible to users. Without that device, a single unfinished feature blocks releases for weeks and the whole procedure stalls. Separating the flag from the deploy also separates the moment something ships from the moment anyone sees it.

It fits teams that have a real reason to control the timing of a release. The structure keeps the preparation continuous and deliberately leaves the final judgment to a person.

• Enterprise customers who must be told about changes in advance. If the contract specifies a notice period, automatic releases are not an option.
• Launches tied to a marketing or sales calendar. The feature can be ready two weeks early and still get switched on the day of the announcement.
• Domains that require an approval record. Regulations demanding a trace of who shipped what and when land here.

The limits are just as clear.

1. It only holds up if the automated checks are trustworthy. Weak tests make "we could ship any time" untrue, and the team quietly reintroduces a manual verification pass before every release.
2. Without pressing the button, almost none of the benefit arrives. Preparation finishing daily while releases happen quarterly leaves the batch size exactly where it was. Before claiming to have adopted this, look at actual release frequency rather than at the pipeline diagram.
3. Changes that are hard to undo still take hands. A database schema change doesn't reverse with a simple rollback, so it gets split into releases that let the old and new shapes run side by side for a while.

"Let's take this to continuous delivery and press for production once the notice goes out."

Finish the preparation now, but time the actual release to the customer announcement.

"Is what's on main right now in a shippable state?"

Checking whether the procedure is genuinely being followed.

"The feature is done — we shipped it behind a flag, turned off."

The code is already in production and only needs switching on.

At Pagedeck this became the default as enterprise customers grew. Changes used to go out as soon as they were ready, and then a contract clause appeared requiring five business days of notice before a screen changed.

Theo reshaped the pipeline so staging is automatic and production waits on a button. Sofia runs the notice schedule and picks the date. Mia checks every cycle how many unreleased features are piling up behind flags, because a large pile means the preparation is done and nothing has reached a user. Work sitting behind a flag for two months is work the company has paid for and not yet sold.

The most common misreading is treating "could ship any time" as "ships often." The two sentences sound alike, and teams that adopt this usually do end up releasing more often, which reinforces the confusion. But what the method guarantees is a state, not a frequency. Finish preparation daily and press the button once a quarter, and the batch going out is as large as it ever was, with the same trouble finding the culprit when something breaks. Left uncorrected, this belief leaves a team with all the tooling and none of the payoff, usually defended by pointing at the pipeline rather than at the release log.

The other one is treating installed tools as a finished adoption. Stand up a pipeline, wire automatic staging deploys, and the outward shape is there. But if branches live for two weeks and the shared branch isn't shippable during them, the procedure isn't running. The way to check is to pick an arbitrary moment and ask whether what's on main could go out right now.