What It Actually Means
That sounds procedural and it is one of the more revealing things about how a system is built, because deployment is where all the assumptions get tested at once.
The Question Worth Asking
How long does it take to get a one-line fix live, and how nervous is everybody?
The answer sorts teams quickly.
A well-built setup deploys in minutes, automatically, several times a week, on an ordinary Tuesday afternoon, and nobody thinks about it. A struggling one deploys on Thursday evenings, by hand, following a checklist, with everyone available in case something breaks.
The second is not caused by carelessness. It is usually the accumulated result of manual steps nobody had time to automate, and it has a compounding cost: because deploying is frightening, it is done rarely; because it is done rarely, each release contains more changes; because each release contains more changes, failures are more likely and harder to diagnose; which makes it more frightening.
Teams get stuck in that loop for years, and the fix is to deploy more often, which is the opposite of what instinct suggests.
Why Frequency Improves Safety
Small, frequent deployments are safer than large, rare ones, and it is worth understanding why because it seems backwards.
A release containing one change that breaks something tells you immediately what broke it. A release containing sixty changes tells you only that something in those sixty is wrong. The investigation is the expensive part, and it scales with batch size.
Frequent deployment also means the process is exercised constantly, so problems in the process surface on an ordinary day rather than during the one release that mattered.
What Should Be In Place
Automation. The same steps, in the same order, every time. Manual deployment is a checklist somebody eventually performs at eleven at night having missed a line.
A rehearsal. Changes go somewhere resembling production first. That is what a staging environment is for.
A way back. Reverting should be quick and practised. Knowing you can undo it in two minutes changes how a release feels.
Nothing that requires downtime for routine changes. Ordinary work should not need a maintenance window.
Someone watching afterwards. Errors and traffic checked for a while after, so a problem is found by you rather than reported by a customer.
What To Ask
- How often do we deploy, and how long does one take? Weekly and minutes is healthy. Monthly and evenings is a warning.
- Can we roll back, and when did we last do it? Practised, not theoretical.
- Does deploying require downtime? For routine changes it should not.
- Who can deploy? If it is one person, that is a continuity risk with a name.
Why This Is Your Business
It is tempting to treat deployment as internal plumbing, and it directly governs two things you care about.
How fast you can respond. A competitor’s change, a broken checkout, a regulatory deadline. If a small fix takes a week to reach customers, your ability to react is capped by the release process rather than by the work.
How much of what you pay for reaches you. Time spent on careful manual releases and on diagnosing large-batch failures is time not spent building anything, and it is invisible on an invoice. Teams with painful deployment spend a substantial share of their capacity on the act of shipping rather than on the thing shipped.
More terms are in the glossary.
