Continuous Deployment

Deployment used to be an event. Finished code didn't ship when it was finished; it piled up for a month or a quarter and then someone pushed it to the servers on a scheduled evening. The service often went down during the push, so teams picked the quietest hours of the night, and plenty of them banned Friday releases outright — a bad push on Friday meant losing the weekend to it.

The real cost wasn't the late nights. It was the size of the batch. When a hundred changes ship together, a support ticket the next morning saying checkout is broken doesn't tell you which of the hundred did it. Finding the cause takes a day, and rolling back means pulling the ninety-nine healthy changes down along with the broken one. So teams reviewed longer before each release, longer reviews meant fewer releases, and fewer releases made the batches bigger again.

Pagedeck lived inside that loop. A typo Theo fixed on a Tuesday waited two weeks for the next release window, and during those two weeks it got mixed in with twenty other people's work. Anything urgent went out through a special approval instead, and those one-off pushes caused more incidents than the scheduled ones did, because nobody used that path often enough to be good at it.

Continuous deployment runs the loop backwards. Instead of treating a release as a rare, large event, it makes releases something that happens several times a day, which shrinks each batch down toward a single change. When one change ships, there is only one suspect.

Everything from the moment code merges to the moment it reaches production is wired into one chain that nobody has to push along. Five steps run in order.

1. A developer merges their change into the shared trunk. This is the job of continuous integration (CI). A teammate reads the change in code review before the merge, and that review is the last point where a human touches the path.
2. The pipeline wakes up on its own and runs the build and the tests. A single failure stops it right there — nothing moves to the next stage.
3. What passes goes first to an environment built to resemble production, where a handful of flows that must never break — sign-in, checkout — get clicked through automatically.
4. Then it goes to production. To keep the service up during the swap, teams use something like a rolling deployment, replacing servers a few at a time.
5. For the first few minutes after the release, error rates and response times are watched against a threshold. Cross it and the system triggers a rollback by itself.

One more piece has to be in place: feature flags, switches that let code ship while the feature it powers stays off. With flags, a half-built feature can merge in the dark rather than sitting in a branch accumulating conflicts, and the moment it turns on becomes a product decision rather than an engineering one.

It fits web services — products where the team controls the servers and users pick up the new version on their next visit. Mobile apps that pass through store review do not fit as cleanly, because days of waiting sit past the point where the team's automation ends. Neither do products whose contracts promise customers advance notice of changes, or regulated areas like banking and healthcare where every release needs a signed record. Those teams stop one step earlier at continuous delivery, which keeps a human pressing the final button.

Technically, three things have to exist first.

1. Tests worth trusting. Automated checks now stand in for the review a person used to give, so a few flaky tests — tests that pass and fail on identical code — are enough to teach the team to ignore red builds, and the safety net is gone the moment they do.
2. Visibility into what production is doing. If a jump in the error rate from 0.2 percent to 3 percent takes an hour to notice, automatic deployment is just a faster way to spread a failure.
3. A way back within minutes. A team that automates the path forward and leaves no path backward will switch the pipeline off after its first bad night.

"This goes live as soon as it merges, right? I'll merge it with the flag off."

The merge reaches production immediately, so the feature stays hidden behind a switch.

"We do continuous deployment, so we don't schedule release dates."

There is no release calendar — work ships when it's ready.

"Test coverage isn't there yet, so continuous deployment is off the table."

The automated checks aren't dense enough to replace a person's eyes.

Pagedeck moved this way after Theo's typo sat for two weeks. The team built the rollback path first, then spent two months letting the pipeline run automatically as far as the staging environment, watching whether it actually caught real problems. Only then did they remove the final approval step. Today Grace doesn't ask about release plans in the leadership meeting. She asks Mia when a particular flag is getting turned on. Once shipping code and exposing a feature became separate events, the thing the executives track moved from deployment to timing.

The most common misreading is that this means shipping without checks. Looking only at the missing approval, that's an easy conclusion to draw. The opposite is true: because a machine now has to do every time what a person used to do once at the end, teams running continuous deployment invest more in testing and monitoring than teams that don't. Adopt it with this misunderstanding and you get the automation turned on while the checks stay where they were — which is the same as removing the last gate that used to catch mistakes.

The other worry is that taking humans out of the loop makes releases riskier. Approval feels like protection. But what an approver actually reads is a list of changes rather than the code itself, and the larger the batch, the more that reading becomes a formality. Ship one change and there is exactly one thing to undo. Keep the approval step because of this worry and the gap between releases widens again — and as the batches grow, so does the risk the step was meant to contain.