The Missing Piece: My 4-Year Journey Implementing Trunk-Based Development
The recent ByteByteGo deep dive into how Spotify ships to 675 million users is a masterclass in platform engineering. They call it the…
The Missing Piece: My 4-Year Journey Implementing Trunk-Based Development
The recent ByteByteGo deep dive into *how Spotify ships to 675 million users* is a masterclass in platform engineering. They call it the “Golden Path” an opinionated, friction-free workflow that allows engineers to focus on code rather than infrastructure.
At the heart of that path are two simple but disciplined foundations: **Trunk-Based Development (TBD) and Canary Deployments.**

Scaled Trunk-Based Development workflow diagram illustrating short-lived feature branches, pull-request style code reviews, and automated builds merging into a central trunk for continuous delivery.
Reading that case study felt like a mirror to my own journey. Over the last few years at **Juspay**, I’ve led several teams through the transition from “merge hell” to these exact high-velocity patterns. But while the theory in a case study looks clean, the reality of implementing it in the middle of a high-growth environment is much grittier.
Here is what I’ve learned transitioning four different teams, from Payments to AI Infra; A workflow that actually scales.
The Realization (2021)
In 2021, I attended a seminar about release strategies, and that is when the speaker mentioned **Trunk-Based Development (TBD) and it felt like a light-bulb going off. Shortly after, I picked up *Accelerate: Building and Scaling High Performing Technology Organizations* and the data confirmed my hunch: high-performing teams don’t just work harder; they work in smaller batches.**
At the time, our reality was different. We were dealing with “sandbox freezes”, merge conflicts that felt like a part-time job, and the constant anxiety of a “Big Bang” release. I knew TBD was the missing piece of our workflow.
2022: The Payment Page Breakthrough

The “Scaled Trunk-Based Development” model: Short-lived branches and a single source of truth. (Source: trunkbaseddevelopment.com)
In 2022, I had the opportunity to lead the Payment Page team at Juspay. In payments, the margin for error is zero.
- The Problem: We were managing multiple versions of the payment page for different merchants on their own release branches. It was a maintenance nightmare.
- The Solution: We moved to TBD and adopted Semantic Release Versioning.
- The Result: No more waiting for branches to unfreeze. Production hot-fixes became a simple cherry-pick. We targeted a weekly release cycle and while it spilled over for the first few weeks as we adjusted, it eventually became our heartbeat. We’ve followed that weekly rhythm ever since.
2024: Scaling to 20+ PRs a Day (The Dashboard Challenge)
When I transitioned to the Dashboard team, I walked into a completely different beast. This was a high-velocity monorepo where multiple teams contributed.
- The Chaos: We were merging a minimum of 20 PRs every single day.
- The Stakes: To make it more “exciting”, there was no dedicated Dev environment!!
Every deployment to the internal sandbox was live for Juspay users. By the time QA reported a bug, our users had already found it. I realized TBD alone wasn’t enough; We needed to isolate the impact of the deployment, not just the code.
- The Solution: TBD + Canary Deployments We introduced Canary Deployments to give QA the breathing space they needed. Paired with TBD, it was an instant hit. Deployment issues dropped by 90%.
- The Fail-safe: For the remaining 10%, we integrated ***Superposition*** for configuration checks. This gave us the “remote control” to toggle features for specific users, ensuring that even if a bug slipped through, its blast radius was negligible.
Platform Agnostic Principles
The beauty of these principles: TBD, Canaries and Feature Flags is that they are platform-agnostic. I’ve continued to implement this workflow in every team I’ve transitioned to since.
As the industry moves toward AI-driven infrastructure, the unpredictability of LLMs makes these “boring” foundations even more critical. You can’t predict an AI’s output with 100% certainty, but you can control how much traffic it sees through a Canary.
Closing Thoughts: It’s About the People
The “Spotify Way” isn’t about their specific internal tools; it’s about a culture that favors continuous integration over big-bang releases.
But here is the most important lesson I’ve learned: No tool can fix a culture. The success of these transitions at Juspay wasn’t because of the tech; It was because every team member contributed to making it work. They traded the “comfort” of long-lived branches for the discipline of small, frequent commits.
If your team is currently stuck in “merge hell”, my advice is simple: Start small, find your “Golden Path”, and remember that a peaceful deployment is the ultimate engineering luxury!
메타데이터
- post_id
- e2d08c082f3e
- slug
- the-missing-piece-my-4-year-journey-implementing-trunk-based-development-e2d08c082f3e
- url
- https://medium.com/@lightningshivam/the-missing-piece-my-4-year-journey-implementing-trunk-based-development-e2d08c082f3e
- canonical_url
- https://medium.com/@lightningshivam/the-missing-piece-my-4-year-journey-implementing-trunk-based-development-e2d08c082f3e
- author_url
- https://medium.com/@lightningshivam
- status
- ok
- fetched_at
- 2026-07-11 10:54:37