Always Agile Consulting commented on a post on Blogger.
Dear Lars!

Thanks for the above. I've read your counterpoints and I fear we will have to agree to disagree in places.

On "the easiest branching strategy":

I disagree that "the easiest branching strategy to roll out in an organization is one that can be automated". The easiest branching strategy to roll out is the one that requires no branching - then you avoid the overhead of developing your automated scripts, testing them, and maintaining them over time. When individual developers practice Trunk Based Development and the team collectively practices Continuous Integration, commits are sufficiently regular that the probability of a merge conflict is far lower. 

That said, Trunk Based Development means minimal branching not zero branching. If production defect fixes are a regular occurrence then short-lived release branches would be used and branch creation might be scripted. However, given production defect fixes are normally merged from trunk to branch there is no real need for additional automated merge support on top of the VCS.

Trunk Based Development is named Trunk Based Development because it predates DVCS - as does Feature Branching. By all means call it Master Based Development if you like.

Regardless of VCS vs. DVCS and Trunk Based Development vs. Feature Branching, your working copy is indeed a local branch of the remote trunk and merges always happen. I don't believe that is in dispute. The best way to minimise merge complexiy and the likelihood of Integration Hell is to encourage developers to commit changes to master on at least a daily basis, and constantly collaborate with their peers on their shared design. 

On "build feature branching":

I would say a) feature branches prevent Continuous Integration if they last longer than a day, and b) build feature branches i.e. less than a day endangers Continuous Integration as it encourages design divergence and discourages collaboration. The only way feature branches could integrate continuously would be if at least one commit was automatically/manually merged to master daily, in which case I would suggest moving to Trunk Based Development and ditching the branching overhead.

As previously stated, I entirely agree with your criticisms of "the successful Git branching model". It looks like what I call Integration Feature Branching - a long-lived feature branch for days/weeks/months that pretends to be master - and it has many flaws.

I don't understand why you suddenly conflate Trunk Based Development with Subversion. Both Trunk Based Development and Feature Branching are compatible with any VCS or DVCS - the tool is orthogonal to the practice. Just because a branch is cheaper to create in Mercurial or Git than Perforce or Subversion does not mean it should be created. As I mentioned in my previous comment, I could argue the expense of creating branches in a VCS might theoretically encourage people to collaborate upon an improved shared design rather than branching the design in different directions.

On "substantial rework is required":

As I said at the outset, I doubt the need for the automation not the quality of the automation itself. If the only time a branch is created is for a production defect fix, where is the "cumbersome manual process in your flow" that you mention?

On "a re-test is a waste of time":

If you test something on master and a branch, that is by definition a duplication of effort regardless of whether it is an automated test lasting 1 second or an exploratory test lasting 10 minutes. There is a difference of course, but it is repetition regardless. 

I infer all your testing of a feature is automated, which can't be right. Surely there is some exploratory testing of each feature by developers and/or testers, which happens initially on the feature branch? And surely that exploratory testing has to be repeated on master, as upon merge it is the first time that new feature has interacted with the entirety of master at that point in time? If that exploratory testing is not happening, there is a risk of production defects as automation cannot handle every scenario well e.g. penetation testing. IF the exploratory testing is happening, there is waste.

I like your confidence that your build is impossible to break! Syntatic conflicts can mostly be handled by the merge tool - Git and Mercurial are particularly good. However, merge tools cannot handle semantic conflicts With regular merges to master semantic conflicts are unlikely, but they are a possibility.

On "incompatible with CI/CD" and "policy enforcement through quality enforcement":

When I say Build Feature Branching such as your strategy is probably incompatible with CI/CD, I choose my words carefully. If an entire team of developers is merging from their feature branch(es) to master on at least a daily basis, then a Continuous Integration mindset could be established. However, every developer on the team has to do this every day on every task for Continuous Integration to happen - and in my experience it breaks down. 

A developer could all too easily go astray from your chosen path, no matter how well automated that path might be. For example, they could pick up a task at 0900, uncover a refactoring opportunity at 1400, and mistakenly couple refactoring completion to task completion until 1200 the following day. By this point the other developers on the team have merged to master at least once, which means a) if anyone else worked in the same area there will be a merge conflict b) if anyone else disagrees with the refactoring, undoing it constitutes rework, c) task completion took longer than necessary, and d) the design of the refactoring was chosen by an individual not by a team. I have fallen into that trap in the past, as I'm sure most other developers have.

Continuous Integration is a shared mindset, and Build Feature Branching enables developers to not work together and not merge on at least a daily basis. All too often that will happen, unless a team has a very strong culture of collaboration in place. In that case I would applaud the team and recommend they move to Trunk Based Development immediately, as they clearly possess the necessary discipline.

On "the benevolent dictator governance model":

I didn't say a pre-commit hook is only necessary if the build is slow or developers are irresponsible - I said it was a good thing, and might be a smell of a slow build or faulty practices. It can work very well, but I would see it as a stepping stone to a better place rather than an end state. 

The 6th principle of Continuous Delivery is "Done Means Released" (although Dave and Jez would probably amend it to "Launched" or "Retired" now, I think). I do not believe any build tool or development team can truly say something is done. 

You make a good point about a pink cowboy hat possibly being linked to a blame culture. I remember when early XP teams would use a single VCS commit username to avoid that very situation. I have seen a broken build token work when the existing team culture is inclusive. I can also imagine it not working well in other scenarios. The broader point I was trying to make was that a post-commit hook is more valuable than a pre-commit hook, as it ensures the build remains broken for only a few moments.

On "what is a fast forward":

Thanks for the clarification, pipeline metadata is invaluable and I can understand why you might implement it in Git. I personally advocate storing pipeline metadata alongside the artifact itself in the artifact repository, such as a my-artifact-1.0.json alongside in Artifactory, which is updated after each action. Each to their own.


Shared publiclyView activity