Trunk-based development

The content here is under the Attribution 4.0 International (CC BY 4.0) license

The advent of Git revolutionized software development, paving the way for new methodologies to emerge. Among these is Gitflow, a branch-based development model that gained popularity for its structured approach. However, Gitflow’s reliance on long-lived branches introduces challenges, particularly around integration, feedback cycles, and the timing of deployments.

Trunk-Based Development (TBD) offers a contrasting methodology that flips the script. Unlike Branch-Based Development, TBD minimizes the use of long-lived branches, keeping developers close to the “source of truth”—the main trunk. By doing so, it reduces integration conflicts and accelerates feedback loops. This approach fosters a culture of continuous integration and collaboration, enabling teams to deliver value to production more frequently and with fewer bottlenecks.

The key advantage of TBD lies in its simplicity and efficiency. By avoiding the complexities of managing multiple branches, teams can focus on delivering incremental changes directly to the trunk. This not only reduces the risk of merge conflicts but also ensures that the codebase remains stable and up-to-date. Additionally, TBD encourages the use of feature toggles, allowing developers to integrate work-in-progress without disrupting the main codebase. This practice supports faster iterations and provides the flexibility to enable or disable features as needed.

In essence, TBD aligns with the principles of agile development, emphasizing adaptability, collaboration, and rapid feedback. It challenges traditional workflows by prioritizing integration over isolation, making it a powerful approach for modern software development teams aiming to stay competitive in a fast-paced environment.

In the next section let’s explore in detail the challenges of Gitflow and how TBD can help to overcome them.

Part I

Git flow

Git flow is a branching model for Git, created by Vincent Driessen. It defines a strict branching structure and workflow. It provides a structured fashion to integrate the work done by different developers. The main idea is to have a main branch (master) and a develop branch, where all the features are integrated. The develop branch is used to integrate the work done by different developers, and the master branch is used to release the software.

In the git flow, the release is done branching off the develop branch, and the release branch is used to prepare the release. The release branch is used to fix bugs and prepare the release. Once the release is done, the release branch is merged back into the develop branch and the master branch.

The problem with git flow

Git iterativo

Part II

Deployment all or nothing

Conflicts

Part III

Feature toggles

Toggles are a developers’ new best friends as they enable the incorporation of changes without a big bang release. Additionally, toggles facilitate continuous integration of work in progress, becoming a crucial turning point in one’s feature development approach.

Various third-party tools are available to enable developers to toggle features on/off seamlessly; however, the tried-and-true method of using old plan environment variables can also be used.

The trick is to always start with the toggle off. In fact, pushing just the set of the toggle is a good initial step. The second step involves confirming if it works as expected and iterating from there.

pros

• continuous deployment
• avoid conflicts

cons

• third party
• toggle management
• code clean up

Types

• release
• ops
• permissions

Part IV

The practice

The practice of trunk-based development is simpler than it seems, however, the history of software development and its complexities have inluences developers to think about gitflow and complex wrkflows to avoid mistakes. However, a better workflow than trying to avoid mistakes when making changes is to use a workflow that allow for changes to be integrated as fast as possible.

Small Batches More Often

Toggles offer a more agile approach to work: once the toggle is set and working, changes are integrated faster and without fear of breaking things, or breaking things in a much more controlled way. You have the option of enabling the toggle for only a few users if needed. TBD facilitates a reduction in batch size, ensuring a smoother flow of work throughout the development process.

As the entire team works mainly on the same branch, the potential risk of conflicts increases. To mitigate this issue, consider pushing smaller chunks of code and pulling more often. Also, keep in mind that communication among team members is important. Just by trying to avoid coding on the same piece of code at the same time you can reduce the likelihood of encountering of unwanted conflict and merging.

Having a lot of developers working on the same codebase can also create conflicts. Consider splitting the teams and/or the applications in microservices or smaller packages if needed.

Constant Work in Progress

Constant work in progress is the prevailing Modus Operandi for TBD. There is no perfect time to integrate changes or push things to production. By following this philosophy, teams no longer require code freezes to meet and review large changes - therefore eliminating any downtime associated with integrating new modifications.

Demos and user input can take place directly in the production environment, where it truly matters.

Monitoring

When it comes to monitoring, logging is essential. It allows you to monitor any spikes and mitigate any potential issues that may arise while doing TBD. Logging should be a fundamental aspect for any application, but it becomes even more critical in the context of TBD.

Real-time logs: provide instant feedback, but while querying or tracking is not possible, it offers a grasp of what is happening. Lagging logs: serve as the ideal place for conducting queries, looking at what happened and taking on the role of an investigator.

Getting Closer to Pure TBD: Short lived branches A short-lived branch is a temporary branch created for a specific task, intended to live less than a feature branch and to be pushed by the end of the day. While the primary focus of pure TBD is to push directly to trunk, these short-lived branches can be useful for testing, bug-fixing or saving work at the end of the day or when switching roles during pairing sessions. If needed, these branches can be merged back into the trunk by creating a “pull request.”

The key aspect of this practice lies in the size of the branch’s file before it is merged and eventually deleted due to its staleness. As a rule of thumb, they should never live longer than 48h, as extending their lifespan can convert them into feature branches, which contradicts the main objective of TBD. Typically, 1 developer (or 2 when pairing) should be responsible for contributing to these branches.

It is ok to merge code from the trunk to the branch to bring them closer, but merging the branch back into the trunk should be regarded as the final step in completing that small feature. Once this merge is done, the branch should be deleted.

The culture

Are you ready?

First and foremost, it would be best to reach specific agreements with the team to have TBD running and adopt the following practices. After all, if the team is not happy, it will most likely fail.

No fear: TBD’s basis is having a culture suitable for a fast-changing environment, so ideally, the team should have a no-blame culture to avoid developers feeling afraid of breaking things due to change. Working software comes first: this means no power-points, no recordings, no talk - the code is the source of truth and demoing it often and anytime is more valuable than any recorded presentation No perfectionism: focusing on perfection will be a considerable workflow blocker. Plus, it leads to later integration (something that will become perfect in the future). Change “my” to “our”: the mindset of working on my story, my feature, my branch establishes an invisible threshold between my responsibility and others’ responsibility. TBD fosters a team culture where everyone contributes to a common goal through collective code ownership. Automation A Trunk-Based Development environment is characterised by having a trustworthy CI/CD pipeline in place. This will allow the team to find issues earlier in the development process due to the shorter feedback loop. Not to mention that automation facilitates rapid change across the code base, making the process more efficient. Without automation, the TBD process becomes more challenging and less impactful.

In the cloud era, opting for a blue-green deployment for TBD is highly recommended, although other approaches, like canary also, are effective as well. The ultimate goal is to establish a secure environment for continuous releases, ensuring a smooth experience for end users without disruptions.

Challenges for Practitioners

Despite the hype surrounding TBD and the numerous benefits it offers to agile teams, resistance to shift still persists.

Over the past decade, developers have been ‘‘trained’’ to adhere to different environments in order to complete several tasks, such as development, quality assurance, and production. When presented with the option of switching to TBD, some resistance inevitably arises, as the fear of impacting production affects all developers no matter their domain. This highlights the importance of considering the human aspect of software development, especially in fast-paced, ever-changing environments.

Extreme Programming, with its set of values, provides the necessary foundation for high-performance teams. When Kent Beck, creator of XP, released the second edition of the book, he introduced the value of respect, alongside feedback, simplicity, communication, and courage.

Many teams across the industry lack the courage and respect required to adopt practices like TBD. However, our advice is that if you ever get the chance to try and experiment with this approach, you should seize the opportunity to explore its potential.

References