This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Branching Strategy – The Forgotten Child of DevOps
The ideal DevOps project starts with everything stored in source control. As a coach, I often find that too little thought is given to how a team will handle their source control branching strategy. Time and time again I have seen how this one decision determines much of the complexity of both product and process. The ease of the journey to continuous delivery is largely dependent on this decision. Teams see success when they take time to make this decision and don’t just buy into master-only development or a model such as GitFlow. Instead, they think about how they want to manage complexity, and it starts with source control and branching strategy.
As an industry, we don’t think about branching strategies in depth or enough. One of the key tenets of DevOps is systems thinking and people tend to forget about it, albeit unintentionally. If branching strategy is supposed to be the best thing since sliced bread, why does it feel or look like we’re trying to navigate through a train yard with no knowledge of how to navigate through the train yard? We’re not train engineers, at least not at the beginning of our efforts.
The current state of branching strategies is usually more like organized chaos. The less complex or the simpler your branching strategy is, the simpler your product is going to be, and the simpler it will be to maintain it. Feature branching and feature toggling are two ways to simplify:
- Feature branching: Feature branching is when you take a feature, work on it by yourself in its own little space, and then merge it back in to the pipeline. Oftentimes I see people using a much more complex model called GitFlow. GitFlow can be abused as a branching model although it comes in handy for understanding that you still need to maintain all the code, but it’s infinitely more complex.
- Feature toggling: Feature toggling can be helpful, especially if you work iteratively or with an agile process. Jez Humble and Dave Farley are very clear in their book Continuous Delivery and the follow up since writing this text book. Trunk “based” (not trunk only) development is key to the team understanding and integrating their changes together. When the team has to deal with integrating their changes on a trunk or master branch every day, they have to deal with the pain of integration immediately instead of somewhere down the line with a merge. When we introduce feature toggling, teams can provide toggles around their new features to make sure they have control of them in production. Feature toggling gives teams (Dev and Ops) the ability to make sure that when something doesn’t work as expected, it can quickly be turned off.
All of this means that we have to learn as an organization what works best for us. On the complexity curve, this isn’t a linear problem, it’s more exponential. Just think about the number of branches that you have to maintain and all of the work you have in progress at any given time – it’s naturally more exponential. What can also add to the complexity is if you’re using a model where you create a lot of branches, you might be doing work that’s not actually going to get out into your production environment, which is a problem, because then you’re spending time doing something that you might never get back to.
The more often we work together and on fewer things, the better off we are. Keeping it simple doesn’t mean that it can’t be complex. Keeping it simple just means that everybody knows what’s going on, everybody knows how to use their own internal process the right way, so that when it comes time for changes to come together for a release or a deployment, everything works together very, very smoothly. That’s how I hope you can be epic with your own branching strategies and reduce the complexity of your product.