Software Delivery
How work gets from an idea to running software: branching, releases, environments, testing. Designed to be followed, and boring on purpose.
A release should be a Tuesday, not an event
When a release needs a bridge call, a rota and somebody who knows the one undocumented step, the process has quietly moved into people's heads. It works until the person is on holiday. Teams in that position are rarely careless - they are running a process that was designed for a smaller system and never redesigned.
We design the way work moves instead: what a branch means, which environment is telling the truth, what has to pass before anything ships, and who decides. Then we separate the two decisions that usually get welded together - putting code into production, and turning a feature on for customers.
The test is not the first release. It is the third one being as dull as the first, which is why we would rather stay for a few cycles than hand over a document and leave.
One of our four consultancy limbs. The others are architecture, business analysis and delivery diagnosis.
Four ways we get brought in
Most of this work starts as one of these. You don't need to know which before you talk to us.
Release process design
What happens between a merge and a customer seeing it, written so a new starter can run it.
Branching and environment strategy
What a branch means, how long it lives, and which environment is telling the truth.
Feature gating and progressive release
Shipping the code and switching it on become separate acts, so a rollback stops meaning a redeployment.
Delivery process review
We watch a real release rather than reading the document about it, and name the step costing you.
What a delivery process has to settle
- What "done" means
- Written down, and the same for everybody. If one team means merged, another means tested and a third means live, the release plan is a negotiation every time it runs.
- What blocks a release
- The gates, and who can open them. A gate that anybody can wave through under pressure is a comment, not a gate, and everyone learns that within about two releases.
- How you go back
- Rolling back should be a switch, not a project. If your only route back is redeploying the previous build, every release carries more risk than it needs to.
- Who does it at 4pm on a Friday
- A process that only works when your best engineer runs it has not been designed yet. We test ours against the person who joined last month.
What lands on your desk
- The process, written down
- Branches, environments, gates and owners, short enough that people read it.
- The pipeline changes
- That automate the steps currently held by a person.
- A first release run with you
- Because a process nobody has run is a proposal.
What it looks like when it works
Two organisations, the same fault underneath: work that was finished and was not reaching anyone. One was releasing constantly and undoing most of it; the other had stopped releasing at all.
| Item | Result | Notes |
|---|---|---|
| Releases rolled back | 45% | at a UK high-street retailer before the work, with no single release explaining it |
| Deployment success | 95% | after feature gating at merge time and one shared release process |
| Still running on it | 10 years | the tooling built to run that process is still the core of it |
| Releases in six months | 5 | at a rail technology supplier that had gone months without one - five finished features sitting on five long-lived branches |
Common questions
Our releases work. They are just slow and everybody dreads them. Is that this?
That is exactly this. A release nobody wants to be on call for is a process problem, not a people problem, and dread is a reliable sign that the process is asking humans to hold something in their heads that a pipeline should be holding.
Do we have to change our tooling?
Usually not. What breaks a release process is rarely the tool - it is that nobody agreed what a branch means, or which environment is telling the truth. We start from what you already run and change the tooling only where it is genuinely in the way.
What does "boring" actually mean here?
That a release is a Tuesday afternoon rather than an event. Same steps every time, no heroics, nobody staying late, and the decision to ship separated from the decision to switch a feature on.
How long before it sticks?
Designing it takes weeks. Sticking takes a few release cycles, because the proof is that the third one is as dull as the first. We would rather stay for those than hand over a document and leave.
Can you do this without rewriting the application?
Yes, and that is the normal case. Branching, environments, gating and what runs in the pipeline all sit around the code rather than inside it. Where the application does have to change, feature gating is usually the only part that touches it.