What Is Trunk Based Development? | TeamCity CI/CD Guide

With trunk-based development, you commit changes directly to the master branch (aka trunk), rather than developing features or bug fixes in separate branches and merging them to master at some later stage.

Committing changes to the master branch triggers the CI/CD pipeline. If the pipeline flags up any failures, it is everyone’s responsibility to jump in to try and fix it as soon as possible. The aim is to keep the master branch in a deployable state, with changes being released frequently.

If you’re already familiar with the principles of CI/CD, you probably recognized from the foregoing description that trunk-based development is a good fit for continuous integration and deployment. As long as everyone on your team commits their changes regularly, you get the benefits of visibility of everyone’s changes and regular, rapid feedback on what is being built.

The primacy of keeping the master branch healthy and in a releasable state encourages everyone to add tests for their changes as they go. Monitoring test coverage metrics will help you keep an eye on this, while ensuring everyone builds locally (perhaps also running a basic set of automated tests) before committing will reduce the number of issues found on master.

Some advocates of trunk-based development argue that it is the only way to achieve continuous integration, and that use of development or feature branches only undermines the benefits of CI/CD. However, trunk-based development also has its downsides.

While it is a great fit for continuous deployment, where code changes that pass all stages of the pipeline are released automatically, the model works best for SaaS products, where there is a high tolerance for – and even an expectation of – continuous updates.