The Best Branching Strategies For High-Velocity Development
Development teams need to move fast. Parallel development allows developers to work on tasks simultaneously as part of a team. And parallel builds and testing ensure developers get the feedback they need quickly.
But as projects and teams grow, working in parallel becomes more complex. Because it’s not just about merging changes within a team. Complex products have several teams that need to integrate code.
Within a given team, the “merge early and often” strategy helps combat this issue. But often integrations between teams are pushed later in the development cycle. Bringing all the code together near the end can cause massive merge conflicts and release delays.
But your teams do not have to sacrifice quality for speed. There’s a better way.
By branching and merging code more frequently, your team can be more productive. Implementing the right branching strategy helps support your parallel development efforts (no matter size of your team or project).
This helps you build better products and keeps your codebase stable. Because team members are able to work on portions of the code without impacting others, they can get more done.
Branching code helps software development teams work in parallel. They can use it to coordinate changes and collaborate on a shared codebase.
To start branching, teams need version control. Version control systems (VCS) organize code, store developers’ work, and allow teams to make and push changes.
When a branch is created, the VCS creates a snapshot of the codebase. And as files are modified, teams can merge back changes. Branches can be made for features, updating frameworks, creating common components, and managing releases.
What Is a Branching Strategy
Branching strategies coordinate work to allow for easier integration of changes and releases. They create a development workflow.
Why You Need It
For teams that have hundreds or thousands of developers, branching and merging can be difficult. Bad merges and late-stage integrations suck up developers time, potentially delaying future work or releases.
To reduce the pain (and effort) for your teams, your branching strategy should aim to:
- Optimize productivity.
- Enable parallel development.
- Allow for a set of planned, structured releases.
- Provide a clear promotion path for software changes through production.
- Evolve to accommodate changes that are delivered, perhaps daily.
- Support multiple versions of released software and patches.
Types Of Branching Strategies
The point of a branching strategy is to efficiently manage code changes. This workflow will impact both developer and deployment workflows.
Task and Feature Branching Strategy
Using a feature branching strategy allows developers to create a branch for a specific feature or task. These are often referred to as user stories. This branch-per-issue workflow allows developers to work separately.
For example, one team or person might be working on an intrusive bugfix deep in the code, while another might be creating a new workflow for the end user. Each team can work independently on their assigned task and merge changes back into the main branch (mainline) when they're done.
Feature Branching Pros
Allowing developers to experiment and work independently from the core product can keep your codebase stable. This strategy gives your team’s the freedom to innovate, plus you can implement workflows for CI/CD.
It also helps developers easily segment their work. Instead of tackling an entire release, they can focus on small sets of changes. Also feature branches can be divided up according to specific feature groups. Each team or sub-team could maintain their own branch for development. Then when they are finished, changes can be tested and reviewed before integrating them together.
When using the feature branching strategy for a large enterprise/codebase, it is important to integrate changes across teams frequently.
By integrating all changes earlier in the development cycle, you can prevent costly conflicts that could take a long time to sort out.
Feature Branching Cons (and What to do About it)
The purpose of feature branches is for the branch to live as long as the feature is being developed. This is where a lot of teams struggle. Long-lived feature branches are a nightmare to merge. Because in an effort to avoid conflicts, developers may work in isolation for an extended period of time. But this causes even more issues.
Featuring branching only works if developers (and teams) branch and merge often.
A lot of developer forums talk about merging at least once a day. But, many teams do not follow this best practice. Plus with most VCS systems, there is no visibility into the main branch. Do you even need to merge? Are new changes available?
To help solve this issue, create an environment for each feature branch for testing. You should also integrate feature branches early in your development cycle. Then you can test and deploy more frequently to ensure there are no issues between branches. Testing production level code helps ensure that code won’t be introduced before it's ready.
Feature Flag Branching Strategy for Continuous Delivery
The goal of DevOps teams is to test by building often. Continuously integrating, testing, and delivering code back to developers ensures that teams fail fast, and resolve issues quickly.
To help support this type of development, some teams implement feature toggles or flags, instead of maintaining a separate feature branch.The advantage is that all work can be done right from in the mainline. This means less branches and minimal merging.
By using the feature toggle, portions of the code can be turned on or off for the build process. Feature flags can help teamsscale quickly. But it slows them down over time as projects and teams grow.
If you have a monolith codebase, this can be costly to maintain. Flags need to be added for each new feature on the code level. And admins need to write scripts to manage them. This takes time away from DevOps teams enhancing build automation that can really help you deliver faster.
Release Branching Strategy
A release branching strategy involves creating a branch for a potential release that includes all applicable stories. When a team starts working on a new release, the branch is created.
For teams that need to support multiple releases and patch versions over time, a release branching strategy is required. Teams can work on all user stories within the mainline branch for that specific release.
It is common to follow different branching strategies depending on the type of release. For example, major releases may use a feature/team-based branching strategy on top of the release branch. Whereas patches/hotfixes may work directly in the release branch.
Release Branching Pros
If you are working on a product that needs to support multiple versions in parallel or needs to handle customization for a specific customer, release branching is a requirement. It allows your team to focus on specific issues per patch or release.
Release Branching Cons (and What to do About it)
Working with a lot of release branches can be difficult to maintain. If you have a lot of changes and contributors, your codebase can quickly become unstable.
It also can potentially create more work for teams. If they need to maintain multiple releases, changes would need to be applied into several versions. For example, you could be supporting version 1.0, 2.0, 3.0., etc.
If you are managing multiple parallel versions or customizations of your software, it is critical to have a process in place. It should ensure that bugfixes are propagated, merged, and tested across the relevant release branches to avoid regressions.
Merging Strategies 101
Whether you use task/feature branching, release branching, or a combination of branching strategies, at the end of the branch, you merge.
Depending on your VCS, your workflow will vary. With both centralized and distributed systems, you usually end up merging everything to one server. Having a single source of truth helps your DevOps teams build easier. They can get everything they need for a build from one central location.
And to help you avoid ‘merge-hell,’ we have some tips to help you branch better.
Branching Best Practices (No Matter Your Branching Strategy)
Know and Communicate Your Branching Strategy for a Project
Once you decide on a branching strategy, you need to document it and communicate it to your team. You want to outline:
- When a developer should branch? From where?
- When they should merge (and how often)? To where?
Defining this workflow across teams is vital. This is usually done through documentation, folder structures, or on a whiteboard. Throughout the development cycle, check in with teams to make sure everyone is on the same page.
Minimize How Long Code Is Checked Out
We are saying it again for the developers in the back! Some teams have a lot of branches, and some have a few. But no matter how many you have, limiting the time code is checked out helps prevent merge conflicts.
Developers should regularly copy down code to ensure they have the most up-to-date files. The longer something is checked out, the more isolated that code can become.
Figure Out Your Dependencies
If you are working on a hotfix, or even a feature, you need to know what versions or teams it will impact. Before you branch, it is important to think about how changes need to be propagated, and where code needs to be integrated.
Review Your Merge/Integration Process
Let’s say a developer is making multiple changes on a branch. When they go to merge, the build breaks. They fix it. And then just before the release, code is integrated across teams. Now BANG, everything is broken.
But which change caused the issue?
The more code you have to sort through, the longer a merge or integration will take. Merging often reduces the risk that something breaks. Integrating code earlier, or integrating across teams one at a time, allows contributors to quickly isolate an issue.
Pick the Right Version Control System
When you think about picking a VCS system, branching is only one part. You want a system that can handle the number of files, contributors, and build demands. Also you are going to need performance to back it up.
And although branching my never be completely stress-free. It doesn’t have to be as much of a headache if you choose the right VCS. With Helix Core –– version control from Perforce –– you get Perforce Streams. This branching method shows the relationships between branches and has branching best practices built-in. It offers large teams a better way to branch and merge.
Gain Speed With Perforce Streams
Streams makes developers life easier. It helps them code more instead of dealing with overhead. And admins don’t need to spend time implementing workflows, complicated scripts, and sending angry emails.
With Streams, the structure is built-in to support complex branching for development and releases (no matter your strategy). Plus this foundation is flexible enough to adapt to how your team works.
How Perforce Streams Works
When a developer creates a branch, Streams sets up their workspace automatically. It knows what files are available and developers can see which ones are being worked on (and by whom).
Streams creates and shows the flow of change between branches.
Your team no longer needs to rely on naming conventions to determine how branches are related. And forget about documenting it on a white board! Because with Streams, you always know where your code needs to go.
Using the Stream Graph, developers can visualize how code is propagated. They can quickly check to see if they have the most updated version of the mainline or parent branch. If there are updates available, new code can be merged down. Then changes can be copied up. This helps keep your branches stable.
It’s that simple.
Remove complications with branching with Streams. It does the work for you. See for yourself.
Already using Helix Core? Getting started with Perforce Steams is easy.