4

What are the advantages/disadvantages of Branch per Release versus Code-Promotion Branches strategies?

Community
  • 1
  • 1
Gili
  • 86,244
  • 97
  • 390
  • 689

1 Answers1

6

The main reason why you branch is to isolate a development effort.

So that really depends what you deem most important to isolate:

  • a promotion effort for a given release (which will isolate commits within that promotion step: testing, integration or prod/hotfixes)
  • a release effort (which will include unit testing,integration,production phases all one after the other)

The Code-Promotion allows for parallel promotion efforts per release (you develop n+2 while testing n+1 and maintaining n).
While Branch per Release allows for a simpler more sequential development cycle where you mainly test and maintain n while developing n+1.

Whatever the chosen strategy is, you need to address the synchronization step between n and n+1 (what and when do you merge evolutions from n to n+1?):

  • With Code-Promotion you can merge at different steps
  • With Branch per Release, you generally merge only from one release to the current state of development for the other release.

So basically, the Code-Promotion strategy means more branches, more merge and more precisions in the history being kept and isolated in those branches.
But it means also more environment to setup and manage.

The Branch Per Release is more straightforward (provided you are able to know that what you are working on will actually end up being part of the next release).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • In a branch per release scenario what prevents you from developing n+2 while testing n+1 and maintaining n? – vlfig Dec 04 '12 at 22:58
  • @vlf nothing: it is simply more detailed (ie "more branches") in the code promotion, in that you promote code from features branches to integration branch to release branch for a given release `n`. – VonC Dec 05 '12 at 06:51
  • 1
    Sooo, when you say "The Code-Promotion allows for parallel promotion efforts per release" you're being unnecessarily restrictive (both allow) and when you say "Branch per Release allows for a simpler more sequential development cycle where you mainly test and maintain n while developing n+1" you're implying that branch per release doesn't allow for activities on more than two branches, which is clearly untrue. – vlfig Dec 06 '12 at 23:19
  • @vlf you are waayy over-thinking this. Those are two workflows you can tweak and adapt as you want. – VonC Dec 07 '12 at 06:47