Always Agile Consulting commented on a post on Blogger.
Hi

I have read over the JOSRA branching strategy in some detail, and am following up on some conversations with Mike Long, Dave Farley, and Seb Rose post CoDe OSL (which I regretfully did not attend). 

Context: I'm an experienced Continuous Delivery guy with a strong Trunk Based Development background using Subversion (7 years), Mercurial (< 1 year), and Git (3 years). I have an in-progress series of related articles at http://www.alwaysagileconsulting.com/no-feature-branching/, and a pending talk on "The Death of Continuous Integration".

Without wishing to upset anyone, I would say the JOSRA branching strategy is a) a well-described branching strategy that improves on its overly-complicated predecessor; and b) probably incompatible with Continuous Integration, let alone Continuous Delivery.

I should say I am working from the following definitions:

1. Continuous Integration is "a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily" http://www.martinfowler.com/articles/continuousIntegration.html
2. Continuous Delivery is a set of principles and practices to improve cycle time via automation and organisational change www.amazon.co.uk/dp/0321601912, or "the extension of Continuous Integration across the software development lifecycle" http://www.infoq.com/interviews/farley-continuous-delivery

Let's start with the opening statement:

"The fact that most prehistoric version control systems weren’t particularly good at branching and especially not at merging leads to the consequence, that many teams today find themselves in a situation where they have never before merged as intensely as they now do on Git"

I assume a) we are denigrating the branching overheads and manual merging of syntactic conflicts in centralised VCSs such as Perforce and Subversion and b) we lack any meaningful data for the assertion that cheaper DVCS branching/merging operations has increased branching/merging operations, but despite the absence of data I would agree with both. However, I would argue an expensive branch/merge mechanism is in many circumstances a useful deterrent to prevent developers from unnecessary branching, divergent design decisions, and the risk of Integration Hell.

On intent:

[This branching strategy] "is specifically designed to be easy both to automate and to roll out event in large organizations"

I don't doubt the good intentions behind the JOSRA strategy, and based on the further detail provided I can think of circumstances in which it might be successful. However, the easiest branching strategy to roll out in an organisation is one that does not require automating, requires minimal branching, and requires minimal merging. That would be Trunk Based Development, which is considered both an effective method of achieving Continuous Integration and a prerequisite for Continuous Delivery by thought leaders such as Dave Farley and Jez Humble.

On implementation:

"The flow uses a branchy approach and is not dependent on any particular repository server. It’s compliant with all that we’ve come across; GitHub, GitLab, Stash, Gerrit etc. It is automated purely by using Jenkins CI and two plugins: The standard Git plugin and the Pretested Integration Plugin"

The flow might not be dependent upon a repository server, but appears to be coupled to a single DVCS and a single build server (Git on Jenkins). I assume using Subversion on Go or Mercurial on TeamCity would require substantial rework, and I would argue a version control strategy should be entirely decoupled from the version control system and build toolchain.

On its predecessor:

"You can see this flow as an optimized and automated version of the wide-spread - but in our opinion - far too complex model described in “A successful branching model” by @nvie."

Agreed. 'A Successful Branching Model' appears to be complicated not complex, but it certainly hurt my head to learn about it. In my opinion it is a more evil form of Feature Branching and I suggest the very name "A Successful Branching Model" is a smell that branching is not always - perhaps rarely - the best solution.

On the flow:

The visualisation is easy to understand and clearly communicates the workflow. I would personally refer to this style of branching as Build Feature Branching i.e. master is the canonical representation of all previous good commits, commits are merged to master from short- to long-lived feature branches, and there is a concurrent long-lived release branch for production fixes. 

The timeline is (understandably) coarse, but this version control strategy is probably incompatible with Continuous Integration - and therefore probably incompatible with Continuous Delivery, as the latter is predicated upon the former. Continuous Integration means every developer on the team is committing to master at least once a day - it is a shared mindset of collaboration - and 'An Automated Git Branching Strategy' is unlikely to lead to that.

