DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Look, Ma! No Pods!
  • What We’ve Learned From Coaching DevOps Teams in Git Branching Strategies
  • Git Branching Strategies for Maintainable Test Automation
  • Git Strategies for Software Development: Part 1

Trending

  • A Better Web3 Experience: Account Abstraction From Flow (Part 1)
  • Freedom to Code on Low-Code Platforms
  • Supercharge Your Communication With Twilio and Ballerina
  • Parallel Sort
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Trunk-based Development: When to Branch for Release

Trunk-based Development: When to Branch for Release

How Continuous Delivery teams and organizations should be releasing software from the "trunk" of the source code, and when it's appropriate to create a new branch.

Paul Hammant user avatar by
Paul Hammant
·
Dec. 18, 15 · Opinion
Like (4)
Save
Tweet
Share
7.11K Views

Join the DZone community and get the full member experience.

Join For Free

it does not matter if you’re using git, mercurial, subversion, perforce, or tfs. this definition below is the same for each.

not branching for release

here’s maven doing an actual release for me in a git repo:

the evidence is two commits — one for v1.16 of fluentselenium, and the following one is for 1.16.1-snapshot (snapshot being maven’s code phrase for work in progress). maven went and pushed the 1.16 jars off to globally available repos.

anyway, it was me not making a branch for a release. sure, i needed other committers to not commit while i was doing a release. for other languages and other build technologies, or java teams not using maven’s release-plugin it might not do commits to signify “release is currently happening.” in that unpolluted commit-history eventuality, i’d be able to do the release from a specific commit (or tag), and not require devs to stay out of the trunk for a few minutes.

teams that are adept at continuous delivery (cd) are doing it this way — releasing straight from the trunk. maybe not every commit, but ones that have at least passed every automated test, in a multi-stage continuous inegration (ci) pipeline.

bugs in the release?

if you’re a hardcore cd team, you’re probably going to do another release from trunk to fix that bug.

if your cadence into production isn’t a couple of time a day, you might prefer fix the bug on the trunk, and cherry pick the bug fix to the applicable release branch. of course you didn’t have that, so you belatedly create the release branch from the right commit hash/num specifically for this bug fix (and others that may follow), then do the cherry pick. teams that are doing it this way are often going to want to manually test the bug has been remediated based on a build from that branch. if you’ve gone to the effort to make a branch, you clone the trunk’s continuous integration pipeline into one that guards this branch.

branching for release

note: i’ve hacked up a clipped image to show something that didn’t actually happen. the branch would be made from a specific commit (or tag, or just head) and named for that release, in some days or hours leading up to a release:

the enterprise in question intends to harden the release on this branch. the first and maybe only true commit on the branch is one that updates version numbers to signify the intent – in this case a “release candidate” for the release. other enterprises could go straight to “1.16”. you also always clone the trunk’s ci pipeline into one that guards this branch.

no commits were made on the trunk (git’s master in my case here). thus developers did not have to slow down at all in the rate at which they were committing to the branch. especially not the dreaded code-freeze popularized in other branching models. i’m talking about you, clearcase!

merging bug fixes back from the release branches to the trunk?

not if you can do it on trunk first and cherry pick to the release branch instead. no risk of regression. note regression means “things go backwards,” “regression testing” means a mechanism to guard that things did not go backwards.

when to delete release branches?

when you’re safely in the next release cycle — meaning you’ve done a deploy to prod and it’s going to stick. and yes, you should delete release branches after they’ve fallen into disuse. they’re still there in history but a merge-meister might not cherry-pick into the wrong branch if there’s only a couple of release branches in play at a time. the cd-style fire hose into production from trunk, should be your goal though. i.e. no branches.

why cherry pick?

well because you only want the release branch (if you created it) to differ from how it was created by the smallest possible amount.

more reading

i’ve been writing about this stuff for more than eight years of course, and practicing it for more than 17.

here’s an article with a few charts of practices correlated to trunk based development: trunk supporting practices

there’s also my whole trunk based development category

Release (agency) Branch (computer science)

Published at DZone with permission of Paul Hammant, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Look, Ma! No Pods!
  • What We’ve Learned From Coaching DevOps Teams in Git Branching Strategies
  • Git Branching Strategies for Maintainable Test Automation
  • Git Strategies for Software Development: Part 1

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: