Making releases boring at a UK high-street retailer
How one shared branch, merge-time feature gating and a single release process turned a 45% rollback rate into 95% deployment success - and the tooling built to run it is still in use.
| Item | Result | Notes |
|---|---|---|
| Rollbacks before | 45% | of releases were rolled back under the old ad hoc process |
| Deployment success | 95% | after one shared branch, feature gating and a single release into QA |
| Merging continuously | 6 teams | of eight or nine engineers in one codebase that previously had no main branch |
| Still in use | 10 years | on, the release tooling built then remains the core of the retailer's release process |
The organisation: a major UK high-street retailer
A major UK high-street retailer ran two e-commerce estates that had grown up apart. The international one was built as an island in Java on a commercial e-commerce platform. The UK one had a mainframe at the base, connecting to the warehouse systems and acting as the fulfilment layer, with a mixture of Classic ASP and .NET serving the shop front. Our team was brought in to converge the two.
The problem: releases the whole organisation had learned to fear
The organisation was process-lite by reputation and proud of it: just get it done, work it out as you go. There was no specification when the work started. Deployments to the UK estate were ad hoc, source control was barely used in any recognisable way, and there was no main branch or authoritative point of truth.
The consequence showed up on release day. Releases were allocated by slot, with two or three projects competing for each one, and choosing which projects went together took hours of management time. Deployments went out at 4am, but real traffic only arrived at 9 or 10am, which is when anyone found out whether it had worked. Roughly 45% of releases were rolled back. Each rollback cost the preparation, the slot, and another round of management hours re-ordering the queue behind it.
What changed: separate shipping code from switching it on
- One branch, and SQL that could be re-run. Both teams merged to a shared branch, with database changes going in as idempotent scripts alongside the code - so a merge was a complete, repeatable change, database and all.
- Off-state, the foundational piece. Work merged into the main branch switched off, hidden behind configuration gates. That separated two things the retailer had always done as one: a deployment event (code goes live) from a feature event (configuration turns it on). Teams could merge from day one, before a feature was finished, without that merge putting anything in front of a customer.
- A release process built on what was allowed. The on-premise build tooling could not be configured, and changing it was off the table. Rather than fight it, the team built a layer above it: spreadsheets carrying the release state, an agreed meaning for each status, and one engineer who knew how to wrap the SQL scripts together. Crude, and it worked.
- A single release into QA. One assembled release was tested and signed off, instead of QA being spread across every competing project separately.
From a physical ticket to an internal app
The first version of the process ran on standups and a physical merge ticket: to merge to main, you went and got the ticket. That is what the release management app replaced - assign the merge ticket to yourself, do your merge, add your release notes, all in one small internal website. Nothing conceptually new, just the process that already worked turned into software, then iterated.
The results: rollbacks stopped being routine
- Deployment success reached 95%, from a starting point where roughly 45% of releases were rolled back.
- Six teams of eight or nine engineers merged continuously into one codebase, from a starting point of no shared main branch.
- Conflicts surfaced early, because people merged small amounts often and could see each other's work as it landed.
- Features could be switched off by configuration after going live, so a problem no longer meant a rollback.
- That release management app is still the core of the retailer's e-commerce release process.
The pattern travels. Most organisations that are frightened of releasing are not short of talent or tooling. They are missing the separation between shipping code and switching a feature on, and a process everyone actually shares. This is the experience behind our consultancy.
See all four case studies, or read rolling out a legal requirement to 72,000 households, simplifying a billing structure and real-time integration for a recycling operator.