In Part 1, I talked about how we developed a git branching strategy that allowed for both a single historical deployment branch, but also for multiple release branches to exist at the same time. The residual issue with this was that we had to suppress merge conflicts during our branch sync’ing operations, so we had to find another way of exposing merge conflicts in a timely and reliable way.
In dealing with this, we devolved responsibility for merge conflict detection to Jenkins.
Builds that were deployed to our Development, QA and UAT environments all originated in Jenkins Build jobs. We had lots of build jobs, but we maintained these programmatically using python, so updating them was not difficult.
We added an extra build step before our integration tests. This step queried the source control repo for all current release branches in a particular project. Each branch was checked out and merged to the branch being built. If any branch failed to merge, the Build job was failed. The only way the development team lead could get the Build to succeed was to resolve the merge conflict.
When I first proposed this, there was some consternation. The main argument was that the development of one release branch should not be delayed by code in another release branch. If you consider release branches in isolation, there is some merit in this argument.
However, while timely deployment of releases is an important consideration, it is not the concern of Source Control. The concern of Source Control is that the code underpinning the product is well managed, which means conflicts between different development strands should be exposed and resolved as soon as possible, even if this impinges on one particular group who are contributing to the overall process.
It was also the case the merge conflicts were reasonably rare, and I was able to argue that a few minutes spent resolving a merge conflict every couple of months was a small price to pay to not have to unravel a bug based on a merge conflict that had found its way into Production.
We proceeded with the system, and as predicted, Build failures due to merge conflicts were rare. However, they did happen, which was something of a relief, as it proved the system was working as designed.
More generally, the development teams were given a whole new lease of life by removing the development branch from the SDLC. In fact, it really only became apparent how much of a bind the development branch was after it had been removed.
The overall success of the system was apparent when a minor bug in the scripting that underpinned the system led to a brief period of confusion before it was found and resolved. During this incident, I offered the option of temporarily re-opening the development branch.
The resounding NO that this was greeted with gave me not insignificant satisfaction!