NEXT GENERATION CM: Building: Change Management First

Types of Builds

We can classify builds into three distinct categories:  Release, Integration and Developer. 
They might be loosely categorized as:

• Release - Existing Build Record (i.e. Snapshot) Used (as authorized)
• Integration - Repository and Change Status Centric (typically nightly)
• Developer - Workspace Centric (repeatedly as required)

Release Builds

A release build is one that is done for a formal or candidate release of the build outside of development.  This may be for formal Verification, for Field Trial, Beta Trial, or Production. It differs from the other two builds in that there already exists a snapshot of what is to be
built in the CM repository.  You specify which snapshot you wish to build and then, using only data from your CM repository, your build tools/process produce the required outputs.

Integration Builds

An integration build is similar to a release build except for a few distinctions. 

First of all, part of the integration build task is to assemble the correct objects into a prospective snapshot which will be used for the build process.

Secondly, there is generally some latitude for modifying the prospective snapshot prior to freezing it.  This might occur, for example, if the build attempt caused compile errors, or
perhaps if the built product would not successfully initialize during basic sanity testing. Generally, urgent changes are produced to "fix the build". Different shops have different rules for such latitude within a build cycle.

Some will say: leave the initial snapshot and always create a new snapshot for any corrections, especially if there is not good traceability of what changes were required to fix
it.  I don't generally agree with this as it may cause confusion when a developer comes in the next day and sees four new snapshots, even if they are properly marked with an appropriate status in the repository.  And it may make it more difficult to pinpoint a snapshot in the past.  My opinion is that a snapshot is frozen when the build team puts its
seal of "sanity tested" on it.  This does not mean that all sanity tests were passed, but instead, that it is more beneficial to "release" this build to the development environment then to stick with the previous one.  And that will be a judgement call at times.

A third distinction is that integration builds are generally done on a specific timeline.  In fact, in many shops, they are automatically performed in the "middle of the night", that is, nightly builds. Does such a term has a meaning in your global development shop? Some of Neuma's customers do builds in the "middle of the night" at each separate development site.  In this way, they may actually be doing multiple integration builds a day.  Others focus each site on a particular development stream and so different streams of development are integrated at each of the different sites.

A potential fourth distinction might be to say that integration builds might be either incremental or full build operations, whereas the same is not true of a release build.  There is some wiggle room here.  I might recommend that, at least a couple times a month, full integration builds are performed.  This will help to verify the continued
correctness of the full build process.  Most shops tend to do full builds on a nightly basis.  This is dependent on the capabilities provided by the CM tools, as well as on the size of the operation.  If the CM tool knows what was built the previous night and knows the
impact of all changes going into the current build, there is not a necessity to do a full rebuild.  Similarly, if your build process has a reliable way of ensuring, for example, that a "make" operation will always do "the right thing", then a full build is not required every
night.  On the other hand, for Release