Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

24.3. Classifying the Releases

The first step in defining the deployment strategy is to classify the various releases or packages and their purpose. There are many different ways in which the different packages can be sliced and diced, so it is a question of what's the best fit.

I find the best way to organize the release packages is to sit back and imagine a clean machine (or environment) and an installer, like the one shown in Figure 24-3. It doesn't matter if you're using a formal installer or scripts to deploy the software. If there were only two installation options in the drop-down list, "test" and "production," what would you expect to be installed and where would you expect it to reside? Using an installer would essentially be the same as running a script called "Install Test Release."

Figure 24.3. Figure 24-3

One of the simplest ways to build up a candidate list for the release packages is to answer the question, "What is it being installed for?" To answer that question, you must look at the following activities involved in the lifecycle:

• Unit testing

• Integration testing

• Smoke testing

• Functional testing

• Technical testing

• Acceptance testing

• Production (including Disaster Recovery)

• Review

This list really just breaks down into two high-level categories: test releases and production releases. However, it provides a very useful starting point for this exercise. The different activities ...