Understanding the Trunk-Based Development Workflow

If you've been working with Git for a while, you're probably familiar with git-flow or perhaps even the "GitHub Flow." These workflows typically involve creating feature branches that can live for days or even weeks before being merged back into the main branch.

While these approaches certainly have their merits, they can sometimes lead to integration challenges and delayed feedback cycles. This is where Trunk-based Development comes in!

What is Trunk-based Development?

Trunk-based Development (TBD) is a source-control branching model where developers collaborate on code in a single branch called "trunk" (traditionally the main or master branch in Git).

The key principle here is simple: keep your changes small and merge them frequently into the main branch.

In its purest form, developers commit directly to the trunk. However, most teams opt for a slightly modified approach where they:

1. Create short-lived feature branches (usually lasting no more than a day or two)
2. Merge these branches back into trunk as quickly as possible
3. Delete the feature branch once it's merged

The emphasis here is on "short-lived" — these branches should be merged within hours or, at most, a couple of days. Any longer than that, and you're not really doing Trunk-based Development anymore!

Why Should You Consider Trunk-based Development?

We've already hinted at some of the benefits of this approach in the introduction, but now let's take a closer look at all the advantages of this workflow:

1. Reduced "Merge Hell": Since changes are integrated frequently and in small chunks, merge conflicts become less frequent and easier to resolve.

2. Faster Feedback Cycles: Your code gets reviewed and tested more quickly, allowing you to catch and fix issues early in the development process.

3. Better Collaboration: Everyone works off the same, up-to-date codebase, making it easier to share code and avoid duplicate work.

4. Simplified CI/CD: With all changes going into a single branch, your CI/CD pipeline becomes more straightforward and efficient.

Despite these advantages, it does not necessarily mean that TBD is the best Git workflow for you and your team. We will explore some of the drawbacks in the next section.

But first, let's address a question that might have come to your mind in the meantime...

What About Unfinished Features?

Since this approach focuses on merging code back into the "trunk" as frequently as possible, you might be wondering:

What happens if I'm working on a feature that's not ready to be released yet? 🤔

This is where "feature flags" (also known as "feature toggles") come into play! Instead of using long-lived feature branches to hide incomplete work, you can use feature flags to control which functionality is available to users.

Here's a simple example in PHP:

if (FeatureFlags::isEnabled('new-upvotes-feature')) {
    // New upvoting functionality
    return $this->newUpvotingSystem();
} else {
    // Old functionality or fallback
    return $this->currentUpvotingSystem();
}

This way, you can merge your code into the trunk branch while keeping it hidden from users until it’s ready for release. When the feature is complete and thoroughly tested, you can simply flip the switch!

Is Trunk-based Development Right for Your Team?

While TBD offers many advantages, it's not necessarily the best fit for every team. For example, if you’re working on an open-source project, this approach will not be effective, as you need strict control over changes and cannot fully trust contributors.

The decision should be based on a careful evaluation of your team's skills, processes, and objectives. Here are some questions you should ask yourself:

1. How Experienced Is Your Team?

Your team will be pushing code into the trunk branch very frequently. If you constantly need to supervise and review each merge, a workflow based on feature branches could prove preferable. Frequent integration and quick conflict resolution can be overwhelming for teams with a high proportion of junior developers.

2. Where Does Your Team Stand in CI and Test-Driven Development?

Your team should be comfortable with Git and modern development practices. TBD thrives in environments with good test coverage and automated CI/CD pipelines, as these systems are crucial for maintaining a stable main branch.

If your organization aims to move towards true continuous integration, TBD can be an excellent catalyst for this transition. However, without a comprehensive suite of automated tests, the risk of introducing bugs into the main branch increases significantly.

If your team doesn't have good automated testing in place, it might be wise to focus on improving this aspect before transitioning to this workflow.

3. What About Feature Flags?

Another key factor is your team's willingness to embrace feature flags. These allow for greater control over feature releases and are often essential in a trunk-based workflow.

Teams that are open to incorporating feature flags into their development process are better positioned to succeed with TBD.

4. How Is Your Product's Release Cycle?

If you're developing applications with inherently slow release cycles, such as mobile apps requiring app store approval, the benefits of TBD may be less pronounced. The rapid integration and deployment capabilities of TBD are most advantageous in environments where frequent releases are possible and desirable.

Transitioning to Trunk-based Development

Transitioning to this new workflow can seem daunting at first. If you decide to give TBD a try, here are some tips to help you get started:

1. Start Small: Begin with shorter-lived feature branches than you're used to, gradually reducing their lifespan. As your team becomes more comfortable, you can further reduce branch lifespans until you're working directly on the trunk for most changes.
2. Invest in Automation: As we have discussed, good automated testing is crucial for the success of trunk-based development. Prioritize building a comprehensive suite of unit tests, integration tests, and end-to-end tests, and implement a robust CI pipeline that runs these tests automatically on every commit. This safety net will catch potential issues early, giving your team confidence to integrate changes frequently.
3. Use Feature Flags: Implement a feature flag system and train your team on how to use it effectively. This approach enables you to decouple code deployment from feature release, giving you more control over your product rollout. They're essential for managing incomplete features in production.
4. Communicate: Make sure everyone on the team understands the new workflow and its benefits. If needed, hold training sessions to explain the principles and benefits of trunk-based development, the importance of small, frequent commits, and how to use feature flags. Sharing this blog post would be a great starting point! 😉

I advise you to stay patient during the transition period, celebrate small victories, and keep the lines of communication open. With time, your team will likely find that trunk-based development leads to a more efficient, collaborative, and productive development process.

Final Words

As more teams adopt DevOps practices and aim for true Continuous Integration, Trunk-based Development is likely to become even more popular. While it might require some initial adjustment, the benefits of reduced merge conflicts, faster feedback cycles, and more frequent releases will become apparent as your team grows more proficient with this workflow.

If you try this workflow, please let us know how it worked for your team!

We hope you found this post helpful! For more Git tips, don't forget to sign up for our newsletter below and follow Tower on Twitter and LinkedIn! ✌️