What is release engineering?
Release engineering covers everything between a tested artifact and the moment users see the change. It decides how versions are named, which environments a build passes through, how traffic moves to the new version, who can switch a feature on, and what happens automatically when the new version misbehaves in production.
The core idea is to separate deployment from release. Deploying puts new code on servers. Releasing exposes it to users. When the two are separate, a team can deploy several times a day with features hidden behind flags, then release to a small share of users, watch the signals, and widen the exposure in steps.
Release engineering sits downstream of the build pipeline and upstream of monitoring. It reuses the artifacts the pipeline produces and the signals that observability provides. Within our DevOps consulting practice, it is often the service that turns a fast pipeline into delivery that is both fast and safe.
Signs you need release engineering
Teams usually call us after a release went wrong in public, or when the release process has grown so heavy that nobody wants to run it any more. Both situations point to the same gaps in how changes reach users.
Releases need a meeting, a checklist and a weekend
When each release is an event with a war room, changes pile up between releases and every one carries more risk than the last.
Rollback means redeploying the old build by hand
If going back takes as long as going forward, teams hesitate during incidents and users wait while the decision is debated.
Unfinished features live on long-lived branches
Branches kept open for weeks to hide work in progress end in painful merges and releases that bundle unrelated changes.
Nobody can say which version is in production
Without consistent tags and release notes, support and engineering argue about what changed, and audits take days instead of minutes.
A database change has blocked a rollback
Schema migrations shipped together with the code they serve make rollback impossible. They need their own sequence and compatibility rules.
If two or more of these sound familiar, the problem is the release process, not the people running it. Adding approval steps usually makes things worse, because it makes releases rarer and therefore bigger and riskier.
What our release engineering engagement covers
We start with how releases actually happen today: the calendar, the last incidents, the rollback attempts and the approvals. Then we design a target process and build it into your tooling. Our guide on deployment windows and release planning shows how we weigh business constraints against release cadence.
Release audit and target process
Current flow mapped from merge to user exposure, incidents reviewed, and a written target process with an owner for each step.
Versioning and release notes
Semantic versions, Git tags created by the pipeline, and release notes generated from merged changes instead of written from memory.
A rollout strategy per service
Blue-green, canary or rolling chosen for each service according to its traffic, state and risk, then automated in your deploy tooling.
Feature flags with a lifecycle
A flag platform or a simple in-house system, naming rules, owners and a removal date, so flags do not become permanent debt.
Automated rollback on health signals
Rollback triggered by error rates and latency compared with the previous version, rehearsed on a schedule, with a manual override.
The deliverables are working configuration in your pipelines and deploy tooling, plus a short release handbook. The handbook answers the questions on-call engineers ask at the worst moment: how to stop a rollout, how to go back, and who is allowed to decide.
Is your next release a gamble?
A release audit typically takes 1 to 2 weeks and ends with a target release process and a prioritized plan.
How we rebuild releases: four phases
We change the release process one service at a time. Each phase leaves the team with something it can use straight away, even if the engagement stops at that point, so no phase is spent on preparation alone.
PHASE 01
Audit
Release history, incidents, calendar, approvals and rollback attempts reviewed.
PHASE 02
Decouple
Feature flags and versioning separate deployment from release.
PHASE 03
Automate
Progressive rollout and health-based rollback built into deploy tooling.
PHASE 04
Rehearse
Rollback drills, release handbook, training and handover to on-call.
We pick a first service with real traffic but a limited blast radius, so the new process is tested on something that matters. Once canary analysis and rollback have worked there, the same templates roll out to the rest of the estate. Rollback drills continue after handover, because a rollback that has never been run is a hope, not a plan.
Blue-green, canary or rolling: which fits?
There is no single right strategy. The choice depends on how much traffic a service receives, whether it holds state, and how much spare capacity you can afford during a switch. We decide per service and write the reason down next to the configuration.
| Strategy | How it works | Fits when | Trade-off |
|---|---|---|---|
| Blue-green | Two full environments, traffic switched at once | Instant rollback matters and capacity can double briefly | Double infrastructure during the switch |
| Canary | New version gets a small, growing share of traffic | Enough traffic exists to compare error rates | Needs good metrics and automated analysis |
| Rolling | Instances replaced in batches behind the load balancer | Stateless services with tolerant clients | Old and new versions run side by side |
| Feature flag | Code deployed dark, exposure controlled at runtime | The business wants to choose release timing | Flag debt if removal is not enforced |
Most estates end up with a mix: canary for high-traffic APIs, blue-green where a fast full switch matters, flags for product launches. Strategies also combine, such as a canary rollout of code whose new feature stays behind a flag. What matters is that every service has a documented strategy and an automatic way back.
Release risks and how we contain them
Progressive delivery reduces the impact of a bad release, but it adds moving parts of its own. These are the failure modes we design around from the start, before the first automated rollout reaches production.
Schema changes that break the old version
We use expand-and-contract migrations: add first, switch code, remove later, so either version can run against the database during a rollout.
Canary analysis on too little traffic
A canary that sees a handful of requests proves nothing. We set a minimum traffic level and duration before any automatic promotion.
Flags that never get removed
Each flag gets an owner and an expiry date, and stale flags are reported in the pipeline so they are cleaned up on time.
Rollback that has never been tested
Automated rollback is rehearsed on a schedule in a real environment, so its first real run does not happen during an incident.
Rollback design deserves its own attention. Our guides on automated rollback and incident recovery and on audit and traceability of releases in production explain how to detect a bad release quickly and prove afterward exactly what ran, and when.
Release engineering pricing
Every engagement starts with a diagnosis of how you release today and ends with a fixed quote. Durations are typical, not promised, and each phase can stop with usable results if your priorities change along the way.
| Format | Duration | Price |
|---|---|---|
| Release audit | 1 to 2 weeks | Fixed quote after diagnosis |
| Progressive delivery on core services | 6 to 12 weeks | Fixed quote after the assessment |
| Enablement support after handover | 30 days | Fixed quote after the assessment |
What changes the price: number of services to cover, how much state they hold, existing traffic routing and whether a feature flag platform is already in place.
The quote covers senior consultants only, a defined set of services and the deliverables of each phase. Feature flag platform subscriptions, load balancer or service mesh costs and any extra capacity used during blue-green switches are paid to their providers, outside our fees.
Release engineering FAQ
What is the difference between deploying and releasing?
Deploying puts new code into an environment. Releasing makes it visible to users. Feature flags and progressive rollouts keep the two apart, so code can be deployed often while exposure stays controlled and reversible.
Do we need a service mesh for canary releases?
No. Canary traffic splitting can run at the load balancer, the ingress controller or inside the application with flags. A mesh helps at larger scale, but we only recommend one when simpler routing has reached its limits.
How do you handle database migrations during a rollout?
With expand-and-contract changes. New columns or tables are added before the code that uses them, and old ones are removed only after every instance runs the new version, so rollback never meets an incompatible schema.
Should we buy a feature flag platform or build one?
It depends on your needs. A few flags with simple on and off rules can live in configuration. Targeting by user segment, audit trails and experiments usually justify a dedicated platform. We compare both against your constraints.
Can releases happen during business hours?
Yes, and that is usually the goal. Small changes with automated canary analysis and rollback are safer in the middle of the day, with the whole team present, than at night with one tired engineer on call.
How do you prove the new process works?
We track change failure rate and time to recovery, two of the DORA metrics, before and after, and we run rollback drills with your team. A second measurement after handover shows whether the gains hold.