Pipeline

Deployment used to be a hand skill. There was a document with the steps in it, and a person worked down its twenty lines running one command at a time. Having the document looks like enough, until you skip one of the twenty lines and nothing tells you that you did. The document describes the happy path; it doesn't check anything.

So incidents kept arriving in the same shape. A Friday afternoon deploy goes out with one configuration value left at its old setting, and payments stop for thirty minutes. Finding the cause takes twenty minutes, and asking what was done in what order gets you an answer from memory. The record lived only in somebody's head.

Deployment also stayed locked to one or two people. Only someone who knew the tricks that never made it into the document could get to the end, so during that person's vacation nothing shipped. A pipeline transcribes the order into a file a machine reads, so the machine repeats what a person used to do, in the same sequence every time.

Work done in sequence by hand gets run in the same sequence by a machine. Five stages is the common shape.

1. Fetch the code. It starts from which branch received which change, and the exact commit ends up in the record.
2. Turn it into something runnable. Converting source into a result is the build, and the deployable output is an artifact. One artifact made here is what every later stage uses. Rebuild at each stage and the same code can produce different outputs.
3. Run the checks. Automated tests and code-rule checks live here, and a failure halts the flow rather than passing it along. That halt is half of what a pipeline actually does. A flow that never blocks anything is a deploy script with extra steps.
4. Put it on an environment. Separate execution spaces with different purposes — development, staging, production — are environments, and the usual route is staging first, then production. Values that differ per environment get injected as environment variables, and the ones that must not leak, like keys and passwords, go into secret management instead.
5. Verify after the fact. Watch responses for a few minutes and roll back to the previous version if they look wrong. Automating the rollback matters more than automating the deploy, because a rollback happens when everyone involved is already flustered.

Four things come out of it. The order is identical every time; who shipped what and when is recorded; nothing depends on undocumented tricks, so anyone can deploy; and when something fails, the screen says which stage it stopped at.

The price is time. Building the first one takes days, and the larger cost is how long a single run takes. Past ten minutes people start deferring merges, and deferred changes pile up until they land together — bringing back exactly the risk the pipeline was meant to remove.

There are three, and they differ in how far the automation goes.

The first is a deploy script bundled behind one command. The twenty-line document becomes a file and a person runs the file. Skipped steps stop happening and it takes an afternoon to write. What remains unsolved is the record and the access: nothing logs who ran it when, and whoever holds the keys on their laptop becomes the only person who can, which is the single point of failure it was supposed to remove.

The second is handing it to a platform. Services that rent out a development and deployment environment attach a default flow the moment a repository gets connected. There's nothing to build, which is fast, but inserting your own checks between stages is hard, and stepping outside the prescribed way hits a wall.

The third is cutting stages. Drop the checks, keep build and deploy, and a run takes three minutes. There genuinely is a range where this is right — on an early product with no users, fixing what breaks costs less than preventing it. Leave it that way after users arrive, though, and the seven minutes saved by skipping checks disappears in a single outage.

On a team deploying once a month with two people building, the first option is often enough. Writing and tending a pipeline still costs more than it returns in that range. The threshold is usually the point where a third person starts needing to deploy.

"The pipeline stopped at stage three. Two tests broke."

Where it stopped is already identified, so only that spot needs looking at.

"A run takes eighteen minutes. People have started deferring merges."

The flow is slow enough that its purpose is breaking down.

"It reaches staging automatically, but production needs manual approval."

Only the last step is a human pressing a button.

Pagedeck runs the pipeline Theo built: five stages, seven minutes a run. Deploying used to be something only Theo could do; now merging code carries it to staging automatically, and the button that promotes to production is one anyone can press.

The run time once grew to twenty-two minutes. Mia checked when people were merging and found everything bunched into the afternoon — merging in the morning meant waiting out the morning, so they put it off. Theo split the tests into two groups, ran only the fast group on merge, and got it back to eight minutes. Nobody had asked for a faster pipeline; the merge timing was the only visible symptom.

The most common reading is that having a pipeline makes deployment safe. It checks automatically and ships automatically, so there appears to be no room for human error. But what the flow guarantees is that the order is the same; what gets checked is whatever a person wrote down. A pipeline with three tests verifies three things and then shows green. Green means the checks that exist passed, and nothing beyond that. Teams that start reading green as safe stop opening the product after a deploy, and learn about outages from support tickets.

The other frequent view is that more stages are better. More checks catch more problems, which is true as arithmetic. What the arithmetic leaves out is time. Grow to ten stages and forty minutes, and people start something else while it runs and see the failure notification two hours later — by which point three more changes are stacked on top and the cause has to be hunted down again. Splitting checks into fast and slow, running only the fast ones on merge and batching the slow ones overnight, is usually the better shape.