Deploy records
Deploy records are the workflow for knowing what is running right now, without having to ask anyone. The decision that stays with us is what goes live: we review and merge every change ourselves. Recording it, and noticing when a build fails, is done by the systems themselves, with a watcher on the result. This page shows how we used to keep track, how it works now, and the parts behind it.
How we built ours
The system that did the work writes the record. Nobody writes deploy notes, so nobody forgets to.
How we used to do it
- We'd merge a change and deploy it.
- Mean to note what had gone live, and when.
- Usually not get round to it.
- When something broke, work backwards through the history to guess what had changed.
- Find a failed build when someone happened to look.
Guesswork, exactly when we could least afford it.
What changed
We still review and merge every change. Writing down what went live, and spotting a failed build, stopped being ours.
How we do it now
- A change is merged or a deploy finishes, as before.
- The code host or the hosting service calls the board directly.
- The board checks the call is genuine and writes the event as its own row, with the commit that went live.
- The watcher turns a failed build into an open "needs you" row and sends it to the alerts channel.
- It shows on the operations dashboard within a minute.
No effort at all, and what is live is looked up, not remembered.
The parts
One small function that accepts calls from the code host and the hosting service and turns each into a row on the board. A shared secret it checks before it accepts anything. The operations dashboard and the alerts channel, reading the rows. And one design choice that makes the record trustworthy: whatever did the work writes the row itself, so nothing is reported second-hand.
What it took us
The function is the smallest part of the board: one door for webhooks beside the helper and the database. Deploy and merge rows have been arriving on their own since the September rebuild.