{"id":3815,"date":"2026-10-18T23:25:00","date_gmt":"2026-10-18T23:25:00","guid":{"rendered":"https:\/\/www.gujaratorbit.com\/blog\/?p=3815"},"modified":"2026-10-18T23:25:00","modified_gmt":"2026-10-18T23:25:00","slug":"devops-garba-season-case-study","status":"publish","type":"post","link":"https:\/\/www.gujaratorbit.com\/blog\/devops-garba-season-case-study\/","title":{"rendered":"A DevOps Case Study: Scaling a Festival Booking Site"},"content":{"rendered":"<p>On the first of July, the engineering lead at a fictional Ahmedabad booking company \u2014 call it Tarang Live \u2014 pinned one page to the wall beside the standup board. It recorded that Navratri would begin in eleven weeks, that the previous year&#8217;s Garba event listings had collapsed the search function twice, and that this year there would be no third collapse. What follows is the twelve-week record of that team&#8217;s DevOps preparation, presented as it happened, with the numbers the team itself tracked.<\/p>\n<h2>The Setting: Nine Weeks to Garba Season<\/h2>\n<p>Tarang Live sold passes for dandiya nights, heritage walks, and food festivals across Gujarat. Seasonally, its traffic curve resembled a heart monitor: quiet for months, then violent spikes every late September. The team of five shared one on-call rota with nobody, and its release process belonged to an earlier decade \u2014 a fortnightly change board, a quarterly release train, and a deployment script only one engineer would run from his laptop. Intent was never the problem. Structure was.<\/p>\n<h2>Week Zero: The Baseline<\/h2>\n<p>Precise work starts with precise measurement, so the first week recorded the panel exactly as found:<\/p>\n<ul>\n<li>Lead time \u2014 four weeks from merged code to a live listing page.<\/li>\n<li>Deployment frequency \u2014 once a quarter, weather permitting.<\/li>\n<li>Time to restore \u2014 six and a half hours during the last season failure.<\/li>\n<li>Change failure rate \u2014 roughly one deployment in three needed a follow-up fix.<\/li>\n<li>Rework rate \u2014 unknown, and its absence was itself a finding.<\/li>\n<\/ul>\n<p>Two calibrations from the research were noted at the same time: restoration counts only change-caused failures per the 2023 redefinition, and rework rate joined the panel in 2024. The team also priced its queue \u2014 ten approved features, each valued near 5,000 units of weekly benefit, waiting on average three weeks \u2014 which produced a delay bill of about 180,000 units a quarter. That figure, not any technical argument, is what opened the budget line for a coach.<\/p>\n<h2>What the Baseline Never Showed<\/h2>\n<p>The week-zero numbers carried a gap worth reporting. No measure existed for how much effort went into redoing failed work, which is why the unknown rework figure mattered more than the poor numbers beside it. Once the column existed, it told a story the others had missed: roughly a third of engineering time was quietly spent re-fixing changes that had already shipped. That discovery did more for the automation case than the delay bill, because it reframed the spending as current rather than future. Baselines, the team concluded, should always include a row for what is not yet measured \u2014 the empty row is often the loudest cell on the page.<\/p>\n<h2>Weeks 1\u20134: Seeing the Work, Stabilising the Path<\/h2>\n<p>The coach arrived in week one and prohibited tooling purchases for a fortnight. The team drew its value stream instead: an idea for a seating-chart feature waited six days for review, nine days for the change board, eleven days for the release window. Work time was measured in hours; wait time in weeks. With the waits exposed, three agreements were signed and posted. The checkout-and-listings stream would be protected from the shared release calendar. Output would dip while automation raised the testing bar, and a six-week dip was pre-approved so nobody would panic at week four. And every change would henceforth travel one identical pipeline, built once, promoted through each environment without rebuilding.<\/p>\n<h2>Weeks 5\u20138: Automating the Path, Rehearsing the Exit<\/h2>\n<p>Week five delivered the incident that had been scheduled by history: a routine deploy triggered a 4 percent rise in declined payments. The response followed the new script \u2014 deployment ID declared, owner named, no irreversible migration having run, so rollback proceeded \u2014 and still consumed 190 minutes, because rehearsal had not yet happened. The team drilled monthly thereafter. By the third timed exercise the same recovery ran close to twenty minutes. Commit feedback was tightened in parallel until every change received a verdict in roughly ten minutes; when a stage ran long, the stage was simplified rather than the wait accepted. Flags went in so unfinished work could sit dark in production, and canary routing covered anything touching payments.<\/p>\n<h2>Weeks 9\u201312: Governing and Spreading<\/h2>\n<p>The final phase addressed the questions an auditor would eventually ask. Access moved to least privilege. Static credentials were retired in favour of short-lived tokens issued through OIDC. A break-glass merge path was created \u2014 loudly alarmed, never silently available. A quarterly evidence routine was scheduled: roughly ten changes pulled at random, each checked end to end for a complete trail. None of it slowed the pipeline; that is the point of automated, evidenced controls in a regulated context. In week eleven, the team running the company&#8217;s vendor-management app asked to adopt the same rules, which is the customary moment a pilot stops being a pilot.<\/p>\n<h2>Locating the Team on the DevOps Maturity Ladder<\/h2>\n<p>The standard ladder runs from siloed beginnings through automated islands and integrated working up to continuous delivery, whose final step is the learning system. In July, Tarang Live was honestly siloed with islands of local automation \u2014 the deployment script, the laptop. By the end of September it stood at integrated, with the checkout stream genuinely continuous and the blameless-review habit (held within five working days, focused on systems rather than people) functioning as its learning mechanism. Two rungs in twelve weeks is typical for a coached pilot; claiming the top rung in a quarter is how programmes get laughed out of retrospectives. Definitions for this ladder and its terms were kept consistent against <a href=\"https:\/\/www.xopsschool.com\/devops\/\">xOps School&#8217;s DevOps encyclopedia page<\/a>, which spared the team several circular debates.<\/p>\n<h2>What the DevOps Quarter Produced<\/h2>\n<p>Season opened on the twenty-second of September. Lead time had fallen from four weeks to under two days. Deploys ran several times weekly through the spike period, including one Saturday-morning fix for a seating-map edge case that would previously have waited for the next train \u2014 and possibly caused the next collapse. Restore capability was never formally exercised in anger, which the team regarded as the correct anticlimax. The change failure rate settled near one in ten, and the rework figure that had been unmeasurable in July became a standing column on the wall.<\/p>\n<p>Other teams preparing for their own spike season can borrow the sequence rather than the specifics: <a href=\"https:\/\/www.gujaratorbit.com\/blog\/devopsschool-a-simple-step-by-step-guide-to-building-your-devops-career\/\">the step-by-step DevOps career guide for building skills in order<\/a>, <a href=\"https:\/\/www.gujaratorbit.com\/blog\/devops-consulting-services-for-automation-collaboration-and-continuous-delivery\/\">the piece on DevOps consulting services for automation, collaboration, and continuous delivery<\/a> when outside capacity is needed, and <a href=\"https:\/\/www.gujaratorbit.com\/blog\/choosing-the-right-devops-consultant-for-enterprise-transformation\/\">the checklist for choosing the right DevOps consultant for enterprise transformation<\/a> before signing anything. Precise people will notice the pattern beneath it all: see the work truthfully, automate one path completely, rehearse failure calmly, and let the calendar \u2014 Navratri or otherwise \u2014 find a team that is already rehearsed.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A twelve-week, week-by-week account of a festival booking platform preparing for Garba season: baselines, a J-curve dip, rehearsed rollbacks, and calmer queues.<\/p>\n","protected":false},"author":7,"featured_media":3816,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2543],"tags":[],"class_list":["post-3815","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/posts\/3815","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/comments?post=3815"}],"version-history":[{"count":1,"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/posts\/3815\/revisions"}],"predecessor-version":[{"id":3827,"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/posts\/3815\/revisions\/3827"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/media\/3816"}],"wp:attachment":[{"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/media?parent=3815"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/categories?post=3815"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gujaratorbit.com\/blog\/wp-json\/wp\/v2\/tags?post=3815"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}