Die, Long-lived Branches

Long-lived feature branches. We tend to think of them as a relic of the software development practices of yesteryear, but many businesses still have them today. Firstly, while nearly every company preaches the importance of Agile and DevOps, there are plenty of large enterprises still using waterfall-style development and delivery methods for at least a part of their application development.

Secondly, and perhaps more insidiously, there are plenty of teams that call themselves “DevOps” yet still have long-lived feature branches. These branches happen because someone wants a new feature but doesn’t want it to interfere with development on the master branch. Or, because that is how feature development has always been done and inertia is a powerful organizational force. Instead of regularly integrating the code for the new feature with the master branch, the feature branch is kept separate until it is ready for deployment.

Except it’s not really ready to deploy, because it hasn’t been integrated into the rest of the application. And that is the hard part.

Why You Should Avoid Long-Lived Branches

Long-lived branches impair collaboration. Software development, especially in a business setting, is a team effort. If your colleagues can’t see what you’re working on (and if it’s in a feature branch, they can’t see it), they will have no visibility into how your work might affect their work. If everyone is working on long-lived branches and no one can see what anyone else does, bringing it all together can be slow and messy.

Integration problems slow you down. If your organizational goal is to deploy more frequently and to get new features to end users as quickly as possible, integration needs to be done continuously or, at the very least, with branches that are exceptionally short-lived. This reduces the complexity of the integration story and the likelihood that the new code will cause unpredictable problems.

Long-lived branches make continuous delivery impossible. A mature continuous delivery and deployment system involves a fully automated pipeline that is capable of thousands of deployments per day, with no manual intervention. If your feature branches are not being integrated into the master branch until the last minute, you’ll create a huge bottleneck in the pipeline that no amount of tooling will solve.

How to Kill Long-Lived Branches

Moving toward continuous integration is both a technical and cultural process. There are two basic steps in moving toward continuous integration that continuous delivery depends on.

Create company-wide guidelines on branching. Changing your company policy and accepted workflow is ultimately the first step toward avoiding long-lived branches—they are caused not by technical challenges but because development teams were sold on the fact that it was the best way to manage feature development.

Use a continuous integration tool. Once you establish that long-lived branches are not an acceptable development method, get a tool to automate testing of each pull request before it’s merged with the master branch.

There’s a reason it’s called a CI/CD pipeline. Without meaningful continuous integration that’s supported both with appropriate tools and by the development culture at the organization, true continuous delivery and deployment is impossible. Without CI/CD, it’s impossible to meet the core objective of DevOps: getting better software into the hands of end users faster.

Ready to learn more about how Spinnaker can help you move toward a mature CI/CD process? Schedule a time to talk with an Armory expert today.