Software engineering · Platform and delivery engineering
Releasing on a Friday without anyone worrying
We set up automated pipelines, environments created on demand, a testing strategy that is actually followed, and a release process where deploying code and launching a feature are separate decisions. Releases take minutes, not rounds of approval.
Where this starts
Slow delivery has structural causes, not a lack of effort
When a team is releasing slowly, the engineers are rarely the cause. The problem is usually an environment that has to be requested, tests so slow that people skip them, a release that needs three people and a scheduled window, or a review queue that nobody owns. These are structural problems with structural fixes, and fixing them is almost always cheaper than living with them.
What we usually find
- A single shared test environment that teams have to queue for
- Tests so slow that people merge changes without waiting for the results
- Releases grouped into a monthly window, which makes each one bigger and riskier
- Rolling back a release means restoring a database backup
- Deployment steps that only exist in one person’s command history
- No measurement, so discussions about speed are based on feelings
Our position
Releasing frequently is not about appearances. Making smaller changes more often is the most reliable way we know to make releases safer.
What the work covers
The whole route from code change to production
We look at the whole route, not just the pipeline, because the delay is usually somewhere the pipeline does not reach. Security checks are covered by application security, and we connect our work to them rather than building a second set.
Pipelines
Building, testing and deploying follow one defined route. It is fast enough that waiting for it is normal, and nobody has to decide whether it is worth running.
Environments on demand
A temporary environment is created for each change under review. Reviewers can see the change running, and the queue for a shared test environment disappears.
Infrastructure as code
Every environment can be recreated from the code repository with a single command. Differences between environments are visible, rather than known only to one team.
Testing strategy
Fast tests catch most problems, and slower tests run only where they are worth the time. Test data is managed properly, rather than improvised by each developer.
Gradual releases
Feature flags and gradual rollout mean that deploying code and launching a feature are separate decisions. Rolling back becomes a switch, rather than a restore followed by an apology.
Developer experience
New developers can set up their machine on their first morning, every service has a clear owner, and we remove the small, repeated frustrations that quietly waste a large part of every week.
How progress is measured
Measure first, then improve
We start by measuring the four standard delivery indicators. Without them, any discussion about speed is just a matter of opinion.
Lead time
The time from a code change to it running in production, measured from your own systems. This usually shows where the real delay is within the first week.
Frequency
How often you actually release, tracked rather than estimated. It is usually the first figure to improve, and the one people notice.
Failure rate
The share of releases that need an immediate fix. This keeps the focus on quality, so speed is not improved at the expense of stability.
Recovery time
How long it takes to recover from a bad release. We rehearse it, rather than relying on how long it took last time.
Pipeline health
How long builds take and how often tests fail for no real reason. A slow or unreliable pipeline is the most common reason good practices are quietly abandoned.
What you are left with
- A pipeline that anyone on the team can understand and run
- A temporary environment for every change under review
- A release process where rolling back is a switch
- The four delivery measures, collected from your own systems
- A documented route from code change to production, owned by your team
Tell us how long a one-line change takes to reach production
That figure, and the reasons behind it, usually tell us most of what we need to know.