Is branching the answer? There is a better way…
By Ed Taekema in CM, Collaboration, Software on August 28th, 2008
Well, what is the question first. Here it is: How do I promote code changes through a team to release
Version control tools since almost the beginning have supported some sort of branching scheme. We did this to allow concurrent changes to files without content loss. This was needed as soon as teams of software engineers worked on the same code base. Where they changed the same file at the same time, they branched the file and then merged the parallel changes. Branching is an effective method to allow people to work together safely.
The next step was to use branching to track separate “releases” or branches of the whole application. This allowed teams to work on a maintenance release in parallel with a “Next Big Thing” release.
From here, branching kind of explodes. Branches are often created to represent each step in the process used to write software for a release. For a typical project, the following types of branches will often get created:
- Main line branch – represents the final production code line.
- Project Branches – each major development effort gets their own branch to work in to keep from interfearing with other projects or production support that is in the main line.
- Build Branches – This branch represents the first place that new code is merged to and “smoke tested” … and is often used as the basis for things like Cruise Control based continuous integration builds.
- Testing Branches – these branches are used typically by QA and testing organizations and represent work that is complete and ready for testing.
- Developer Branches – Rather than having all the developers working together in one branch, it is often recommended that each developer work in their own branch and promote code to other developers by merging their branch to the project’s build branch.
This problem that branching solves here is dramatically different from the original problem of concurrent file modification. Branching is being used to automate sharing of code changes within a team. There are problems with this approach:
- It encodes the team’s process into the file history of code making it difficult to quickly adjust the process as team conditions change.
- Using a merge to promote changes introduces the possibiliy of an incomplete or bad merge that hides its effect, namely that the code isn’t promoted, or worse additional code is injected that doesn’t belong.
- It clouds the history of file changes with multiple merges that make it difficult to understand if changes have correctly been merged and makes it hard to understand what is in a build of the software.
- It makes it hard to promote code to software teams that don’t have a close common branch. For example, you want to merge a fix from one project to another but the only common branch is the main line and merging there will hit production before you want to.
My experience with Telelogic Synergy (day job) says that there are other solutions. Its approach is to leave branching to handle concurrent development. In other words, file history branches only when there are conflicting or parallel changes to a file. The flow of changes between developers, teams, builds etc is done by routing the change set (Task in Synergy) to the appropriate person or sandbox of the software.
I’ve found this to accomplish several key things:
- It is much clearer what is actually in a build of the software since there are only real merges in the file history (in other words only merges where file changed in parallel … not countless merges that are simply code promotions or worse opportunities for bad merges).
- I can quickly adjust how the team works by tweaking how change sets are shared, without having to worry much about how the file history has been manipulated.
- For those odd situations where I need to manually promote changes to an unexpected place, the change set can be manually promoted.
Of course you couldn’t do the above without being able to detect missing intermedicate changes which happy Synergy manages well.
So, we’ve had the branching hammer in our tool belt since the dawn of computing … I just don’t think that managing the code sharing process on a team is a nail that needs that hammer.
08/28/2008 at 12:32 pm
Managing promotion in source control does a pretty nice job of isolating teams from each-other but that extra slowness does impact the value of any continuous integration you do. There’s a need to strike a balance there.
But once you get into testing, I think source code promotion has really run its course. You don’t test source code outside of static analysis. Most teams test built binaries of some sort. The problem then is about managing builds and tests of those builds as they move through the SDLC.
08/28/2008 at 8:25 pm
I think it comes down to the size of what you promote … if it is large change like an entire enhancement request .. it might impact continuous integration … but if the changes are tracked at a level somewhat smaller and also promoted that way, it should be fine.
The other thing to consider is that the granularity of promotions needs to change as the process gets closer to release or production. For instance, early promotions from sub team to whole team can be done in small chunks, but when promotions target testing and eventually production or release, the promotions are increasingly larger, or incorporate larger sets of changes.
In my experience using Telelogic Synergy, this is accomplished by defining a CM Process that starts by promoting the developer defined change set (Task in Synergy speak) but then transitioning to Change Request promotion for promoting to testing environments and production. In Synergy’s case, Change Requests group a set of related Tasks. I think this flexible approach to promotion works really well and doesn’t have some of the problems of a file – branch method I outlined above.