Every consulting engagement I have run ends the same way: someone closes the laptop and says, “okay, but the thing I never understood is\u2014” and asks the question the whole room was avoiding. The questions are remarkably consistent across companies, which suggests they are structural rather than personal. They are also, almost always, ReleaseOps questions \u2014 about the strategy layer that decides when installed software becomes behaviour users can see. Here are the six that return every quarter, with the replies as I give them in the room \u2014 stories and arithmetic included.<\/p>\n
A team lead asked me this over coffee, certain the answer was obviously yes. It is obviously no, and the distinction rearranges everything after it. Deploying installs a version on machines. Releasing exposes what that version does to people. A team that fuses the two \u2014 and most do, without noticing \u2014 has chained installation, exposure and announcement into a single all-or-nothing gesture. Untangle them and the gestures separate, giving the team two controls that move on their own schedules, and announcements stop being hostage events:<\/p>\n
The engineer who asked the coffee question The engineer who asked the coffee question shipped her next feature dark, on a flag, two weeks before the marketing email went out \u2014 and told me later it was the calmest launch of her career.<\/p>\n
Long enough to gather evidence, which turns out to be a computable sentence. Suppose you fear the new version doubling your error share \u2014 say from two bad responses per thousand to four. You want the trial to catch eight of every ten such doublings while crying wolf no more than five times in a hundred. On a service serving fifty requests a second, the trial needs to push roughly four thousand requests through the new code. Hold the canary at one percent of traffic and you are waiting on the far side of two hours; grant it a tenth of the traffic and the same evidence lands in about a quarter of an hour. Duration is not a preference. It is a consequence of traffic share, sample size and how subtle the feared defect is. Teams that “run canaries” for symbolic ten-minute windows on quiet services are not running experiments; they are running rituals.<\/p>\n
The best teams answer in one line: whoever holds the pager holds the brake. On-call always retains the right to abort \u2014 at 3 a.m., without convening a meeting, without worrying about the feature owner’s feelings. The uncomfortable corollary is about merge permissions rather than pagers: where the pipeline deploys automatically on a tagged commit, anyone carrying merge rights into the main branch is holding the release pen, whether or not their badge says so. Organisations that map this authority honestly \u2014 who can install, who can expose, who can reverse \u2014 stop being surprised by their own launches. Those that leave it implicit learn it during incidents, at the usual tuition rates.<\/p>\n
This question divides rooms until the research is read. DORA’s programme examined whether external change approval boards reduce change-failure risk and found no supporting evidence. What does associate with safer change: peer review, and evidence about the modification collected automatically by the pipeline. The reason is not ideological; boards sit far from the work, so their judgement arrives late and blunt. Governance itself is fine \u2014 the working pattern is gates whose effect is explicit, able to block, pause or record, with exceptions that carry a person’s name and an expiry date. A permanent override is just policy decay with a signature.<\/p>\n
There is a price dimension too, which the debate usually skips. A board that adds days of queue time per change taxes every launch \u2014 including the trivial ones \u2014 and pushes engineers toward batching, which quietly raises the blast radius of each batch. Peer review plus automated evidence taxes each change minutes instead of days, and applies the scrutiny in proportion to risk. Same protective intent, radically different carrying cost.<\/p>\n
More kinds than most teams have words for, which is why freeze announcements cause such confusion. The classic code freeze \u2014 halting code changes ahead of a release \u2014 is the one delivery research advises avoiding, because it batches risk instead of reducing it. A change freeze scopes the halt to a class of modifications. Time-window blockers protect specific hours, retail weekends and financial quarter-ends being the usual suspects. And the error-budget freeze is the self-inflicted kind: when a service has spent its allowance of unreliability, ordinary change stops automatically and only critical fixes move \u2014 Google’s published example halts everything except P0 and security patches. Naming which freeze you mean, in writing, ends most of the arguments.<\/p>\n
One warning from experience: the freeze discussion is where gatekeepers hide. A team I advised had a standing “stability window” that had quietly run for eleven months, blocking all change while a queue of fixes aged behind it. Nobody had decided to keep it; nobody had decided to end it either. The moment each halt type was written down with an owner and a sunset clause, the queue drained in three weeks and nothing broke. Freezes are tools with handles \u2014 the harm comes from handles nobody is holding.<\/p>\n
Not with tooling. The sequence that has worked for every small team I have watched: spend the first month writing a one-page release policy and opening a flag registry where every switch has an owner and an end date. Spend the second month shipping one service completely dark and rehearsing the rollback for real, stopwatch running. Spend the third putting automated canary analysis on three services and letting the numbers decide widening speed. That is thirty, sixty, ninety days, and by the end the vocabulary in the first question above will sound like your team’s native language. Helpful companions on the road: the piece on how DevSecOps transforms release safety<\/a> covers the security stitches, this essay on DevOps bridging development and operations<\/a> supplies the cultural chassis, and the walkthrough of building a dependable CI\/CD pipeline<\/a> is where the automation evidence in the boards question actually lives.<\/p>\n