Trunk-Based Development in Practice

By Sarah Sunday

Before I get into how trunk-based development works for us, I’ll direct anyone looking for a comprehensive primer and argument for trunk-based development to this Atlassian article. This article compares the two primary development flows and gives the benefits for using a trunk-based development flow. It’s a really great article.

As for what a trunk-based actually means to us in practice, it depends on the size of the team. What works for a few developers would not work on a team with many developers. So we have two flows, depending on the size of the team.

Regardless of team size, the development items should be reflected in some way to cards/statuses in the project management system (e.g. Trello or Jira). So, for example, moving something to staging has two tasks: actually deploying it and actually moving the card to a list/status that means it is in the staging environment. And releases be communicated to the rest of the team. Communication like that is a constant across team size.

What is impacted by the size of the team, however, is the git branching flow.

Smaller Team

With only a few developers, coordinating staging releases is simple. So it’s possible and preferred to only have two core branches as that reduces overhead.

Branches

• main - Development mainline and staging environment base.
• production - Reflective of the production environment.

Flow

• Pull Requests are based on main and point to main.
• Staging releases are made off of main.
• Production releases are made from main to production via pull request merge.
  • It can be direct, or it can be from a deploy branch (a branch off of main or the target called deploy-MM-DD-YYYY, for example). This allows pulling out commits or cherry-picking if necessary.

Larger Team

On a larger team with say five developers, having only two branches can become problematic and hard to maintain. So to handle a larger team, the flow is altered to include a staging specific branch to control staging releases and add an extra review step.

Branches

• main - Development mainline.
• staging - Reflective of the staging environment.
• production - Reflective of the production environment.

Flow

• Pull Requests are based on main and point to main.
• Staging releases are made from main to staging via pull request merge.
• Production releases are made from staging to production via pull request merge.

Like with the smaller team flow, deploy branches can be used to deploy only a subset of commits.

Conclusion

There’s always improvements to be made to any development flow, but this is a flexible flow that has been tested across various projects I’ve been on. It allows for quicker merges and a way to see production deploys and what code is on production just from the VCS view. This, coupled with maintaining the mirrored view in the project management board, creates clarity over where a development item actually is (i.e. is it being worked on or is it ready for review on staging). I personally prefer this type of flow to the alternatives for its simplicity and flexibility.