DevOps: Shortening the Distance Between Merge and Live

DevOps has been defined into meaninglessness — a culture, a job title, a set of tools, a department some organisations created while changing nothing about how work flows.

The useful definition is narrow: reducing the time and risk between someone finishing a change and customers benefiting from it. Everything worthwhile follows from that.

The four measures#

There is broad agreement on four metrics that indicate whether delivery is healthy. They are worth knowing because they are hard to game and they expose trade-offs.

The counter-intuitive finding, repeated across years of industry research: teams that deploy more often typically have lower failure rates. Small frequent changes are easier to test, easier to diagnose, and easier to reverse than large infrequent ones.

If you measure nothing else, measure these. They tell you where to work — a team with a low failure rate and a two-week lead time has a different problem from one that ships hourly and breaks constantly.

The practices that move them#

Version control for everything, including infrastructure and configuration. Anything that exists only because someone typed it once cannot be reproduced after a failure.

Automated build and test on every change. If verifying a change requires a person to remember a sequence, it will eventually be skipped under deadline pressure.

Small changes, merged often. A branch alive for three weeks is a merge conflict and a debugging problem waiting to happen. This does more for reliability than most tooling.

One artefact, promoted through environments. Build once, deploy the same thing to test then production. Rebuilding per environment means you tested something other than what you shipped.

Configuration separate from code. Same artefact, different settings. Secrets from a secret store, never the repository.

Automated deployment, with a tested rollback. The rollback is the part people skip, and it is the part that determines how long an incident lasts.

Monitoring that answers "is it working?" Not just CPU graphs — is the business function succeeding? Are orders completing?

Notice how little of this is about specific tools. Most of it is discipline that a small team can adopt with what they already have.

Where organisations get stuck#

Buying a platform instead of changing how work flows. A sophisticated pipeline in front of a process requiring three sign-offs and a monthly release window changes nothing. The constraint is the process.

A "DevOps team" that becomes a new silo. If one group deploys on behalf of everyone, you have recreated the wall you were removing, with better tooling.

Automating a broken process. Automation makes a bad process faster and more consistent, not better. Fix the sequence first.

Environments that differ from production. "Worked in test" is nearly always this. If test has different data volumes, versions or configuration, it tests a different system.

Manual steps nobody documented. The deployment that only one person can do is an availability risk with a name attached.

Deploying without downtime#

The techniques are less exotic than they sound:

Rolling — replace instances gradually. Simple, and the default for most container platforms.

Blue-green — run the new version alongside the old, switch traffic, keep the old one warm. Rollback is switching back, which is the fastest rollback there is. Costs double resource during release.

Canary — send a small share of traffic to the new version, watch the error rate, then widen. Best when you can measure quality quickly.

Feature flags — deploy code disabled, turn it on separately. This decouples deploying from releasing, which is the single most useful idea in this list. It means a bad feature is switched off in seconds without a deployment.

For databases, the rule that avoids most pain: make schema changes backward-compatible. Add columns before using them, remove them a release later. Then any version can run against any adjacent schema, and rollback stays possible.

What to build first#

If you are starting from a manual process, in this order:

1. Everything in version control, including config
2. A build that runs on every change and fails visibly
3. A deployment script — even a simple one — so it is repeatable
4. A tested rollback
5. Monitoring for the business function, plus an alert that reaches a person
6. Then measure the four metrics and work on whichever is worst

Each step is useful on its own. That matters, because platform projects that only pay off at the end tend not to reach the end.

FAQ#

Is DevOps a role or a practice?#

A practice. The title exists and is usually an engineer specialising in delivery infrastructure — which is fine, as long as they build capability the whole team uses rather than becoming the person everyone queues behind.

Do we need Kubernetes for DevOps?#

No. These are unrelated. Excellent delivery is achievable with virtual machines and a deployment script; a Kubernetes cluster with a manual release process is not DevOps. See our Kubernetes guide for whether you need it at all.

How often should we deploy?#

More often than you currently do, almost certainly. Weekly is a reasonable target for most teams starting from monthly. The goal is not frequency for its own sake — it is that small changes are safer, and frequency is what makes changes small.

What if our industry is regulated?#

Regulated industries often deploy more frequently, because automated pipelines produce better evidence than manual processes: every change is logged, tested and approved in a system of record. Compliance requires control and traceability, which automation supplies better than a spreadsheet.

Should we automate everything?#

No. Automate what is repeated, risky when done by hand, or blocking. A task performed twice a year may be better as a well-written SOP — see our SOP template — than as code nobody maintains.

Our releases keep breaking. Where do we start?#

Look at change size first. Large batched releases are the most common cause. Then check whether test environments genuinely resemble production, and whether rollback has actually been tested — the combination of a big release and an untested rollback is what turns a defect into an outage.

How do we measure this without a big tooling investment?#

Deployment frequency and change failure rate can be counted from your existing release records by hand. Lead time and restore time need timestamps you probably already have. Start with a spreadsheet — the number matters, not the dashboard.

What else is coming for DevOps