Introduction
Today, how can we talk about software development without mentioning Git? A good version control system is essential for ensuring an efficient workflow. Git is the quintessential version control tool and is the most popular. Nevertheless, with Git, various strategies have developed to structure and manage the flow of changes in the codebase. Among all these strategies, today we’ll focus on two: Trunk-Based Development (TBD) and Git Flow.
On one side, we have TBD, a minimalist approach that advocates working directly on a common trunk, in other words, the main branch. While Git Flow, on the other hand, proposes a more complex structure, with dedicated branches for features, fixes, versions, etc.
Both approaches have their advantages and disadvantages, their own complexities and simplicities, and that’s what we’re going to explore now.
The objective of this article is not simply to provide an explanation of these two version management strategies, but rather to demonstrate why, in many contexts, TBD can prove to be a more optimal approach than Git Flow.
Git Flow vs Trunk-Based Development
The Git Flow Strategy
Git Flow is a popular version management strategy designed to help teams manage complex developments, leveraging the power and flexibility of Git branches. It offers an organized structure that facilitates parallel development of different features and version management.
Organization
With Git Flow, we organize our branches as follows:
- main, the main branch that represents the current state of production
- develop, the branch where all features, fixes, and other changes for the next planned version are located
- feature/xxx, branches created from develop where the code for a feature is located and will be merged with develop once development is complete
- release/xxx, branches created from develop where the code for a new software version is located, potentially refined before deployment
- hotfix/xxx, branches created from main for critical fixes discovered in production. These branches are merged into main as soon as the fix is ready and are also merged with develop to ensure the fix persists in the codebase
The Problems with Git Flow
The strength of Git Flow lies in its structure, which allows for easy management of parallel tasks and tracking of code evolution over time.
However, this strategy comes with a set of drawbacks:
- Complexity — This strategy requires a lot of manual branch manipulation, demanding complete mastery of Git and this process
- Complicated continuous integration — Continuous integration is more complex to set up due to parallel development on multiple branches
- Costly frequent deployment — Continuous/frequent deployment is not impossible but requires much more time and energy
- Merge problems — The significant number of parallel branches leads to many potential merge issues
- Difficult code reviews — Pull requests tend to be larger with Git Flow because they contain complete features. Feature branches tend to live too long, requiring frequent merges with develop, which causes delays in the delivery process
The Trunk-Based Development Strategy
The Trunk-Based Development strategy is a much more minimalist approach aimed at simplifying the workflow by minimizing code fragmentation and facilitating continuous integration. To achieve this, we only work on a single main branch (main or trunk), also known as the common trunk.
A Single Source of Truth
With TBD, this means that all code modifications are introduced and merged directly into the main branch. Each developer must therefore merge their changes regularly, several times a day. As a result, versions are managed directly from the main branch, each developer is constantly up to date, and merge problems are considerably reduced. The development cycle is faster and fuels continuous integration and deployments.
What About Branches?
Working with the TBD approach doesn’t mean we no longer have any branches besides the main branch. Indeed, branches can still be used, but they must be very short-lived and merged as soon as the work is completed.
What About Code Reviews?
Regardless of the adopted strategy, the code review process persists and remains an essential component to ensure the quality of the code that is merged into the common trunk. The subtlety between the two strategies is that with TBD, as changes are frequently merged, they are generally smaller. And if the changes turn out to be significant, then TBD emphasizes collaboration and would require making these changes through pair or mob programming. Finally, code reviews should be handled quickly (within half a day) and should only last a few minutes (about 15 minutes maximum).
What About Significant Changes?
TBD doesn’t prevent the development of important features that require substantial code modifications. However, this strategy promotes collaboration through pair or mob programming, but that’s not the only solution. There are also Feature Flags.
A Feature Flag is a software development technique that allows hiding, enabling, or disabling a feature in a production environment without having to redeploy the code. This technique offers real-time control over features, represents a safety measure against potential issues with new features, and, most importantly, allows working on new features directly in the main branch without interrupting the normal operation of the application.
In the context of the TBD approach, where all modifications are made directly on the main branch, the use of Feature Flags allows merging code for new features that are not yet completed or tested. The feature can be developed and merged into the trunk without being exposed to users until it’s ready, at which point the Feature Flag can be activated.
The use of Feature Flags brings considerable flexibility to the development process and is an essential component for achieving continuous deployment and an efficient workflow in TBD.
But what does it look like in practice? They are nothing more or less than booleans:
const featureFlags = {
enableNewFeature: true,
enableBetaFeature: false,
enableFeatureDashboard: false,
// ...
};And in use, for example for React (but the principle is the same for any environment):
function Page() {
if (featureFlags.enableNewFeature) {
return <NewFeatureComponent />;
}
return <OldFeatureComponent />;
}It is entirely possible to set up a system of Feature Flags that can be controlled remotely via a back office, or using ready-to-use tools such as Firebase Remote Config, PostHog, or Harness.
Prerequisites
For an effective implementation of TBD, several elements are generally required:
- Continuous Integration (CI) — This strategy greatly benefits from CI, given that it is often called upon for small modifications. CI ensures that the common trunk is always in a functioning state and continues to be deployable at any time.
- Automated tests — Automated tests go hand in hand with CI. If properly implemented, they ensure code quality.
- Code reviews — As mentioned previously, code reviews are an essential component for maintaining quality and knowledge sharing.
- Feature flags — As explained earlier, it is important to know how to set up feature flags because they are often used.
- Culture of collaboration — The entire team must be involved, know, and apply this process. The team must also take responsibility and be ready to collaborate closely and share knowledge.
Let’s Summarize the Benefits
- Continuous Integration (CI) — Thanks to the frequent integration of small changes, problems are detected and resolved more quickly, limiting potential merge conflicts.
- Faster deployments — With a single main branch always ready to be deployed, TBD facilitates faster and more regular deployments.
- Process simplification — TBD eliminates the need to manage numerous long-term branches, simplifying the team’s workflow.
- Code quality — Regular code reviews help maintain code quality and anticipate problems.
- Flexibility thanks to Feature Flags — Feature Flags allow testing new features in production without exposing them to end users, contributing to a safer and more controlled launch.
What About the Drawbacks?
- Rigorous merge management — Changes must be continuously merged into the common trunk, requiring developers to frequently synchronize their work to avoid conflicts.
- Culture — For some teams, adopting this strategy may require a significant change in their work practices, particularly around continuous integration and constant code reviews.
- Risky deployments without adequate testing — Without adequate test coverage, the risk of introducing bugs into production may be higher.
- Complexity of Feature Flags — While Feature Flags offer more flexibility, their management can add complexity. Misuse can lead to technical debt.
Despite these challenges, it is generally recognized that the benefits are worth the effort required to implement TBD. As with many things in life, it’s important to determine if this strategy is suitable for the specific context of your team and project.
DORA Metrics and Trunk-Based Development
The DORA Metrics (DevOps Research and Assessment metrics) are a series of performance measures for software development teams:
- Mean Lead Time for Changes (MLTC) — The average time it takes for a commit to go to production.
- Deployment Frequency (DF) — How often an organization deploys code to production.
- Mean Time to Restore (MTTR) — The time it takes to recover from a production outage or incident.
- Change Failure Rate (CFR) — The proportion of deployments causing a production incident or service failure.
TBD is closely related to DORA Metrics because it encourages shorter integration and deployment cycles, which can accelerate deployment time and increase deployment frequency.
- MLTC and DF — Frequent merging of small changes helps reduce deployment cycle time and increase deployment frequency, as the main branch is always in a deployable state.
- CFR — With regular code reviews and automated tests, the percentage of failed changes is expected to decrease.
- MTTR — As problems are generally smaller and more localized, it’s usually possible to fix and restore service more quickly.
In summary, Trunk-Based Development is well-aligned with improving DORA metrics, making it a strategy of choice for DevOps-focused teams.
Conclusion
This article has thoroughly examined the Trunk-Based Development (TBD) strategy, comparing it to Git Flow and highlighting its numerous advantages. We have analyzed how TBD promotes faster development cycles, better code quality through constant code reviews, and greater flexibility through the use of feature flags. We have also explained how TBD facilitates achieving high performance according to the DORA Metrics.
However, TBD is not without challenges. It requires rigorous merge management, a significant cultural change in some teams, and good test coverage to minimize risks associated with constant deployment.
In conclusion, TBD is a powerful model that can accelerate value delivery, improve code quality, and promote continuous optimization of team performance. However, as with any strategy, its adoption should be preceded by a thorough evaluation of the team’s specific needs, contexts, and capabilities.