The visualisation shows concurrent feature branches. Now, even if every developer on the team intends to only have short-lived feature branches they all too easily last longer than a day. Those independent branches discourage collaboration, diverge from the shared design, prevent predictable delivery, and periodically cause Integration Hell. Integration Hell might be a complex syntactic conflict that requires manual intervention, a semantic conflict that causes a defect http://martinfowler.com/bliki/SemanticConflict.html and/or c) a re-test on master of feature(s) that were already tested on the branch. This is all waste that no customer will ever pay for, and is incompatible with the Continuous Integration/Delivery demand that the codebase always be releasable at any given point in time. This is even illustrated in the diagram when a particular commit to master is marked as stable - every commit to master should be marked as stable. 

I say this branching flow is probably incompatible with Continuous Integration because it might not be. If every developer on the team pushes their Feature Branch to master at least once a day, then it posible Continuous Integration could be accomplished. However, in my experience the availability of cheap branch/nerge tools blinds developers to Individuals And Interactions Over Processes And Tools, and Responding To Change Over Following A Plan.

On the principle "The project integration branch is where developers continuously integrate":

The statement "This commitment is really the core concept of Continuous Integration: It’s a technique for software developers to share work and collaborate as a team" is correct, but only for trunk. There is an implication here that a "project integration branch" other than trunk could be Continuous Integration, but that is simply not the case.

The statement "Some agile beliefs say that a task can not span more than a days work, simply because a developer should be expected to deliver some piece of increment of running code to the code base at least once every day" can be explained by Continuous Integration demanding at least a daily commit by every team member to trunk - making tasks shorter than a day is one possible means of accomplishing that. 

On the principle "Only trivial merges are allowed onto the integration branch":

This is all well and good for syntactic conflicts, but semantic conflicts can and will happen when developers stray into long-lived feature branches in the same codebase region. 

On the principle "All integrations onto an integration branch must pass an automated toll-gate":

The suggestion of pre-commit hooks on master to verify commit integrity is a good one, but the need to run such checks is often a symptom of a) developers not testing their own work b) a slow build and/or c) a build that is hard to revert. In my experience it is better to have a post-build hook that immediately reverts a failed build, along with the delivery of a pink cowboy hat to the offender. This can be automated.

On the principle "All integrations onto promotion branches are automated":

Why on earth does there need to be a 'stable' branch? Why is master not permanently stable? Why does there always need to be a 'release' branch? Why is master not good enough for production releases, with release branches created at a later date if a production defect occurs? 

On the principle "The integration branch is always aiming for the next release":

I strongly agree with your saying that a stabilisation phase "defies the purpose of a Continuous Delivery pipeline which we advocate and which essentially implements our definition of done". Any kind of hardening phase in software delivery represents a fundamental failure to build quality into the product. 

In summary, I believe it is fair to say that Continuous Delivery requires Continuous Integration, and Continuous Integration is unlikely with this branching model. Saying that, the case for it is well-described and at times well-argued... particularly when contrasting it to its predecessor and the understandable desire to be aligned with Continuous Integration and Continuous Delivery practices. However, to do this your best bet really is Trunk Based Development.

Trunk Based Development is hard but it works very well. Commit to master with no branching on at least an hourly basis, constantly collaborate with your peers, and commit production fixes to a release branch when necessary. The extra emphasis upon shared design and collaboration can be a difficult adjustment for many teams, but the subtle pressure upon everyone to improve the codebase design together will be worth it. Trunk Based Development is independent of any VCS, any DVCS, any versioning scheme, and scales to any organisation size as proven by Facebook http://paulhammant.com/2014/01/08/googles-vs-facebooks-trunk-based-development/ and Google - the latter has 15,000+ developers in 40+ offices on trunk http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/). 

Again, thanks for (indirectly) asking for my feedback on the above. 

Cheers

Steve
JOSRA
JOSRA
josra.org
Shared publiclyView activity