Branching and Integration Time

Discussions about branching often focus on the wrong thing. Unintegrated code sitting around slows teams down, whether the code is in a branch or in a developer’s workspace. Discussions about improving pace of development often veer into arguments about branching. Arguing about whether branches are good or bad will distract you from the more basic question of “Do changes get integrated and tested rapidly enough to ensure the rate of delivery we want?”

Integrating too slowly is the main challenge to agile development. Slow integration makes it harder to show incremental progress and maintain an always working code line with valuable features. Frequent integration helps the team deliver incrementally and maintain working software. Your process should help you to integrate quickly so that you can deliver value at a good pace.

The ideal integration frequency varies from team to team. Merging once a day is good, more frequently can be better, but too often can cause churn and overhead if you aren’t doing it well. Team and planning dynamics are key decision factors, but some things are universally true: small frequent commits improve reliability, changes that move the design forward are more valuable than trivial changes. These factors often lead to once a day as a good initial target, but each team needs to decide what values of “small” and “frequent” work for them. (Retrospectives are a good forum for exploring that question.) Automated testing is essential to moving quickly even though it can add a small increment of time to the commit interval in the short term.

Getting this to work well can be challenging, but it is doable. Small useful increments and effective tests are easier than many believe. Though you may need to change your mindset.

Branches and reviews can improve collaboration for both co-located and remote teams. So rather than starting with a “branch or not” conversation, start with an integration rate goal and evaluate how long it takes code to get into production. The next post will talk about why branching can have advantages for your team.

(This is adapted from an earlier Techwell article)

Perceived Safety and Branches

Branches are often used with the goal of improving stability. This going wrong is often the source complaints abut the use of branching. This post briefly examines the rationale behind branching some non Main Line branching strategies.

Workspaces and Delays

A Brief Detour from talking about branching. There are risks with branching, there are other paths that lead to deferred integration, and all the issues that arise from that.

The Trouble with Branching

Code Lines defined terms, Why Code Lines Matter motivated why SCM Process matters, and the post addresses a major risk people see in using branching.

Why Code Lines Matter

Code Lines defined some terms. Here I’ll start getting into how SCM and Version Management concepts affect your day to day work

Code Lines

My last post introduced the series. This post defines some terms and sets the stage for discussing the value of simple branching for agile teams

It's About Time: Branching and Integration

This post kicks off a series of articles about the role of branching on an agile software development team. Since Software Configuration Management Patterns came out quite a while ago, it seems like time to revisit some of the concepts in it. They are still relevant, though a different approach to explaining how to apply them might be useful.