Branching Strategy Enables Rapid Delivery

Branching Strategy — Introduction

Rapid delivery becomes possible by creating faster feedback loops through short-lived branches and merging earlier in the development process. The goal here is to enable your team with the process and the tools to collaborate, develop, and test together, releasing code changes faster.

I’m sure most developers are already familiar with creating branches for developing new features. Branching is the duplication of an object within a version control system (VCS) so that modifications can happen in parallel. Although it is entirely possible to develop code without a branching strategy, using a well-defined workflow can help teams accelerate change without fear of introducing change that may interrupt delivery. Many modern version control systems add features to help keep the collaboration going as well.

Let’s look at an approach we can take to help speed things up. There are several branching strategies to choose from but being intentional in how we work with them helps us focus on small batch changes. This approach of building small, iterative changes will help us know what’s changing in our artifacts at all times as well as minimize risk in deployment. The main goal is releasing working software to your customers. At a team member, or individual level, the goal is to make small, testable changes and keep the master/main branch “deployable.” Regardless of the model you choose, we believe you should be maintaining a master branch that can always be deployed.

What Does a Branching Strategy Look Like in Practice?

The Topic Branch Workflow (git/GitHub)

The Topic Branch Workflow (this can also be referred to as the Feature Branch Workflow) is based on creating disposable branches in Git that can contain the code necessary for the topic (aka: feature, bugfix or task). We like calling the branches “topic” to show that we can make any change we want in this branch. The idea is to help teams not get hung up on a feature branch being a “feature.” Some feature development could take months, but we think you can do this through several small branches instead of one long-running feature branch. In this model, a disposable branch is created from the master branch and all active development (commits, unit tests, code review) is done outside of the stable master branch. When the code is ready, a Pull Request can be made that compares the changes in the topic branch with those on master and can be merged in on approval.

Topic branches should reflect individual tasks and require 4-6 hours to complete. While this is just a guideline, anything larger than a day of development may need to be organized into smaller topic branches. As your development team embraces this process, they will learn and become better over time at developing smaller topic tasks.

Here’s how it goes:

1. Developer selects a topic to develop (story, task, bug, etc.)
2. Developer creates a new workspace by creating a new topic Branch from master
3. Developer develops locally on this topic branch
4. Developer receives changes from Master branch to remain up to date during development
5. Developer pushes topic branch to the source control repo when ready for review
6. A Continuous Integration Tool (such as Jenkins) automatically builds the product and runs associated tests to validate changes
7. Developer reviews changes with other team members (this process is much smoother with Pull Requests)
8. Team developers can comment on changes and approve or request updates
9. On approval and after all tests pass, the topic Branch is merged into master branch & local workspace (topic branch) is deleted

The intention of this approach is to create a deployable artifact with every successful merge to the master branch. Always have something ready to release. By keeping your master branch current, you will help your immediate team by having a stable base for regular changes and at the same time lower the chances of external teams misunderstanding how to integrate with your application.

What Else Can We Add to Make a Branching Strategy Successful?

Pull Requests

I’ve mentioned the term Pull Requests (PRs) a few times already but building that code review process and automated CI build/test in is a great way to ensure your team knows what changes are being introduced at all times. It’s true that you can merge automatically or bypass pull requests altogether, but building a culture of sharing and review will help other team members understand more about the product they support. This is something we use instead of formal code review sessions for daily small-batch changes. You may find that PRs won’t fix all the code quality issues but it is an awesome built-in feedback tool.

Team Chat Room Integration

Keep looking for more ways to speed up the feedback loop. Help your team support and manage the branching strategy in their normal development process. Connecting the Pull Request messages to a team chat system can bolster the feedback loop and ensure that changes are being reviewed quickly. Adding build failure messages to your Slack channel or HipChat room can bring attention to changes that need to be looked at quickly.

Seeing firsthand how making these changes help teams deliver is why we believe employing a branching strategy focused on small batch changes along with increasing the visibility and frequency of the CI process can produce a product quickly and reliably.

If you have any comments or questions, reach out to us.

‍