The deploy you do not think about is the one that pages you

Every team I have joined had a deploy step that someone described as "fine, mostly". It was never fine. "Mostly" is where the outage lives, and the person saying it is usually the only one who knows which parts are the "mostly".

The rot is rarely in the tooling. It is in the knowledge that never got written down: the migration you run by hand first, the service you restart in a particular order, the one environment variable that is different in production for a reason nobody remembers. None of that shows up in a pipeline diagram. All of it shows up at 2am.

So I ask four questions instead of reading the pipeline. First: who deployed last week, and were they the same person as the week before? A deploy only one person performs is not a deploy, it is a ritual. Second: what happens if the deploy fails halfway? If the answer starts with "well, you would have to", write it down — that is your rollback procedure, and right now it lives in one head.

Third: how do you know it worked? Not "did the pipeline go green" — how do you know a customer can do the thing they came to do? A deploy that reports success while the checkout page is throwing is worse than one that fails loudly, because it costs you the hour before someone notices.

Fourth, and this is the one that finds the most: what did we skip to make it fast? Every deploy process has a step someone quietly stopped running. Find it, and you have found next quarter's incident.

None of this requires new infrastructure. It requires writing down what one person knows, which is cheaper than the outage and considerably less exciting.