Steve Smith is an Agile consultant and Continuous Delivery specialist at Always Agile Consulting Ltd. An XP / Lean developer with 10+ years of experience in enterprise software development in Britain and New Zealand, Steve favours practices such as Pair Programming and Test-Driven Development to build quality into software products. As an early adopter of Continuous Delivery he has overseen transformation programmes in multiple organisations to reduce lead times and increase product revenues. Steve is a co-author of the Continuous Delivery and DevOps book "Build Quality In", a co-organiser of the monthly London Continuous Delivery meetup group, a co-organiser of the annual PIPELINE conference, and a regular speaker at conferences such as Agile On The Beach and QCon New York. Steve blogs at Always Agile Consulting and is on Twitter at @AgileSteveSmith. Steve is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

Trunk Based Development Branching

06.25.2014
| 5693 views |
  • submit to reddit

NOTE: Always Agile Consulting now offers an Introduction To Trunk Based Development training course!

Trunk Based Development supports Optimistic and Pessimistic Release Branching

Trunk Based Development is a style of software development in which all developers commit their changes to a single shared trunk in source control, and every commit yields a production-ready build. It is a prerequisite for Continuous Delivery as it ensures that all code is continuously integrated into a single workstream, that developers always work against the latest code, and that merge/integration pain is minimised. It is important to note that Trunk Based Development does not prohibit branching. Trunk Based Development is compatible with a Release Branching strategy of short-lived release branches that are used for post-development defect fixes. That Release Branching strategy might be optimistic and defer branch creation until a defect occurs, or be pessimistic and immediately incur branch creation. For example, consider an application developed using Trunk Based Development. The most recent commits to trunk were source revisions a and b which yielded application versions 610 and 611 respectively, and version 610 is intended to be the next production release.

Branching In Trunk Based Development - Optimistic

With Optimistic Branching, the release of version 610 is immediate as there is no upfront branching. If a defect is subsequently found then a decision must be made where to commit the fix, as trunk has progressed since 610 from a to b. If the risk of pulling forward from a to b is acceptable then the simple solution is to commit the fix to trunk as c, and consequently release version 612.

Branching In Trunk Based Development - Optimistic Defect Low Risk

However, if the risk of pulling forward from a to b is unacceptable then a 610.x release branch is created from a, with the fix committed to the branch as c and released as version 610.1. That fix is then merged back into trunk as d to produce the next release candidate 612, and the 610.x branch is earmarked for termination.

Branching In Trunk Based Development - Optimistic Defect High Risk After

With Pessimistic Branching, the release of version 610 is accompanied by the upfront creation of a 610.x release branch in anticipation of defect(s). If a defect is found in version 610 then as with Optimistic Branching a decision must be made as to where the defect fix should be committed.

Branching In Trunk Based Development - Pessimistic Defect

If the risk of pulling forward from a to b is deemed insignificant then trunk can be pulled forward from a to b and the fix committed to trunk as c for release as version 612. The 610.x branch is therefore terminated without ever being used.

Branching In Trunk Based Development - Pessimistic Defect Low Risk

If on the other hand the risk is deemed significant then the fix is committed to the 610.x branch as c and released as version 610.1. The fix is merged back into trunk as d and version 612, which will also receive its own branch upon release.

Branching In Trunk Based Development - Pessimistic Defect High Risk After

The choice between Optimistic Branching and Pessimistic Branching for Trunk Based Development is dependent upon product quality and lead times. If product quality is poor and lead times are long, then the upfront cost of Pessimistic Branching may be justifiable. Alternatively, if post-development defects are rare and production releases are frequent then Optimistic Branching may be preferable.

 

Published at DZone with permission of Steve Smith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

David Karr replied on Wed, 2014/06/25 - 10:07am

Another way to concisely illustrate the difference between trunk-based development and "the old way" is that the old way would create a release branch when the work targeted for a release is STARTED. The better way as described here is to create (or perhaps optionally create) the release branch when you're about DONE with the work for the release.

Gaobi Lee replied on Wed, 2014/06/25 - 10:30am

 Wonderful article---http://www.bagswalletssale.com

Alexander Kriegisch replied on Wed, 2014/07/02 - 8:40am

I disagree with trunk-based development in favour of (usually short-lived) story/feature branches which are only merged into an upstream sprint/release branch after its Definition of Done has been fulfilled and the feature/story/bugfix was accepted by the customer or product owner. Anything else leads to an unstable trunk.

My approach does not contradict CI/CD: There are nice Jenkins plugins which automatically create build jobs per new story branch and deletes them again after a story branch has been merged and deleted. BTW, story branches should be continuously updated from the sprint branch whenever a finished story is merged back into the sprint branch. Many small merges are much easier than one big one. Integration of upstream changes should be done as early as possible.

After a sprint/iteration is finished, the sprint branch only contains tested and accepted work. It can be merged into the master/trunk and there the release can be created. This way the master/trunk is always stable, the sprint/iteration branch only contains features/bugfixes for the next release and if a sprint/iteration is over before all stories were done, unfinished work does not pollute the release. It will be merged into the next sprint branch after it is done and accepted.

This model works nicely with Git and its advanced (but, technically speaking, very simple) branching/merging model. With SVN and similar products, merging is more painful, so I recommend to really switch to Git and its way of tracking changes and parent revisions via a ADG (acyclic directed graph), which is fundamentally different and thus superior to the way SVN, CVS, Perforce & Co. track changes.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.