An Integrated Build and Release Life-Cycle Solution

Now that I have discussed the definition and breakdown of Software Build and Release Management and its inherent challenges, I can start to bring the process back together. How can you do things better? How can the process be improved? The heart of this answer is in the three following sections.

Manage Your Configuration Before It Manages You

As I said previously, Software Build and Release Management is essentially a part of Software Configuration Managementyou can't have one without the other. To have repeatability and reliability in building and releasing software, SCM is a prerequisiteversion control and baselining at a minimum. The same is true of completeness. You need to individually identify the set of configuration items going into the build (whether they are versions or collections of versions as components). You also need to be able to refer to them collectively as a single release going to the customer.

Hopefully, you are already using IBM Rational ClearCase or are familiar with another tool such as CVS. Chapter 2, "Tools of the Trade," describes the basics of ClearCase and ClearQuest. For more detailed information or further reading, refer to the product manuals or Bellagio and Milligan [Bellagio05].

Automate

Building and releasing software can be tedious, and if it is carried out manually, it is also likely to be error-prone. Automation is needed to "...ensure consistency and repeatability on the project. Manual procedures leave consistency to chance; repeatability isn't guaranteed, especially if aspects of the procedure are open to interpretation by different people" [Hunt99]. Repeatability and reliability cannot be ensured without automation. And as it was pointed out to me, with automation, when you find a bug, you fix it once, and then it is fixed for all time.

Automation enables traceability too. As Haas says, "Tracing ... is often neglected, because it's regarded as a big and almost impossible task" [Haas02]. Certainly, having to maintain a manual traceability matrix would support this statement. It is much better to get some traceability as a natural part of an automated build and release process.

If you want to be able to respond with agility and speed, automation helps too. After all, machines are far better and faster at doing repeatable tasks than humans. If you want to put changes into the buildwhen and as often as you wantyou need a simple button to click that says "Do the build now." Better still, you want that button to be clicked for you. (This is the concept of scheduling that I discuss in Chapter 6, "Running Your Build Scripts.")

The answer to some of these challenges has often been cited as continuous integration, "a fully automated and reproducible build, including testing, that runs many times a day" [FowlerCI]. Essentially, continuous integration is a process that integrates small developer changes into an integration build as frequently as possible, maybe as often as every couple of hours. Although I use some of the techniques and tools of continuous integration throughout the book, do not get hung up on the term and its associations with "agile development" [Cockburn01]. Essentially, it is just the refinement of a best practice; after all, software developers have been running daily builds and smoke tests for years.

Putting It All Together

So, you need Software Configuration Management and automation, but where do you start? How should you set up the SCM environment, and what should you automate? Hopefully the answer is in the following chapters. Essentially I will implement a complete and integrated build and release life-cycle solution. Figure 1.2 is a scaled-down version of the complete software development life cycle shown in Figure 1.1.

Figure 1.2. Integrated build and release life cycle

This solution utilizes the different aspects of Software Build and Release Management that I have identified. At its core is the environmentthe tools that are used and their configuration. This is described in detail in Chapters 2 and 3. The input or start of this life cycle is when you identify what to build, which is either informal (when part of a Private Build or Integration Build) or formal (when part of a Release Build). The identification process is basically a decision and validation checkpoint that uses generated Baseline and Change Request reports as its input. Consequently, there is no separate chapter for this phase; instead I describe how to automatically generate reports as an input to this phase in Chapter 9, "Build Reporting and Auditing."

Following identification, the life cycle iterates through the define-execute-report phases (and back to identify). In these three phases you define what you will build and how (Chapters 4 and 5), you execute the build (Chapters 6 and 7), and then you report on the results of the build (Chapters 8 and 9). The only variation on this cycle is when you decide that you want to create the Release Build. As I have said, this requires a more rigorous identification phase; therefore, you move out of the cycle when you release (Chapters 10 and 11). Of course, if the Release Build is not good enough the first time, there's no reason why you can't iterate through the phases again. Finally, in Chapter 12, "Putting It All Together," I revisit the concepts introduced in this chapter to summarize how a complete solution can be implemented, concluding with a walkthrough of the build and release life cycle for a sample project.