Environment Purpose & Use
The first of five (5) subjects in Solution Environments describes the recommended environments used to support three concurrent Releases - Build, Candidate and Production. They enable the work needing to be done concurrently for each Release.
Environments - Purpose and Use
The diagrams below depicts the standard path of progression for the vast majority of changes made to any Product Solution following the ITM. Refer to the corresponding PowerPoint slideshow section below for an animated description which provides additional information and a better explanation for the sequence of events. For additional information on how changes process, also refer to the Reference Materials for Code Set Management.
Environments for the Build Release
To support ongoing development of a single Build Release over a number of Sprints two environments are used:
- DEV1; and
- TST1
Do not allow multiple Teams to each have their own DEV/TST Environments. If there are conflicts between their work, it is best to discover these sooner rather than later. While separate environments may make things easier on each Team, it will ultimately add work for everyone else and slow down overall Solution Delivery.
Environments for the Candidate Release
Once each Build is complete a new Candidate Release is created which then undergoes a number of Quality Assurance (QA) tests. Some amount of Defects should be expected, and while time permits these can be fixed. To support the QA's Certification Testing, and to allow for Defect fixes, three environments are used:
- DEV2;
- TST2; and
- QA2
Environments for the Production Release
Once the Candidate Release has been certified and UAT approved it is ready to move into Production (PROD). Should some unforeseen and urgent change be needed, there are two additional environments which allow those changes to be made without needing to impact either the next Candidate Release, or future Build Release.
- PROD
- DEV3
- QA3
Other Supplemental Environments
The environments described above are pretty much required to enable ongoing, iterative Build, Candidate and Production release cycles.
For a variety of reasons other Environments may also be desired. Some may be needed for just a short period of time; others may be longer serving.
But in general additional Environments should only be created to serve a specific purpose that cannot be addressed by another, existing environment.  Some sample are depicted at right.
Note:Â x, y & z are examples of optional environments that may be desired.
These may be lower Environments in the Development Domain (e.g., DEV4, TST5), meaning they are the source of change, or they may be higher Environments in the QA Domain, meaning they are more closely tied to Change &Â Version Control,