- 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
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.