Trunk-Based Development

Hello everyone!

We usually use some git flow as a development strategy in our teams. Normally 3 branches:

• main or master
  • Code running in production
  • Protected
  • Usually used only for deployment, as all tests were done on the staging branch.
• staging or release
  • Code running in staging environment (pre-production)
  • Protected
  • Used for functionality tests in real conditions, bug and problem detection, configuration validation, integration testing, load testing, etc.
• develop
  • Sum of new features from all teams and hotfixes found in production.

We usually have a flow similar to this which is the idea of gitflow and very well accepted nowadays.

But have you heard of the Trunk-Based Development (TBD) strategy?

Trunk-Based Development (TBD) is a software development strategy where all developers collaborate on a single main branch (usually called "trunk" or "master/main") and make frequent commits directly to it.

Requires much more concentration and rigor and therefore a refined CI pipeline on the trunk is recommended.

In the case of open source projects, developers cannot create branches in the repository where we have the trunk. The developer is forced to create a fork of the project and then, when their contribution is finished, create a PR trunk to trunk or keep their fork updated with the main project's fork and develop in a branch in their repository and request to create the PR.

Developers working in their own repositories don't break the build with any commit. It's the developers' job to assume the habit of proving the commit is good.

In a business project we can create branches in the same repository for feature development and make a PR directly to the trunk.

A work is only considered complete if it's merged into the main project's trunk.

New branches will be created by repository maintainers for a release branch that will live for a short period. This branch will be replaced by another release branch in the future, or not if you want to keep the history depending on the project.

There's no well-defined rule, I've seen cases where only tags are created for markings without release branches.

It's still possible that there's only one trunk branch and that's it, everything depends on the type of project.

If using release branches, a bug must be fixed in trunk and merged to the release branch only by maintainers.

Working with TBD in Git requires a disciplined development culture, with practices such as code reviews, rigorous automated tests, and good team communication, but the benefits in terms of quality and delivery speed can be significant. A robust pipeline is extremely necessary.

Advantages

• Continuous and Rapid Integration: Since everyone is working on the same branch, changes are integrated frequently, which helps detect integration problems quickly. This reduces the risk of unpleasant surprises at the end of the development cycle.

• Simplicity in Version Control: With fewer long-lived branches, repository management becomes simpler and easier to maintain. This reduces the overhead of complex merges and difficult conflicts to resolve.

• Fast Feedback: Changes are tested and integrated continuously, allowing problems to be identified and fixed quickly. This accelerates the feedback cycle and increases code quality.

• Facilitates DevOps and Continuous Delivery: TBD is a practice that aligns well with DevOps practices, such as Continuous Integration (CI) and Continuous Deployment (CD), as code is always in a ready-to-deploy state.

• Reduction of Long Branches and Merge Conflicts: Since the focus is on frequent commits to the main branch, you avoid creating long-lived branches that can cause large merge conflicts. This also reduces the possibility of "merge hell".

• Encourages Collaboration: TBD encourages collaboration and frequent communication among team members, as everyone is constantly reviewing and integrating each other's work.

• Agility in Bug Resolution: Bugs can be fixed quickly, without the need to cherry-pick or backport to other branches, as code is centralized.

• Greater Transparency and Visibility: With everyone working on the same branch, it's easier for all team members to have visibility of the project's current state.

Disadvantages

• Risk of Instability in Main Branch: Since all developers are making frequent commits to the same branch, there's a greater risk of introducing bugs or problems that affect the entire team. This can cause instability, especially if tests aren't rigorous.

• Greater Need for Discipline and Best Practices: The team needs to have rigorous discipline regarding practices such as code reviews, automated tests, and quality control. I recommend using sonarqube to help in the quality process.

• Complexity in Large Teams: It can be difficult to coordinate and manage work without frequent conflicts occurring with people working on the same point of code.

• Dependence on Strong Automated Tests: TBD heavily depends on a robust automated test suite. If tests aren't comprehensive enough or if there are false positives/negatives, these will be integrated into the main branch.

• Less Feature Isolation: In methodologies using feature branches, new features can be developed and tested in isolation before being integrated, not in TBD's case.

• Difficulty in Managing Releases: In projects where there's a need to manage multiple simultaneous versions or releases, TBD can be more challenging, as all changes go directly to the main branch. This can complicate the creation of hotfixes or previous versions. Not highly recommended for this scenario.

• Learning Curve: For teams accustomed to working with long-lived branches and traditional merges, the transition to TBD may require a significant change in mindset and work practices, which may take some time to adapt and larger onboarding and more training from the company.

• Less Flexibility in Development Cycles: In scenarios where certain features need to be released separately or on different timelines, the TBD approach is not well adapted.