Over the years, the topic of what constitutes the best branching strategy has been the one I’ve spent the most time discussing with teams. Naturally, as Developers, we want to cover every possible use case, so we tend to overcomplicate the branching processes. However, while we should keep the strategy simple, that doesn’t mean there is a magical solution that fits all teams.
Recently, more complicated branching strategies have fallen out of favour for leaner, simpler ones. However, many considerations still need to be accounted for before picking (or changing) your approach.
What common factors to consider when choosing a branching strategy?
The best choice is the practice that supports the reality of where your team and the business currently exist. It would be best if you considered the following:
- Team experience
- Desired deployment frequency
- Change management practices
- Confidence in code quality
- Software architecture
If you are working at a well-established company where these practices have matured or a relatively new tech startup where you have already made these considerations, you probably wouldn’t be reading this article anyway. But the majority of us fit somewhere else. You may have a cumbersome process that confuses people, or your current approach is working fine, but you’re ready to take it to the next level to increase efficiency. Whatever your current state is, there is always room for improvement. Let’s dive deeper.
Team Experience with Branching Strategies
Most of your team likely has worked with various other groups with different maturity levels. Some might have worked very effectively with some branching strategies in the past, or it could have been a disorganized mess. You should explore the specific branching methods familiar to them in either case. When the team members share their past experiences, along with what they thought worked and what didn’t, not only will you get buy-in for potential upcoming changes by including them in the decision, you should be able to narrow down options that will work best.
In some cases, that familiarity might work against any desire to improve. For instance, suppose developers are comfortable with what they already know, so they first must recognize how different strategies could help expedite software delivery. They may need encouragement to embrace change. A research or knowledge-sharing campaign is the next best step in that case. Search for good information about the best practices and share them with the teams. Present options, pros and cons, and provide tangible examples of how it would work for your team’s product. Please encourage them to do the same. Even if you don’t make any significant shifts in how your teams work, showing them other options will at least get them looking at things in a new light.
Deployments and Environments
Part of the chosen branching strategy must consider when and how your code reaches your various environments. For example, having a development, QA, and production environment is typical, but you might also have a staging or sandbox environment for demos. On the other hand, you might not require a QA environment and only run with two. Whatever your case is, you need to identify which branch of code will get deployed to each environment and what triggers the deployment, whether automatic or manual.
If you choose a traditional long-running ‘develop’ or ‘integration’ branch (like Gitflow), then commits against that branch should automatically trigger a deployment of that branch to the development environment. But at what point do you now deploy to QA? Again, like Gitflow, do you cut a release branch off your development branch and manually deploy that one to QA? Typically, the ‘main’ branch will represent the current production state in most models. You could automatically deploy to production once you merge into the ‘main’ branch. But if you use a trunk-based or feature-based branching strategy, these trigger points would be entirely different.
What if your product requires supporting multiple versions? In that case, your options are more limited. Each version would require its own long-running branch for as long as that version is supported. The main branch would be reflective of the most recent version. While regular feature additions to the latest version could follow a chosen strategy, performing hotfixes of previous versions would need its own consideration.
Change Management
Although source control is only a concern to the development team, you should pay attention to other departments, groups, or individuals you interact with. For example, does your Product Team (or whoever brings requirements to your developers) have them broken down into small, independent features, or do they have many dependencies? Do you need to group many tickets to have a releasable product? What about Customer Success, Sales or Marketing? Do they typically need time to prepare training materials or pitch decks before the changes go live?
Ultimately, how frequently does your organization want to release changes? Although the multiple releases per day promised by continuous delivery sounds exciting, some organizations might require a more scheduled, systematic approach to change management. A fully automated pipeline capable of testing and releasing every single tiny change is usually the dream, but in reality, it might be overkill for some.
Confidence in Code Quality
Most teams will consist of a healthy mix of experience levels, but even the most experienced and skilled developers will introduce bugs from time to time. So what sort of code review and testing procedures do you have in place? If you have a full suite of automated tests that cover most of your codebase, and you’re confident the chances of introducing bugs are low, then allowing commits to the main branch could be a simple and safe solution. On the other hand, if you have little test coverage or have low-quality code reviews, you should use alternate branches to resolve issues until it is safe to merge to the main branch.
You can also consider your end-user base, their tolerance for bugs, and the risk level your organization is willing to take on. For example, if you’re in the early stages of a startup and your end-users are large businesses, sometimes minor bugs can cause apprehension during that vital demo, so a model that supports quality over speed might be preferred. Alternatively, you can accept the risk of losing the occasional paying customer if you target a wider audience. In that case, a simpler branching model allows you to move quickly, both in introducing bugs and resolving them.
Software Architecture
Whether you have a monolith or microservice architecture, consider the number of different repositories, how they might depend on each other, and the number of teams working on them. For example, when multiple groups build various features on the same repository, keeping the product in a releasable state becomes more difficult. Of course, you can mitigate these risks if you have a high level of test automation or if you make good use of feature flags. However, if you need a different option, having a long-running ‘develop’ branch that integrates everyone’s contributions might be the best way to maintain a stable codebase.
You could adopt a simpler branching model if your architecture landscape utilizes a decent microservice approach with multiple small repositories of rich functionality. But other factors need to be considered. For example, just because you have many microservices doesn’t mean you don’t have a habit of introducing breaking changes regularly. If you do but don’t have robust integration tests, you’ve eliminated one of the benefits of this architecture. As a result, you now need to coordinate multiple stable branches across numerous repositories, which requires more effort for everyone.
What Branching Strategy to choose?
Now that you’ve made these considerations, did it clarify your choice? Or did it just make it more confusing? A good branching strategy supports the business, the teams and how you want to operate. You don’t choose a model and start changing everything around it to suit that choice. If you want to increase your team’s efficiency, here are a few topics you should cover first.
Do you have a culture of writing, unit, integration and end-to-end tests? The stronger your automated testing procedures are, the leaner your branching strategy can be. If you need to be more robust in these areas, put your focus there. No branching model will give you higher quality or confidence in your releases, no matter how often they occur.
Do you deliver small pieces of independent functionality? Do your requirements allow you to write small amounts of deployable code? If you continually group many related stories to release your product safely and don’t already have a feature flagging service, consider adding that flexibility to your system first. The ability to ship code changes frequently without impacting your end-users until you’re ready will allow you to consider leaner branching strategies.
Does your organization embrace frequent changes? While everyone will say they want this, the reality can be slightly different. For example, have you ever been ready to release a significant feature, but then Customer Success needed you to wait until they could craft communication to your end-users? Ensure you have honest conversations with the other departments in your organization about how software changes impact them and if they can confidently handle on-demand, frequent changes. If not, you could focus on ways to help them adopt a faster change process.
Making the right choice for your team’s branching strategy requires many considerations. Hopefully, this article has helped you think about the best balance for your developers, the teams and the entire organization.
