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."
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:
Production (including Disaster Recovery)
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 ...