Git

Trunk-Based Development: An approach to shortening the Time-To-Market

This blog post shows why you should look at Trunk-Based Development technique and why you should use it to shorten the time-to-market for new features.

Photo by Austin Distel / Unsplash

Table of Contents

The story behind
Why the classic GitFlow probably *increases* the Time-To-Market
What is Trunk-Based Development?
What are the benefits of introducing Trunk-Based Development in my team?

The story behind

We're developing a new system with one of my customers. We have launched the first version of the product.

As I write this blog post, we're discussing on the team how we handle various releases and hotfixes on Git.

Over the past 6 years of working in product development as a technical lead, software architect, and software engineer, I've experienced the same thing over and over again: the need to shorten time-to-market for new features.

It's really difficult to explain to non-technical stakeholders in the company what technical excellence is, how to reduce technical debt and so on.

So in the context described above, time to market is always important.

Time-To-Market is always important.

This blog post shows why you should look at Trunk-Based Development technique and why you should use it to shorten the time-to-market for new features.

❗

Disclaimer: This content is highly opinionated.

Why the classic GitFlow probably increases the Time-To-Market

In the past, I've often worked with the classic GitFlow (or various manifestations of it). It postulates different types of branches:

develop (current working release)
main (release in production)
release/x (current & past releases)
feature/x (isolated feature development)

More or less the classic GitFlow from the following illustration:

In this branch strategy, you often work on long-lived feature branches and then create a merge/pull request for the develop and/or corresponding release branch and have a dogmatic or epic asynchronous code review discussion about tiny implementation details.

After your teammates approve the changes, you can bring them into the development branch, and in some scenarios probably backport them into release/x and release/y.

This approach often leads to the following drawbacks:

Complexity in branching and merging
A lot of concurrently living working branches (which increase over time)
Long-lived branches often lead to "merge hell"
Async-heavy code reviews (and large amount of discussion)

But where is the connection to time-to-market?

The classic GitFlow approach from above doesn't explicitly encourage or force you to put small batches of your product customisations into production.

Rather, it holds you back and gives you the opportunity to pack more features into the next release before deploying it into production.

This may increase the time-to-market of each feature.

Measure the status quo with the four key metrics of DevOps performance

So take a step back and measure your deployment frequency and stability.

A good technique to measure your status quo is the four key metrics of DevOps performance:

Deployment frequency: How often an organization successfully releases to production
Lead time for changes: The amount of time it takes a commit to get into production
Time to restore service: How long it takes an organization to recover form a failure in production
Change failure rate: The percentage of deployments causing a failure in production

At a high level, deployment frequency and lead time for changes measure speed, while change failure rate and time to restore service measure stability.

Elite Performance Teams deploy on demand which means multiple deploys per day (Source: 2019 State of DevOps Report)

And this is where Trunk-Based Development in.

If you want to have an elite or high-performance team of DevOps metrics, you should look at the Trunk-Based Development approach. It'll take you to the next level.

What is Trunk-Based Development?

Trunk Based Development (TBD) is a source-control branching model that emphasises continuous integration and collaboration within a development team.

With TBD, developers work on a single common branch, often referred to as a "trunk" or "mainline" branch, rather than of using long-lived feature branches.

In trunk-based development, the team doesn't develop on specific feature branches. (Source: trunkbasedevelopment.com)

The entire development team is working on the common branch called Trunk. (Source: trunkbaseddevelopment.com)

Key principles and practices of Trunk Based Development include:

Common Mainline: All developers work on the same branch, usually the main branch that represents the current state of the product. This promotes frequent and continuous integration of code changes.
Small, atomic commits: Developers commit their changes frequently and ensure that each commit is a small, self-contained unit of work. This practice facilitates code reviews, reduces merge conflicts, and enables faster and more accurate bug detection.
Continuous integration: developers integrate their changes into the main branch several times a day, enabling fast feedback loops and early detection of integration issues. Automated testing and build processes are often used to validate code changes.

Trunk-Based Development is the foundation for Continuous Integration and Continuous Delivery. TBD allows you to run lean experiments.

What are the benefits of introducing Trunk-Based Development in my team?

With Trunk-Based Development you get at least three benefits:

Reducing time-to-market and increasing efficiency
Improving team collaboration
Increasing stability of your product

Reducing time-to-market and increasing efficiency

By forcing you to work with *really* small and self-contained batches that you can integrate into the trunk, you have a much smaller but continuous integration effort.

With this approach, you reduce the lead time for changes and increase the frequency of deployment.

Improving Team Collaboration

The best way to share knowledge is pair programming and synchronous code walkthroughs.

IMHO it's a killer for team performance and especially for team collaboration and communication if you work "alone" on a feature branch and then create one of those crappy two-kilometre merge or pull requests that even lead to an epic discussion about irrelevant things.

In my experience, it's better to keep track of the main branch and changes if you work together on one branch. It improves collaboration and communication within the team.

It forces you to be a team player and not a lone programming wolf.

Increase the stability of your product

Changes that are isolated in Feature Branches are by definition not integrated. Thus, it's not continuous integration.

Continuous integration is a combination of trunk-based development and a series of rapid, automated tests that are run after each commit to the trunk to ensure that the system always works.

Continuous integration is about avoiding long integration and stabilisation phases by integrating small batches of code on a regular basis.

This way, developers ensure that they communicate what they're doing, and integration avoids large merges that can make a lot of work for other developers and testers.