Trunk-Based Development - A Short Guide for Modern Teams

I have worked with many clients as a DevOps / Infra engineer, and one of the common overlooked parts of Software Development is the Release / Branching Strategy

It plays a crucial role in,

1. Deploying to Production frequently & safely

2. Rollback in case of any issues

3. Managing Hotfixes for Production

   
   There are various branching strategies, and in this blog post, I will detail one of the strategies that I often use in client projects - Trunk Based Development or Dirty Master Strategy

What is Trunk-based Development

Trunk-Based Development (TBD) is a version control strategy where developers collaborate on code in a single branch called main or trunk.

The idea is to keep the code changes small, frequent, and merge into the main branch incrementally. This will avoid something called long-lived branches.

Problem with Long-Lived branches

It is an anti-pattern mainly due to these reasons,

1. Leads to Merge hell. If the changes are large, it is very difficult to remember the context, resolve the conflicts, and merge safely to the main branch

2. It leads to longer and repeated QA cycles

If you want to read more about it, Refer: Long-lived branches with Gitflow | Technology Radar | Thoughtworks India

How it works

1. All the PRs / commits will be merged directly to the main branch and gets auto-deployed (using CI / CD pipelines) to the Development environment

2. Once we plan for the release, we can take a Release Branch in the Semantic versioning format. eg: 1.45.0 and this gets deployed to the Pre Prod environment

3. We will do the testing in Pre Prod environment and when the build is good to go, we can promote the same artifact (1.45.0) to the Production environment

4. This branch 1.45.0 is freezed and only Hotfixes are allowed. All the new functionalities will get merged into the main branch.

5. At any point in time, we will know what version is running in Production. This will be very helpful in reproducing the issue. Eg:

   Service	Version
   frontend	1.51.0
   backend	1.32.0
   workers	1.25.0

   Advantages of this Strategy

1. We need to maintain only one long-lived branch - main

2. Resolve fewer merge conflicts

3. Encourages CI / CD, Test Automation, and small or fine-grained commits

4. Rollback / Hot fix is much easier

   When to use this Strategy

   1. If your team has a proper CI / CD setup

   2. There is a proper pre-production environment, and too many Hotfixes will not happen in Production

   3. The team is following Agile principles and wants to release the code to Production frequently

EzyInfra.dev – Expert DevOps & Infrastructure consulting! We help you set up, optimize, and manage cloud (AWS, GCP) and Kubernetes infrastructure—efficiently and cost-effectively. Need a strategy? Get a free consultation now!