Keep a record of what went live
Keep a verifiable record of the code that went live and flag failed builds.
Keep the evidence
A commit is a named version of the code. Record its identifier with the deployment result, rather than relying on someone to remember what changed.
The method
Let the deployment service report whether the build succeeded or failed, with its commit identifier. Check that the message came from the expected service before accepting it. A webhook is an automatic message between systems; it still needs verification. Save the event in a shared log with a link to the build. Send failures to a place someone checks. Look up the running version against that log when you need to investigate a change.
Check the result
You can trace a live version to its build, and a failed build is visible for review. This needs a configured event receiver and service credentials. People still review, merge and decide what to change.
How we use it at Pitch
At Pitch, the board is our shared work log. An assistant is software that follows our instructions with access to agreed tools. A watcher checks for changes and reports them; a worker runs a configured routine. Those roles need explicit instructions, access and permissions. Context and boundaries 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. The setup 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. Our sequence 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. The principle The system that did the work writes the record. Nobody writes deploy notes, so nobody forgets to. What stays with a person We still review and merge every change. Writing down what went live, and spotting a failed build, stopped being ours. 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. How the process began 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.