Luminate Retail Group · 2025
From a monthly release train to twenty-six releases a week
A monthly release train replaced with an automated pipeline, taking lead time from six days to four hours and change failure rate from 22 percent to 3.1 percent.
- Industry
- Multi-brand e-commerce
- Location
- Manchester, United Kingdom
- Engagement
- 7 weeks
- Team
- 2 NordsCode engineers, 5 client engineers
Outcomes
- 26Releases per week, up from 4 per month
- Averaged across the three months after handover, spanning six services. The previous cadence was a single coordinated release train on the last Thursday of each month.
- 3.1%Change failure rate, down from 22%
- Proportion of deployments requiring a rollback or an immediate corrective release, measured over the same three month period against the pipeline's own recorded history.
- 4 hrsLead time from merge to production, down from 6 days
- Median time between a pull request being merged and the change serving live traffic, reported automatically by the pipeline rather than estimated.
The challenge
What we found when we arrived.
Luminate Retail Group operates four consumer brands on a shared commerce platform, with peak trading concentrated in a six week window each winter. Releases went out once a month as a coordinated train: every team's changes batched together, a manual regression pass over two days, and a deployment run by hand from a laptop by the platform lead.
The batching created its own problems. A single failing change could block everyone else's work for another month, and because each release contained roughly forty merged pull requests, diagnosing a production issue meant working backwards through all of them. Roughly one release in five required a same-week corrective deployment. During the winter peak the team froze releases entirely for seven weeks, which pushed urgent fixes into an undocumented manual process.
Our approach
What we did, in the order we did it.
Sequence matters more than tooling on engagements like this one. Each step below existed because the previous one produced something the next one needed.
- 01
Measure the baseline honestly
One week instrumenting the existing process before changing it: build durations, queue times, manual steps and rollback frequency. The measured six day median lead time was considerably worse than the team's own estimate, and that gap made the case for the work internally.
- 02
Fix the tests before automating around them
The regression suite took 51 minutes and failed intermittently on nine tests. Those were quarantined and handed to the owning teams with specific reproduction steps, while parallelisation and dependency caching brought the reliable suite down to 9 minutes.
- 03
One reference pipeline, then replication
The smallest of the four storefronts taken end to end first, including canary deployment and automated rollback on health check failure. That pattern was then applied service by service, with Luminate's engineers writing the last three themselves.
- 04
Make delivery visible
Deployment frequency, lead time, change failure rate and restore time reported automatically to a dashboard the engineering manager reviews weekly, so regressions in the process surface as quickly as regressions in the code.
The results
What changed, and how we know.
Releases moved from four a month to an average of twenty-six a week across six services within three months of handover. Median lead time from merge to production fell from six days to four hours, and change failure rate fell from 22 percent to 3.1 percent, largely because canary health checks now roll back a bad deployment automatically before it reaches meaningful traffic.
The following winter peak was the first the team ran without a release freeze. Fourteen changes shipped during the six week trading window, including two urgent pricing corrections that previously would have gone out through the manual process. The platform lead is no longer the only person who can deploy: all five engineers have shipped to production independently.
What it was built on
- GitHub Actions
- Kubernetes
- Argo Rollouts
- Terraform
- Playwright
- Grafana
Engagement type
CI/CD AutomationRecognise any of this?
Most engagements start with a call describing a situation that sounds a lot like one of these. Tell us yours and we will say plainly whether we can help.