Trunk Based Development (TBD)

In trunk-based development (TBD), developers always check into one branch, typically the master branch also called the “mainline” or “trunk”. You almost never create long-lived branches and as developer, check in as frequently as possible to the master — at least few times a day.

“Every developer is touching mainline, so all features grow in the mainline… which acts as a communication point. With CI, the mainline must always be healthy, so in theory (and often in practice) you can safely release after any commit.”  – Martin Fowler

With everyone working out of the same branch, TBD increases visibility into what everyone is doing, increases collaboration and reduces duplicate effort.

The practice of checking in often means that merge conflicts if any are small and there is no reason to hold back on refactoring. Troubleshooting test failures or defects becomes easier when the change-set is small.

TBD also implies deploying code from the mainline to production – which means that your mainline must always be in a state that it can be released to production.

In other word Trunk Based Development means – Trunk based development is a source-control branching model, where developers collaborate on code in a single branch (master). Developers should resist any pressure to create and maintain other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build and “live happily ever after.

Trunk-Based Development is a key enabler of continuous integration and by extension continuous delivery. When individuals are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of continuous integration that all team members commit to trunk at least once every 24 hours. This ensures the code base is always releasable on demand and helps to make continuous delivery a reality.

Architecture of TBD :

1

DevelopmentTypes

Short Lived Branches :

Utilizing short-lived feature branches are recommended for this TBD. One key rule is the length of life of the branch before it gets merged and deleted.

In other words,  the branch should only last a less than a 3-5 days. All merges from these short-lived feature branches back to master shall be via pull requests.

slfb_pull-push.png

Pros of TBD :

  1. More linear history, which is easier to understand and to make cherry-picks and reverts.
  2. Smaller conflict resolutions, mainly in case of major refactoring.
  3. Always the Trunk/Main Line is Production ready.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s