Why Should You Switch to Trunk-Based Development?

Four years ago, during a job interview with Agoda, the engineering manager told me that Agoda made about 50 deployments to production every day. That was a big surprise to me.

Back then, I believed the "safe" way to release software was to ship features to development or staging branches first, test everything thoroughly, and then, after a while, release it to production. I only deployed to the production branch once a month. So when I heard about deploying 50 times a day, I honestly thought, "This guy is crazy. Who does that?" That’s over 1,000 times more than I was doing!

Later, when I joined another company, I discovered trunk-based development, and now when I look back, it really feels like I was living in the stone age. In this article, I’ll walk you through:

What is trunk-based development?
Why trunk-based development works
Best practices

What is Trunk-Based Development?

Trunk-based development is a version control practice where developers merge small, frequent updates into a single core branch—often called main or trunk.

There are no develop, staging, or production branches. Just the main branch, along with short-lived feature branches. Every time something is merged into main, it gets deployed to all environments.

Why Does Trunk-Based Development Help You Move Faster?

Trunk-based development encourages developers to create small, short-lived pull requests (PRs) every day. PRs under 250 lines of code are easier to review, quicker to merge, and often result in higher-quality code.

Think about it: if you send a PR with 100 lines of code, your teammates can easily point out 10 issues. But if you give them 1,000 lines, it usually ends with a "Looks good to me" (LGTM).

As a result, your PRs get reviewed and merged faster—with better quality.

Why Is Trunk-Based Development Safer?

With trunk-based development, you avoid long-lived branches. That means the difference between your branch and main is small, reducing the risk of merge conflicts.

Also, because you're only merging small changes, it’s easier to track, test, and revert when something breaks. You can just revert a single PR, and 90% of the time, the issue is resolved.

On the flip side, if you're using long-lived branches like development or staging, you might be deploying 1,000 commits at once.

Who can guarantee nothing will break in production?
How do you even know which commit caused the problem?

At my old company (FPT Software), my teammates often had to work overtime just to deploy a release.

Why Does Trunk-Based Development Create Better Teams?

Trunk-based development helps teams collaborate better. Code reviews become less of a burden. Developers feel more confident knowing the code is simple, and if something goes wrong, it’s easy to rollback.

Best Practices for Trunk-Based Development

✅ Small and Frequent PRs

Create small PRs multiple times per day
Keep each PR under 250 LOC
Approve and merge quickly (1 reviewer is often enough)

✅ Use Test-Driven Development (TDD)

Write unit tests, integration tests, and E2E tests
Use trunk gates: only allow merges if all tests pass

✅ Implement CI/CD

Never deploy code manually. It’s boring, error-prone, and risky.
Use tools like GitHub Actions or CircleCI for automated deployments

✅ Use Feature Flags

Hide unfinished or experimental features behind flags
This allows safe deployment without affecting end users

✅ Encourage Pair Programming

Share knowledge and improve code quality through pairing
Builds a stronger sense of team ownership

If you're interested in learning more about trunk-based development and how to build a team that can ship software quickly and safely, I highly recommend checking out The DevOps Handbook. It’s a great resource for understanding modern software delivery practices used by high-performing teams.