As discussed above, the phases available to a release are defined in the lifecycle selected for it. It might be helpful to think of a lifecycle model as a template used to create and drive releases. A lifecycle defines the progression of phases through which software passes on its way to production, which is represented by a production phase, or some similarly designated final phase. The lifecycle does not specify which particular environments are used for a release, but the general pattern. For example, a lifecycle might have the following phases: Development, Quality Assurance, and Production. Releases based on this lifecycle will have all three phases, although the actual environments used might vary from release to release. A lifecycle can also define the quality steps—gates—required to be successfully completed before software is permitted to progress to the next phase.
Tip
Develop strategies appropriate for each phase; strategies for high-ceremony production deployments might be inappropriate for low-ceremony environments.
The first step to define the path to production is to determine if an existing lifecycle model can be used, or if a entirely new one is required. Starting fresh with UrbanCode Release will naturally require the creation of lifecycles that mirror your normal processes and environments. As your experience grows, you will develop a stable of lifecycles that can handle most, if not all, of your releases. So the activities required to define the path to production will largely be determined by the availability of suitable lifecycles. The following tables outline activities based or whether or a not a reusable lifecycle is available.
Table 5. Creating a Lifecycle
Table 6. Using a Lifecycle
