DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog Branching – Seeing the woods for the trees

Branching – Seeing the woods for the trees

Written by Technical Consultant Stewart Osborne Linux Automation specialist, RedHat Certified Engineer and DevOps Practitioner.

If you’re planning a migration to Git, the chances are, you are doing so as a means to increase the productivity of your software delivery teams. If you want to do it right, you’ll need to coordinate your branching and merging strategies in advance to get the most out of your new VC tool and minimise disruption.

Depending on the VC tool you are already using, your level of organisational maturity and the agility of your delivery teams, you may already have suitable branching strategies defined for each team which can be utilised post-migration. But even if you do, now would be the best time to re-assess those strategies to ensure that you’re getting the most out of Git.

Two of the most commonly used Git branching strategies are “Git Flow” and “GitHub Flow”. While there are similarities between them, both strategies are tailored to different levels of organisational maturity and selecting the wrong one can have dire consequences for the productivity of a team.

As a general rule, I’d say GitHub Flow is the most preferable branching strategy to maximise the flow of work and boost productivity. However, there are several pre-requisites to GitHub Flow that must be met in order to leverage this increased momentum. Essentially, you need to embrace true DevOps practices to make this a viable choice:

  • Dev, Test & Integrations environments should be available on demand
  • The code-base should have a high level of automated test coverage (at least 80%)
  • Build & Deployment processes should be de-coupled and independent
  • True Continuous Delivery should be the goal (Not based on release cycles)

If these conditions are met, following the GitHub Flow branching strategy will allow Development and Engineering teams to write, test and deploy new code multiple times per day using true trunk-based development practices.

Implementing GitHub Flow before these pre-requisites are met can actually result in decreased productivity and increased complexity of the CI/CD pipeline, as Github Flow lacks the structure to allow for delays in the dev-test-deploy process. Essentially, trying to use Github Flow before you are ready will result in fewer benefits and more merge conflicts.

If you are still on your journey towards Continuous Delivery but do not currently meet the above pre-requisites, then you’re likely grouping production changes together into release candidates and are deploying with release cycles.

For this particular delivery model, I’d suggest that Git Flow is the best way forward. Git Flow has the structure to allow for the parallel development of multiple features in isolation, while allowing for delays to occur at any stage without it causing conflicts further downstream.

For example, let’s say a team of Developers are working on 4 separate features at once. Three of those features have been deployed to appropriate testing environments for unit tests and integration tests to be run. The fourth feature has been written, but there’s no environment currently available for this to be tested and so the 4th feature has to wait until a suitable environment is free.

If these Developers are working with a Git Flow branching strategy, this delay is easily managed as part of the process and does not impact the progress of the other features being developed. This same scenario using Github Flow would likely result in a merge conflict when the fourth feature is merged back into the master branch after testing, because additional features or fixes may have been merged out of sequence during the delay.

It’s worth noting that Git Flow is also an excellent “stepping stone” for organisations intending to implement true CI/CD practices in the near future. This is because Git Flow increases the safety and “deployability” of the master branch, ensuring that every single piece of code in the master branch has been thoroughly tested and is in a deployable state. Having complete confidence in the state of the master branch is a fundamental requirement for switching to Github Flow at a later date.

Of course, there are other branching strategies – and there’s nothing stopping you from tailoring them to your organisations’ workflow. There is also no need for every team to adopt the same branching strategy, as long as strategies are agreed and coordinated with any downstream teams.

That said, there are certain advantages of adopting well-known strategies such as Git Flow and Github Flow and implementing them across the entire organisation:

  • Decreased CI/CD pipeline complexity
  • Reduced learning time for new team members (new hires and inter-team transfers)
  • Well documented strategies with community support
  • Tooling is available to help navigate Git Flow & Github Flow for IDEs.

However, the Git Flow and GitHub Flow strategies needn’t be followed to the letter. Git is flexible enough to allow you to plan and adopt your own strategies to better suit the requirements of your individual development or product teams. For instance, you may decide to increase your number of permanent branches to better reflect the availability of your development & testing environments. Go ahead – as long as it’s well planned and communicated there’s nothing stopping you.

If you’re new to branching strategies or you’re having difficulty getting consensus from your teams on which strategy to work with, using either of the above as a starting point to spark discussions in workshops should start you off on good footing.

Leave a Reply

Your email address will not be published. Required fields are marked *