When coding an application as part of a sizable software development team, it is important to remain in sync with the other engineers working on the project. This can prove to be a very difficult task, as some software teams can be quite large. One strategy that helps a team stay in sync with changes to the codebase is known as trunk-based development. When employing trunk-based development, the developers working on a project make all their code changes in a common branch known as trunk. There are numerous benefits to developing with this approach, ranging from fewer issues with conflicting code changes amongst team members, all the way to advantages for continuous integration.
No more long-running branches
Many development shops utilize long-running branches to allow their software engineers to develop, unbothered by the rest of the development team. For the sake of argument, let’s say one developer will be assigned to develop Feature 1 while another will be assigned to develop Feature 2. These developers will create a branch from the trunk codebase and then go forth to develop in their individual branch for weeks or even a month at a time before completing their work and merging their changes back in the shared branch, utilizing a source control tool such as SVN. While this certainly does work for some teams, it is easy to see the pitfalls of this approach. More than likely, after being out of sync with the trunk codebase for so long, changes have occurred within the main branch that directly conflict with the feature branches that were being worked on by the individual developers. This can create huge headaches for the developer when it comes time to merge a new feature back into the trunk codebase. Combine this with the risk for conflicting code to affect functionality and we can see that this practice can be dangerous.
It is with these potential pitfalls where we really see the value of trunk-based development. By adhering to the principles of trunk-based development, these long-running feature branches are no more. Instead, the developer working on Feature 1 and the developer working on Feature 2 would work in short iterations to write their code and commit their changes to the trunk branch, as often as several times per day. In doing so, they remain in sync with the developers working beside them. This can significantly reduce the amount of conflicts the developer has to resolve because they are no longer waiting such a long period of time to integrate their changes into the trunk branch. This approach also allows the developer to test their code against the code changes of other developers on the team on a more regular basis.
Advantages for continuous integration
Aside from the value trunk-based development provides in regard to merge conflicts, there is also major value as it relates to continuous integration. This should be considered when evaluating this approach.
Continuous integration (CI) involves developers merging their code frequently into a common branch that is then built and promoted to an environment that will contain the latest and greatest version of the application. Trunk-based development supports this practice as the developers will already be working in the shared branch to be built and promoted. The developers are then prepared at any time to merge and commit as often as they see fit. Oftentimes a CI tool such as Jenkins or CircleCI is then configured to build the project post-commit, and deploy to the environment designated to hold the latest and greatest version.
Trunk-based development will ensure that this process occurs more often than if the developers were working in their own long-running feature branches. With this, developers will be more aware of issues with their code. Does their code break the build when integrated into the shared branch? Are there issues with the most up-to-date version of the application once the feature is merged into trunk and deployed for testing? These questions are important to answer as early as possible to avoid major issues that may require significant refactoring down the road, and they can be easily answered by employing a strategy of trunk-based development.
Conclusion
The current world of application development often calls for a fast-paced development cycle that gets quality products out the door. And it is the job of the DevOps organization to provide that environment. Trunk-based development can assist a DevOps organization in their ability to do this. By working in trunk and frequently integrating their code changes, the developers will become a cohesive unit that responsibly implements features with respect to those coding alongside them. Early detection of major issues and conflicts will become standard practice, and will allow for quick resolutions that don’t slow the development process, while also supporting the successful practice of continuous integration—and all of this is a benefit of simply staying in sync.
