Trunk-Based Development

1. Overview

In this tutorial, we’ll learn about the trunk-based development approach in Version Control Systems (VCS).

First, we’ll explore the general concept, see how it’s different from the feature branch development model, the common characteristics involved, and the workflow to achieve it.

Then, we’ll discuss the different factors to consider while going for trunk-based development. Finally, we’ll see the pros and cons of using trunk-based development.

2. What Is Trunk-Based Development?

Trunk-based development is a source-control branching model, where the developers work on a single branch called ‘trunk’ or ‘mainline’ (‘master’ or ‘main’ in Git).

Since there’s no long-lived development branch in this model, merge conflicts are generally avoided, and the builds aren’t broken frequently.

In the trunk-based development approach, the developers mainly collaborate on the ‘trunk’. However, larger teams may use short-lived branches that can last no more than a couple of days.

Developers commit the code very often to push the latest copy in the trunk. Subsequently, the builds trigger automated tests, which help to minimize the integration issues at a later stage.

As we can see, this approach encourages continuous integration and works best for small agile teams.

3. Comparison With Feature Branch Model

Feature branch-based development is the most common approach the teams chose to practice. In this decentralized version control approach, the developers create long-lived dedicated branches from the main codebase to isolate the changes needed for a particular feature/improvement.

Once the code is ready and tested, the commit will be made to the respective branch. Finally, these branches will be merged back to the main code base after resolving the merge conflicts.

Here, the idea is to enable developers to work independently and commit the changes without affecting other developers or teams. Specifically, this can be useful in relatively large projects with multiple contributors and/or complex codebases.

4. Characteristics of Trunk-based Development

The trunk-based development approach has some common characteristics. These factors influence how effectively the developers work and collaborate between themselves. Let’s see them in brief.

4.1. Continuous Integration

In trunk-based development, all the developers work on a single branch (master/trunk). This enables faster code integrations, thereby reducing merge conflicts.

The developers integrate the code changes as frequently as they can instead of waiting for a large chunk of new code.

4.2. Small, Frequent Commits

Integrating small but frequent commits regularly avoids the risk of doing a big merge at a later stage. Subsequently, the merges will be much easier with relatively fewer conflicts.

Also, as the commits are more regular, the chance of introducing bugs is minimal. Moreover, it’s much easier to identify and resolve merge conflicts.

4.3. Test Automation

Test automation is an essential feature in the trunk-based development model. Since there are regular commits, we need to make sure that the builds aren’t broken. In addition, the new commits shouldn’t introduce regressions.

Increasing the test coverage helps to reduce the risk of regression and helps in fixing the identified issues quickly.

Moreover, these automated tests provide instant feedback so that the issues are resolved faster, which results in improved code quality.

4.4. Code Review

For each new commit, other developers review and provide feedback before merging the code to the main branch. This helps to improve the code quality and identify potential issues in advance. The timeframe to complete the code review needs to be defined so that it doesn’t delay the commits.

4.5. No Long-Lived Branches

Any branch that is longer than two days may end up becoming a long-lived branch. In trunk-based development, long-lived branches are avoided to prevent merge conflicts and allow faster integration.

5. The Workflow

Let’s see the major steps involved in the trunk-based development model.

5.1. Code Change

In the first step, once the code is ready, the developer commits the code directly to the trunk or a short-lived branch that was created from the trunk. Here, the rule of thumb is that everyone commits to the mainline every day.

More precisely, we should never have more than a day’s work sitting unintegrated in the local repository.

5.2. Pull Request

As soon as the code is committed, the developer creates a pull request to merge the new code with the main branch.

The pull request would contain the basic description of the change, the list of code changes, and any other relevant information.

5.3. Code Review

In this step, other developers review the code changes from the pull request. This step helps to identify the defects which could have escaped from the eyes of the original author.

Further, having this 4-eyes validation for the new code enforces the best practices for new developers.

5.4. Automated Testing

Trunk-based development relies heavily on automated tests. These tests include unit and integration tests that are triggered automatically when a pull request is created.

Automated tests prevent the new code changes from breaking the existing functionalities. More importantly, it gives the confidence that the new code works fine without affecting the old code.

5.5. Merging

After passing through the peer review and automated tests, the new code is ready for merge with the trunk. Since there’s no long-lived branch and the commit interval is short, we minimize the risk of merge conflicts.

6. Factors Influencing Trunk-based Development

Multiple factors have influence when choosing between trunk-based development and feature branch development.

Specifically, we should take care of the specific needs of the project and the development team involved. Both these development approaches have their advantages and disadvantages. However, the primary factors to consider include the complexity of the codebase, the actual development process, and the number of developers.

Let’s see what are the major pros and cons of trunk-based development.

6.1. Pros

• Speed and efficiency: As the team works on a single branch, Trunk-based development enables faster code integrations due to frequent check-ins, which results in fewer merge conflicts. As a result, the team can enjoy the speed and efficiency this model provides.
• Greater code stability: Frequent check-ins also help to detect and fix any code issues. As there’s no long-lived branch, we avoid the risk of bigger mergers. In other words, this results in greater code stability as we identify the issues earlier and fix them.
• Enhanced team collaboration: In contrast with the branch model, where the developers work on individual branches, trunk-based development fosters good understanding and better collaboration between themselves by providing more awareness of all the current changes.
• Continuous integration and delivery (CI/CD): By way of frequent commits, developers make sure that the code in the trunk is always the latest. While doing so, they make sure that the builds always pass, and in case of any failures, it’s addressed instantly. Subsequently, the code in the trunk will always be in a deployable state.
• Reduced technical debt: While working with long-lived branches, there are chances that the developers may go for quick fixes, which may result in new technical debt. In trunk-based development, with the help of frequent merges and smaller commits, we avoid big merges to reduce technical debt.

6.2. Cons

• Risk of breaking the build: Since the developers commit more often, there’s always a chance of breaking the build. When the build fails, we may need more time to fix it and make it pass again.
• Change isolation: There’s a risk of mixing two or more changes without testing those individual changes separately. The developer needs to be ready, always knowing the current codebase may get updated anytime.
• Release management: It’s difficult to maintain different codebases in the trunk. Thus, management of releases may become a headache if we need an intermediate release in between.
• Number of developers: If the developers are more in number, working on the trunk may be more challenging. The team collaboration may be affected if the process isn’t clear.

7. Conclusion

In this article, we had an overview of the usage of trunk-based development in modern software development.

Also, we discussed briefly the characteristics and workflow of the trunk-based development model. While on the subject, we also compared the differences between branch-based and trunk-based development.

Finally, we saw the benefits and drawbacks of using the trunk-based development. To conclude, trunk-based development is worth considering for teams that want to streamline their development process, improve team collaboration, and reduce technical debt.