Internal tooling for a team whose release process lived in a shared document. The work was part software, part archaeology — finding out what the process actually was before automating it.
The problem
The documented process and the real process had quietly diverged. Every person on the team ran it slightly differently, and the differences only surfaced when something broke.
How it went
- 01
Document reality first
Sat with the process as it is actually performed, not as it is written down. The gap between the two was most of the problem.
- 02
Automate the boring middle
The steps that never vary became a single command. The steps that need a judgement call stayed manual, on purpose.
- 03
Make state visible
A small dashboard shows where a run is and what it touched, so failures are readable instead of mysterious.
- 04
Ship with a way out
Every automated step can be run by hand, and every run can be undone. Tooling nobody can escape from is worse than the document was.
Along the way
What shipped
- Discovery and process mapping
- Architecture plan
- CLI tool and web dashboard
- Data visualisation for run history
- Deployment and maintenance notes
After
The team runs releases the same way twice, which was the entire point. Time-saved figures would be invented, so none are given.
No invented numbers. Ever.Next project