Software engineering · Platform and delivery engineering
Shipping on a Friday without anyone minding
Pipelines, environments on demand, a test strategy that is actually run, and a release approach where deploying and launching are separate decisions. Measured in minutes rather than approvals.
Where this starts
Delivery slows for structural reasons, not effort
When a team is shipping slowly the cause is rarely the engineers. It is an environment that has to be requested, a test suite too slow to wait for and therefore skipped, a release that needs three people and a window, and a review queue nobody owns. These are structural problems with structural fixes, and they are almost always cheaper to fix than to keep tolerating.
What we usually find
- A single shared staging environment that teams queue for
- A test suite slow enough that people merge without waiting for it
- Releases batched into a monthly window, which makes each one larger and riskier
- A rollback that in practice means restoring a database backup
- Deployment steps that live in one person’s terminal history
- No measurement, so the conversation about speed is a conversation about feelings
Our position
Deployment frequency is not a vanity metric. Smaller changes released more often is the most reliable way we know to make releases less dangerous.
What the work covers
The whole path from commit to production
We work on the entire path rather than the pipeline alone, because the delay is usually somewhere the pipeline does not reach. Security gates belong to application security; we wire ours alongside them rather than building a second set.
Pipelines
Build, test and deploy as one defined path, fast enough that waiting for it is the normal behaviour and running it is not a decision anyone weighs up.
Environments on demand
Ephemeral environments per branch or pull request, so review happens against a running system and the queue for shared staging simply stops existing.
Infrastructure as code
Environments reproducible from the repository, so recreating one is a command and the differences between them are visible rather than folklore held by one team.
Test strategy
A suite shaped so the fast tests catch most problems and the slow ones run where they earn the time, with test data managed deliberately rather than improvised per developer.
Progressive release
Feature flags, canary and blue-green, so releasing and launching become separate decisions and a rollback is a toggle rather than a restore and an apology.
Developer experience
Local setup that works on the first morning, clear ownership of services, and removal of the small recurring frictions that quietly consume a large share of every week.
How progress is measured
Instrument first, then improve
We start by measuring the four delivery indicators, because an argument about speed without them is an argument about opinions.
Lead time
Time from commit to running in production, measured from your own systems, which usually locates the real delay within the first week.
Frequency
How often you actually release, tracked rather than estimated. It is the number that moves first and the one people notice.
Failure rate
The share of releases needing an immediate fix, which is what keeps speed honest and stops the other figures being optimised in isolation.
Restore time
How long recovery takes when a release is bad, rehearsed rather than assumed from the last time it happened.
Pipeline health
Build duration and flake rate, because a slow or unreliable pipeline is the most common reason a good practice gets quietly abandoned.
What you are left holding
- A pipeline anyone on the team can read and run
- Ephemeral environments per pull request
- A release approach where rollback is a toggle
- The four delivery measures collected from your own systems
- A documented path from commit to production, owned by your team
Tell us how long a one-line change takes to reach production
That number, and the reasons behind it, is usually the whole diagnosis.