Essentials of the Build Process

Build  is central to CM. It's critical to do it right.

A basic build  capability is founded on 2 key fundamentals:  the ability to reproduce  the build and the ability to automate the build process.  Without these  two fundamentals, you're fighting an uphill battle.  Reproduction of the  build implies that you have a CM system able to capture the build  definition.  Automation helps to ensure that no manual errors can play  into the production.  But this is just a basic build  capability.

To move up the ladder, there's plenty more to be  done.  First of all, automation must be made available to all levels of  the team, from production down to developer.  Each member of the team  needs the same assurance that the right stuff is being built: developer,  integration, verification, production.

It's one thing to automate the  build, but in a continuous or regular integration cycle, there could be a lot  of work in deciding what's going into the build, especially in larger  projects.  So what's the secret to successful regular builds?  Make  sure you have quality going into the builds.  To get a series of quality  builds it's important to make sure of 2 things:  start with a stable  build; ensure the changes going into the build are of high quality.

If  you've got a half-baked build to start with, don't open the floodgates for  other changes.  First stablize the build through intensive debugging and  changes that move the quality forward only.  Once you have a stable build  you're in a good position for the second requirement - high quality  changes.

High quality changes
High quality software  changes are a product of many factors:

• Good people

• Good product architecture

• Effective peer reviews

• Feature and  integration testing prior to check-in
• Ensuring the changes that go in  are approved

Good people are hard to come by, but good  processes, with a good mentor, can make average developers very  effective.   A mix of software experience, application experience,  objectivity and strong design and software engineering skills are  desireable.

Good product architecture is key. I remember in  my very first job, I had 1 week to get a code generator debugged and  working.  I looked at the architecture and it just wasn't there.   The only way I could make the deadline was to throw out the existing work and  rebuild from scratch, although with a good bit of help from the existing work  that had been done.  The tactic was successful.  Now you might not  want to throw out your entire flight software or telecom system, but if there  are components that are overly complex and lack good architecture, your  changes are going to cause problems.  Your builds will have bugs that  need to be ironed out before restoring a stable build, the first premise for  the next build.

Effective peer reviews will eliminate a significant  percentage of potential build problems, while at the same time helping to  ensure that the architecture remains solid.  It's important to have a  good peer reivew process, but also a key developer involved, one that  understands the architecture and and the wider issues involved.  Peer  reviews are most effective when they become a teaching tool - it's critical  that new developers are aware of this going in.

Your process should not  allow code to be checked in unless it has been tested.  One of the most  effective ways to ensure this is to track