What is DevOps Branching Strategies

Like tabs versus spaces, branching strategies is one of those emotive topics that trigger heated debates both online and offline. While many hold strong opinions on the best approach, as with many things in software development, the right answer depends on context. With that in mind, let’s look at what branching strategies are and how they tie into CI/CD.

Put simply, a branching strategy is your team’s agreement on how and when to create and merge branches in?version control. How you set up your version control system and use branches will impact how you set up your CI/CD pipeline, so it’s important to choose a model that meets your needs.

What is a branching strategy?

Your code branching strategy determines how and when developers branch and merge. There are several models including mainline, trunk-based development, task/feature branching, and more. When deciding on a method it is important to evaluate what makes sense for your team and product. Most version control systems will let you adopt any of these strategies.

How developers branch code and where/when it gets merged in the CI/CD pipeline are closely related. Branching determines how developers work. CI/CD branches decide how code is built, tested, evaluated, and eventually released.

A basic workflow starts with code being checked out. When the work in the branch is committed, CI/CD processes are triggered. This can be done with a merge or pull request. Then the CI/CD pipeline kicks into high gear.

The goal of CI/CD is to continuously integrate changes to find errors earlier in the process (a.k.a. “shift left”). This increases a project’s velocity by avoiding late stage defects and delays. It creates an environment where code is always ready for a release. Set up your projects and teams for success, with the right CI/CD branching strategy.

Why you need a branching strategy in DevOps

A properly implemented branching strategy will be the key to creating an?efficient DevOps process. DevOps is focused on creating a fast, streamlined, and efficient workflow without compromising the quality of the end product.

A branching strategy helps define how the delivery team functions and how each feature, improvement, or bug fix is handled. It also reduces the complexity of the delivery pipeline by allowing developers to focus on developments and deployments only on the relevant branches—without affecting the entire product.

How to Set Up Your CI/CD Branching Strategy ?

A code branching strategy is the foundation for your team. Your CI/CD strategy determines what actions in a branch trigger a build, test, and/or code review. It also determines how code moves through the DevOps pipeline.

When figuring out your CI/CD strategy, review:

1. How many commits are done on an average day by developers?
2. How is the build run for each commit?
3. Upon success, where does the developers commit go — mainline or master, shared dev code line?
4. When should you run a full build? For example, should you implement a nightly build?
5. What is the testing strategy? How much code coverage do you need? Server-side testing? Static code analysis?
6. What are your desired metrics for success/failure?
7. What are your desired time limits for feedback to the developer?
8. These questions will determine how you want to structure your branching CI/CD strategy.

Branching Strategies Options

Release Branching Strategy

With release branching, all the code that is meant to be deployed together lives on the same branch. This makes it easy to do isolated testing of new behavior, separate from the rest of the codebase or other in-progress work.

When working at a custom software consulting company, release branching can also be useful because it clearly defines what’s live on Production. This approach helps clients understand when it’s ‘go time’ for new features because deployments are pre-planned and concrete.

Feature Branching Strategy

Feature branching is similar to release branching, except instead of organizing the branches around a release of several features, you create one branch for each individual feature. For example, imagine your team needs to implement the following feature: “As a user, I can log in to the website with my username and password.” Depending on team structure and workflow, that might encompass several tickets or tasks on your project board.

Story or Task Branching

Though feature branching is closer to ‘continuous’ than release branching, it still can lead to similar problems with long-running branches, since a feature might take a long time to code to completion. That also means it has similar potential for merge conflicts.

Trunk-Based Development

Finally, the strategy that is truest to the core purpose of CI/CD: trunk-based development. This is honestly the scariest thing I’ve ever written: with trunk-based development, everyone commits and pushes to the?main?branch (the core codebase! without any side branches!), and those commits are deployed automatically! So scary!

GitFlow vs GitHubFlow

There are basically two ways to manage the software projects in GIT are?Git flow?and?GitHub flow. These two flows can help you manage your project and optimize your entire workflow in the team.

• master?— A representation of the codebase that is currently in production whose commits have gone through the entire flow and merged after post-release verification.
• develop?— The culmination of all feature branches that have been merged into the branch. Often used to run automated testing and releases to development resources through CI/CD pipelines.
• features?— Each change meant for inclusion in the next release are completed in feature branches that correlate with project tasking.
• hotfix?— Similar to feature branching, but can be based off of master. Allows for fixes to continue to support production while not affecting current development. Any changes can be pulled into active feature branches and/or back to master to ensure the issue isn’t re-introduced.
• release?— As it sounds, this branch is used as the final culmination of the feature branches slated for release. This branch would be a candidate for production and changes merged back into master after verification of a successful release. (in case using GitFlow)

We see less and less usage of workflows that involve developing directly from the trunk or master branch. This can be especially cumbersome to manage vs other methods that have seen great success in software development. As we move forward, those that are adopting more SaaS implementations of Git and integrate with tasking will likely move away from this method in favor of a branching model.