Making Incremental Integration Work for You

• impact they have on other files - ideally using the build definition record.
• Incremental Changes to a Build Enviornment. Once you have an incremental build definition, you want to be able to update your environment in order to do your build operation. CM tools need more flexible file retrieval capabilities so that its easy to populate, not based on a set of problem numbers or a baseline definition, but on the changes and the impact of the changes. Older proprietary tools (e.g. PLS and SMS) support a file expression capability for identifying and retrieving the correct set of files in one simple operation. Very few modern CM tools (e.g. CM+) support this same capability.

Reporting and Incremental Integration

Finally, it all comes down to knowing what you're doing and what you've done. Even more important than release note generation, I would claim, is the ability to be able to report 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 selecdt) 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

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