{"id":2467,"date":"2026-10-18T20:00:00","date_gmt":"2026-10-18T20:00:00","guid":{"rendered":"https:\/\/www.bhopalorbit.com\/blog\/?p=2467"},"modified":"2026-10-18T20:00:00","modified_gmt":"2026-10-18T20:00:00","slug":"devops-90-day-ticketing-plan","status":"publish","type":"post","link":"https:\/\/www.bhopalorbit.com\/blog\/devops-90-day-ticketing-plan\/","title":{"rendered":"How We Learned DevOps: A Small Team’s 90 Days"},"content":{"rendered":"

The night our booking page fell over, it rained hard enough to drum on the office shutter. A folk-festival on-sale opened at nine, traffic arrived at 9:01, and by 9:04 our three-person team was watching an error page where the ticket button used to be. We fixed it by midnight. We also decided, somewhere between the second chai and the third, that we would rather never repeat the evening. That decision is how we came to learn DevOps properly, in ninety days, on a budget that would not frighten a street food stall.<\/p>\n

Step One: Watch the Work Before Changing It<\/h2>\n

Our first week produced no code at all. We drew the journey of a single feature \u2014 “add a seating map” \u2014 on the wall, from idea to the moment a customer clicked pay. The picture was humiliating. Roughly four days of actual work sat spread across five weeks of waiting: waiting for review, waiting for a deploy window, waiting for whoever held the server passwords to be awake. Nobody had been lazy. The system had been patient. Seeing the waits on paper, with numbers beside them, ended every argument about where to start.<\/p>\n

A tip for anyone repeating the exercise: time the waits yourself instead of estimating them from memory. Our estimates were flattering by half, and the real numbers \u2014 captured with a stopwatch and some honest ticket notes \u2014 bought us credibility with the coach from the very first meeting. Measurement before persuasion; it is the same instinct that later made our audit folder easy.<\/p>\n

Step Two: Protect One Stream and One Coach<\/h2>\n

We had exactly one product worth protecting: checkout and ticketing. So that became our stream, and we hired an enabling coach for one quarter rather than “doing a transformation”. She made us sign something I initially found dramatic \u2014 an agreement that output would dip for several weeks while automation raised our testing bar, and that nobody would panic about the dip before an agreed date. She was right to insist. The J-curve is real; week four tested us precisely as promised, and the pre-agreed date is the only reason we did not pull the plug.<\/p>\n

Step Three: Build Once, Promote Everywhere<\/h2>\n

Until then, each of us built the app slightly differently, which meant staging tested an artefact production had never seen. Week three fixed that permanently: one pipeline, run the same way every time, producing one build that travels forward through every environment without being rebuilt. Then we attacked feedback speed. Any commit had to get an answer \u2014 pass or fail \u2014 in about ten minutes. When a check pushed past that, we shortened the check rather than accepted the wait. Fast answers keep a three-person team honest; slow ones teach you to batch, and batching is how Fridays get dangerous.<\/p>\n

Step Four: Rehearse the Rollback Until It Is Boring<\/h2>\n

The rain-night recovery had taken us three hours, much of it spent remembering how. Our coach made us script the sequence \u2014 declare the deployment ID and an owner, check whether an irreversible database step had run, roll back if safe or switch the feature off if not \u2014 and then practise it on the calendar, monthly, with a stopwatch. Our first timed drill was slow. The third was quicker than our original real emergency by an order of magnitude, which is the professional way of saying the drill now finishes in the time it takes the kettle to boil. Every incident since has ended in a no-blame review inside five working days, pointed at systems rather than people.<\/p>\n

Step Five: Let Releases Arrive in Stages<\/h2>\n

We stopped saving work up. Small changes merge into one shared trunk daily \u2014 no more feature branches ageing like pickle \u2014 and anything user-facing ships behind a flag so it can sit dark in production until we choose. Riskier changes go out first to a sliver of traffic as a canary. The seating map spent two weeks invisible to customers while we poked it in staging, then flipped on for real one quiet Tuesday without a single ticket of drama.<\/p>\n

Our DevOps Rules, Written Down and Handed Over<\/h2>\n

Phase three of the quarter was governance, which sounded corporate until we saw it was mostly house rules. Access became least-privilege; credentials became short-lived tokens issued through OIDC instead of a shared password in a group chat. A break-glass merge path exists for genuine emergencies and announces itself loudly when used. Each quarter we pull roughly ten random changes and check their evidence end to end \u2014 fifteen minutes each, and the audit folder writes itself. Reference material kept us honest throughout; the coach pointed us at the Ops Atlas DevOps explainer<\/a> so our arguments were about trade-offs, never definitions.<\/p>\n

Step Seven: Keep the Numbers Where Everyone Sees Them<\/h2>\n

The last habit cost nothing and changed our arguments. The five delivery measures went on a whiteboard beside the kettle, updated every Monday:<\/p>\n