Essentials of the Build Process

demo as part of the peer review

Finally, it's important  that there is control over what is going to go into a build.  High impact  and high risk changes should be accepted early in the process, before the full  team begins working on the release cycle.  Tight control must be  exercised as release dates approach.  It's fine to have a developer who  can fix 30 problems a week, but if those are all low priority problems, and  we're nearing in on the release date, the result may not be desireable.   Typically, somewhere between 10% and 30% of problem fixes will introduce  undesireable side effects.  If only 5 of the problems really needed to be  fixed for the release, there's a much better chance of not having a severe  problem resulting.  Still, if it's earlier in the release cycle, there's  time to absorb such side effects and fix the problems before they go out the  door.

When you're controlling what goes into a build, it is really  ineffective to do so at build time.  This will likely create a minor  revolt among the developers, who have worked hard to complete their  work.  Instead, you want to ensure that change control is starting prior  to assignment of changes to the design team members.  Ideally, developers  begin work by selecting tasks/problems/features which have been approved and  assigned to them.  Then there's no rejection of unwanted functionality or  problem fixes.

Perhaps an even more critical side effect of having a  change control process up front is that work flows from the developer through  the process and into integration in pretty much the same order.  This  reduces the need for rollbacks, branches and merges, and allows you to adopt a  more optimized promotion scheme, and ideally one where you don't even need to  create separate promotion branches.  This in turn makes it easier to  automate selection of changes, as pre-approved changes can flow through the  system as soon as they are successfully peer reviewed.

Manage the  Superset Baseline, Build Subsets
Many organizations create and  manage a baseline for every build.  While this provides for full  reproducibility, managing a large number of baselines can be complex.   Typically a product has a number of variants.  While it is important to  try to move variant configuration into run-time or at least deployment, there  are a number of cases where this is not or can not be done.  In this  case, the best strategy is to manage a superset from a baseline perspective,  while building subsets.  It's natural to configure a product from a  subset of the baseline.  Instead of dozens of baselines, a single  baseline is used for management and reference purposes.  Each build can  be customized, as long as the CM tool tracks the build definition in terms of  the baseline.  

For example, build of the baseline with the  English option; build of the baseline with European standards; build the  baseline with a specific customization for NASA.  Tracking of builds  involves identifying the baseline, identifying the option tags, and  identifying any additional change packages that need to be added to it. As  emergency fixes are added, new builds can be easily readied just by adding in  the change packages for those fixes.  No need to specifically commission  a new baseline.

At Neuma, we create baselines occasionally, and then  create a series of regular builds off of each baseline, not just for customer  delivery, but for "nightly builds".   It's easy to look at the  difference between builds just by looking at the changes that have been added  to each.  It's like building a new house by saying: