Practice5.Nightly Builds

Practice 5. Nightly Builds

In order for your team to ensure that your software is working, it should be completely rebuilt from scratch one or more times per day. The build should include as many automated tests as possible to catch integration problems early, and the result of the build should be an installable product image. Nighttime is a good time to do this because no one is working on the code, and there are plenty of idle computers available. However, if you can do it, there is a lot of benefit to building the product as many times per day as possible. If the build or tests fail, fix the problems first thing in the morning and don't let anyone integrate any additional work until after the build succeeds again, otherwise there is a risk of multiple bad changes accumulating that will jeopardize the quality of the product.

Nightly Builds and Configuration Management

Ensure that all assets required to build and test a project are stored in your CM tool. An excellent test is to regularly start from a "clean slate": remove everything associated with your project from your disk, get the latest version of all the files by checking them out, do a complete build, and ensure that all the automated tests still run. The best time to run this test is every night, as part of your product's nightly build.

Store your entire project in your CM tool. If your project includes user documentation, web pages, demo content, etc., make sure it is all in your CM tool. Too often, the project team will only focus on its software, but very few projects consist only of software. This can cause problems when it comes time to integrate the various pieces because manual work is often required to gather everything together and then verify that all the pieces are still compatible. No manual work is required if all the parts of the project are kept together and the entire project is built every night. You should never accept separate build processes and multiple integration steps.

Pay Attention to Build Times

You should always keep an eye on the product build times. The faster you can keep the build, the faster the feedback you'll get when you need to quickly generate a cut of the product. Long build times encourage developers to take potentially dangerous shortcuts and also to pay less attention to keeping the problem under control.

Long build times are almost always an indicator that something is wrong with the structure of the product: too many interdependencies between modules, not enough modules, or worst of all, duplicated or unnecessary code. In languages like C or C++ there might also be "include file" bloat, with include files making unnecessary #include statements or declaring inline functions that should be moved to the .cpp file.

Here's an example of the most common problem:

// File: A.h // This class contains a member variable that is a pointer to an // instance of another class. // #include "B.h" class A {        ...    protected:    class B *m_Bptr;    ... }

The problem with this seemingly innocent class is the #include of "B.h," which is the file that declares "class B." If this file that declares "class A" (A.h) is included in many places in your product, build time will suffer because the preprocessor is going to spend a great deal of time processing A.h AND B.h, when in fact B.h is not necessary because a forward declaration can be used in A.h and an include of B.h only added to the .cpp files that actually need to use "m_Bptr":

// File: A.h // This class contains a member variable that is a pointer // to an instance of another class. // class B;    // All class A needs is a forward declaration of             // class B. class A {        ...    protected:    class B *m_Bptr;    ... } 

Tip: Timestamp the start and end of all builds

A good practice to follow is to timestamp the start and end of all complete builds and keep a log. Then, write a simple script to catch large increases in build time. If possible, produce a simple chart that can then be put on a web page and quickly viewed. It's always easier to glance at a chart than to dig through a log file!

The Entire Team Owns the Product Build

It should be part of the team's mindset that it is everyone's responsibility to pay attention to the product build. Unfortunately, some developers I have encountered feel that cheaper labor should be hired to look after the builds. This attitude is wrong and unprofessional. It is wrong because the cheaper labor won't know the code and won't be able to fix any problems when they're foundonly the actual developers can do so. It is unprofessional, because hiring someone else to do part of your job is like a mechanic hiring someone else to look after his tools…!