← Back to list

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…

Shivam Ashtikar · 2026-04-08 21:15 · 119 claps · 3.1 min read
#software-development #devops #trunk-based-development #engineering-management #juspay
Open on Medium ↗
Wiki topics: BIZ · Business Strategy ☁️ · DevOps & Cloud 🎵 · Music & Audio

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.

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)

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