In the early days of software development, programmers did not have the luxury of sophisticated version control systems. Instead, they created two versions of their programme concurrently to track changes and, if required, reverse them. This procedure proved to be labour-intensive, expensive, and inefficient over time.As version control systems evolved, several development approaches arose, allowing programmers to detect defects more readily, write in tandem with their colleagues, and speed release cadence. Most programmers use one of two development approaches to build high-quality software: Gitflow or trunk-based development.
There are two ways in which developers can work together using version control.
- Feature branch - Developers create a branch from the main or mainline and then work on that branch in isolation until the feature is entirely developed. This is then merged back into the main or mainline.
- Truck Based Development - Developers divide their work in various small tasks/batches and merge their work at least once a day. We will take this up in below in detail
What is Trunk-based development?
Trunk-based development is a software development strategy where engineers incorporate small changes to a core codebase.
Trunk based development is a branching model where a developer makes regular changes to the Trunk or main or master branch directly. This phenomenon minimizes the situation of merge-hell and prevents release branches from bugs. Suppose a new code needs to be added to the main code, so a developer needs to follow the below steps:
- Take the feature branch from the main branch.
- Make necessary changes.
- Build and test the changes.
- Generate merge requests to the main branch.
- A release engineer will approve a merge request to the main.
- Delete the feature branch.
Trunk Based Development enforces CI/CD(Continuous Integration and Continuous Development) at its full potential. The focus is on feature branches and code review practices, aiming to maintain excellent quality and collaboration.
How is Trunk-Based Development implemented?
For Small teams
A single developer or pair of developers can directly commit to Trunk after build.
For Scaled Trunk-Based Development
Introduction of short-lived feature branches. As the code base scales and the team grows, the merge conflict situation also scales up. In this situation, developers create feature branches and work on them, generate pull requests, and integrate them to master or trunk after code-review and build.
What are the benefits of Trunk Based Development?
Work with the master branch directly.
The TBD phenomenon stands over short-lived feature branches, which are extracted from the master itself and will ultimately merge into the master branch after the successful build of new code. This enables you to work directly with the master branch.
Continuous Integration
The main benefits of trunk-based development are that it enforces Continuous Integration, Code review and smooth code releases.
Reduce Merge-Hell
TBD prevents merge-hell situations by providing developers with the potential to merge new work to the main branch directly. The code is still not to be merged to production until they have passed the build stage.
Production-ready code
Allow continuous code integration to the main branch. As the code went through different pipeline stages, the code is now reliable enough to do the production.
More visibility of features
Small feature development gives greater visibility of features being developed.
Fast delivery of features
Expressway of delivering new features more frequently.
What are the best practices for implementing Trunk Based Development?
- Development should be done by using the master or trunk branch.
- Create a feature branch from the master or trunk branch.
- Should always use feature branches for small feature development.
- Remove feature branches after serving the purpose.
- Feature branch must be merged directly with the master.
- Code must be merged to the main branch only after passing the test and build.
- The complete code can be merged with the master branch only if the build and test stages are passed.
- Merge must be unidirectional, i.e. from feature to master. Avoid merging from release to master.
- No one can commit code in the release branch. Only the release manager should generate release branches from the master branch.
Difference between Git-Flow and Trunk based development
Properties
|
Git-Flow
|
Trunk Based Development
|
Philosophy
|
Keep development far from the main branch.
|
Keep development as close as possible to main branch
|
Working principle
|
Create feature branches from the main branch, when work is done, the developer creates pull requests, other developers comment on the changes and may have discussions.
|
Create a feature branch from the main branch, when work is done, the developer directly merges code in the main branch after passing build and test.
|
Release frequency
|
Review code is sometimes a very time consuming process which results in slow releases.
|
TBD is used where frequent releases are required.
|
Restrict Access
|
Users are restricted to branch access.
|
No restriction over branch access.
|
Life of Feature branch
|
Long lived feature branch
|
Short lived Feature branch
|
CI/CD
|
Different deployment methods used.
|
Enforces CI/CD best practices for quick releases.
|
Application
|
- Work best when running an open-source project and large enterprise companies.
- When working with juniors in a team, you need to review their code before merging into the main branch.
- When you have your product, you need to review every code closely.
|
- When you are just starting up the project.
- When you need quick features.
- When you work with senior developers, you trust their work
|
Who is using Truck Based Development?
Trunk based development is not a new idea but is gaining more popularity recently. In past, these practises have been given various names like, 'Software Configuration Management', 'Version control systems' which is evolved to simple 'Source Control'.
Big IT giants like Google, Amazon and Facebook have successfully adopted the TBD approach in their companies. A small team lowers the cost of software development. This is because engineers now have to maintain only the master branch and other branches have a limited period. As a result, it helps in minimizing merge conflicts. Due to its lightweight workflow, TBD is highly recommended by the software development community.
Conclusion
Trunk based development has drastically improved how we use version control systems in the software development process. Now developers have more transparency as they can work directly over the master branch. This concept also enforces the use of CI/CD efficiently to get the full benefits of TBD. This approach will benefit organizations to produce high-quality code at a higher pace. This also brings confidence as the code is always production-ready. If you want to take TBD at an advanced level, you can use feature flags. But you should keep in mind that you must know the use cases where Trunk-based development brings you joy and where it can put you in trouble(Use Git flow instead).
What's Next?
- Measure Your Team's Software Delivery Performance with DORA Assessment
- Read how Nexastack is enabling Continuous Delivery
