NEXT GENERATION CM: Building: Change Management First

builds, there is always a need to verify full reproducibility so that you know that at a point in the future, if necessary, a full build may be generated without problems.

Developer Builds

A developer build is different from release and integration builds in various ways:

• The developer may choose to build in an isolated workspace, or to
  continually re-sync (aka. re-base) active changes with the latest (or
  perhaps another) integration environment, or perhaps to use a mixed
  strategy: isolate until the changes are in a stable known state and
  then re-sync.

• The developer does not generally create a snapshot of each build, especially if the edit/build/test cycle is only a few minutes long. Instead, the developer will generally save (aka. shelf) the source changes at a stable known state prior to continuing to work on the change.  It is recommended, however, that a complex feature be broken down into a set of logical changes that can be independently checked-in along a strategy that sees the riskiest portions of the feature implementation absorbed into the integration cycle as early on as possible (i.e. not close to release dates).

• A developer build is performed ad hoc and typically a lot more frequently than release or integration builds.  It is not uncommon, especially with today's IDEs, to see a developer perform dozens of builds in a day on the way to producing a new feature.

• A developer build is most often done as an incremental build.  Changes
  are made and only what is necessary is re-compiled and built.  Your build environment should rarely require a developer to do a full build.  However, for smaller products (e.g. < 100 KLOC), a full build can be done in under a minute these days. So this distinction is only important in larger projects.  Often the IDE is used to decide between incremental and full builds.

• Developer builds are not released in any way shape or form.  Only the developer is waiting for it.  (At least this is recommended practice.)  If another developer requires the changes of one developer, the correct approach would be to either check-in, or save (i.e. shelf) the change at the state that it will be used by the other developer.

There are, no doubt, other distinctions that can be made, but we need to get on with the process.

Automation of Integration Builds

The process of automating builds has a lot less to do with the build process than with the change process in your shop.  However many shops ignore this and automate the builds regardless of the change process.  When this happens, the automated build becomes king and change management, as well as configuration management, fall slave to the
build process. It is important that a proper change and configuration management process be used from which build automation will flow out rather than vice versa.

For example, consider a shop that says: "We're going to use a basic CM tool and automate nightly builds by pulling out the latest checked-in code, including 'make' files, and perform the build operation.  We'll then make the resulting build environment available for anyone who needs to make/test changes the next day."  The process is easy to implement: pull out the latest code (into the right places) and invoke the top-level make file (which will invoke whatever other ones are required).  It's simplicity means that
the process will be implemented accurately, so that's good.

However, there are numerous other implications and omissions in this statement,
and some have far-reaching effects.  For example, a developer will not check in any code that is not fully tested for fear of "breaking the build".  Good testing is good.  Leaving code checked out longer than necessary is not so good. In fact, a rapid add-on to the above process is: "You need approval for checking in any code changes that are