Managing Branches in Static Analysis

In some respects, making software isn't much different than making sausage - it's messy and most would rather skip the details.  For those that choose the software development career, you have to live it everyday.  One area where I've seen significant mess is in the management of branches.  Delivery of software is seldom a one-time effort - with future versions expected to be delivered frequently.  Add to that the complexity of:

• software being available on different platforms and operating systems
• emergency software patches being made available
• different versions of the software customized to specific customers
• new major updates/rearchitectures/research simultaneously in the works as a production version

Pretty soon you may have branches all over the place.  Most organizations have a main branch which is the "gold master" with development branches being forked from it.  Many organizations will make it a requirement that the main branch should be release ready at any time.  Some organizations won't even allow edits on the main branch, instead requiring all changes to be made in forked development branch from the main branch.  Other organizations have developers happily chipping away at the main branch as well as creating multiple branches that may eventually be released.  Chaos ensues in these environments.

For those organizations that at least have a main and development branches, changes can be tested in the development branch prior to merge into the main branch.  Of course there may have been other merges that have taken place during the time that development branch was worked on and thus integration can be painful.  Software has lots of dependencies and when the assumptions are changed, software breaks in unpredictable ways.

The increasingly popular continuous integration process is designed to limit the pain of branch integration by doing it early and often.  Hand in hand with Agile, continuous integration has reduced the risk of complexity and therefore delay in releasing software.

Where does static analysis fit in?

There are lots of places where you can run the analysis.  You can run it regularly on the main branch (which probably already has a nightly scheduled build or continuous integration process).  This is a great way to quickly find out if something has broken, particularly during a merge.

Some organizations want to run it also on development branches - in a sense, creating a no new defects policy from branch pull to branch integration.  Of course when the development branch merges back into main, an analysis should be performed as part of the testing to see what breaks when things get merged.  This can be done on a manual basis.

Performing analysis on the development branch may not be entirely required -- it depends on when you want to be made aware of problems and when you want to enforce your acceptance criteria.  Analyzing every development branch will add to the IT costs as you will need more hardware to run the analyses on development branches.  For some organizations this is overkill - for others this is essential as their branches may be long lived and they need to meet their criteria as early as possible.

One additional way to still have the acceptance criteria enforced at the main branch but still enable developers to find and fix problems as they develop in the development branches is to have developers analyze the code they are working on in their own desktops.  Some static analysis tools provide a "desktop" version of their tool so that developers have the power to analyze the code they are working on and iteratively fix problems well in advance of a merge.  This enables them to find and fix problems early.  However, one must keep in mind that the development branch and particularly the code being worked on by a specific developer may vary quite a bit from the main branch and thus not all problems can be found at the desktop.  Frequent merging should help solve that problem.  Regardless, doing some analysis on the development branches enables developers to fix problems sooner which pays off in higher quality software earlier and better productivity.