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.

_

_

A Code Line can be defined in terms of policies for when and how teams use branching, the branch structure, and the conventions the team uses around pre-merge checks, including testing. The Codes Line structures a team uses can have a huge impact of the ability of a team to deliver — not just because of the branching structure associated with it but also because of how well it fits in with the rest of the team’s processes. For agile teams, the impact of Code Lines can seem larger because the feedback on an agile project exposes problems sooner.

Of all the elements of Code Lines, branching seems to get the most discussion. I’ve heard quite a few people argue that branching is evil and to be avoided at all costs. It’s true that some people use branching in a way that slows the team down in unanticipated ways. But those slowdowns are often an indicator of other larger obstacles to agile development, including planning and testing approaches.

Using a Code Line structure that works for you team is essential for successful agile delivery, but changing your Code Line structure alone won’t fix your delivery problems if your planning and testing processes are broken. To improve collaboration (both speed and quality) and thus value you need to integrate code quickly. The right Code Line structure can help. But Code Lines are only part of the picture: testing, planning, and organizational culture also play a role.

In this series of short posts I’ll explain why the the problem teams face is not with their choice to use branching or not but rather with time to integration; in other words, having code that stays isolated for too long is at the heart of much of this pain. I’ll discuss the factors that contribute to that, and how to the branching model a team uses is only as good as the planning, testing, and feedback modes the larger team supports.

The next post defines some terms.