to the system integration, development and test teams, what has changed in each iteration of incremental integration. In the later stages of a release, this reporting is equally important to the change control board and to the build managers.
When an incremental build is ready for sanity testing, the first focus is on how well the build initializes. Then, the focus moves to changes in the functionality. You want your teams to have a list of problems resolved and features advanced so that they can first test these out and perhaps establish (or selected) an incremental set of test cases to be run. You don't have time to run a full regression test, typically, at least not before you make a go/no-go decision for moving the development environment onto the new build. But it sure is nice if you can quickly focus on fixes and feature areas addressed by the incremental build, because these are the most likely areas where problems will occur.
Make sure your tools and processes allow for automated and effective reporting. You can't spend a few hours at it because in a few hours you may well be processing your next integration cycle.
Where to From Here?
Though I've not actually made a case for incremental integration here, it's a way of life at Neuma. If you're going to embark on it, make your life easy:
· Use tools that support change packages
· Consider using a per-release-stream branching strategy
· Find a process/tool that helps you to avoid a branch-per-promotion-level strategy
· To define incremental builds, use a baseline plus a set of changes
· Use a tool that gives you adequate reporting
· Manage your risk up front, even before stream development starts
Then you'll make incremental integration work for you, rather than vice versa. Instead, you can tackle the bigger problems, like automatically calling the developer who introduced compile errors, improving your sanity [testing] and getting time off for the holidays.