The environment lifecycle defines the various stages/phases in the life of an environment. Further, the test environment lifecycle describes the period of time over which an environment is developed based on demand, brought to the organisation and eventually removed from the organisation. The cycle is broken down into six phases:
Demand is the first phase which helps in gaining an understanding of the demand for test environments in the particular project or programme situation. It then determines and details the test-specific requirements, such as the number of test environments, scope of the data sets, configuration, integration, etc. Demand initially comes from the overarching projects, and early insight will ensure demand helps in proactively planning, coordinating and providing fit-for-purpose environments in a timely fashion.
The design is phase about turning demand into a design of the test environment. This helps to determine the solutions for provisioning test environments based on what is in scope. This may include building new environments, either from the ground up or from templates, and/or sharing existing environments within the client landscape. This phase consists of determining tool requirements and set-up, to manage artefacts (code, packages, configuration) for re-use, and compliance and audit purposes.
The build phase is about actually building an environment based on a design. It’s about provisioning infrastructure, application configuration and integration into the right environment at the right time. This also includes managing the provision of test data within application environments and keeping code base up-to-date (aligned with production) etc.
In its operational phase; once the environments have been provisioned, the test team will require support on many levels from the environment team, including Incident/request/problem/access management, change delivery (configuration, builds, firewall rules), job execution (batch, file transfers), release and deployment support etc
This is the phase driven by demand. Once an environment is released by a project it can be allocated to another project based on requirements. The environment can be repurposed subject to requirements. For instance, if initially an environment is built for system testing and now the same project or another project requires it for performance testing, then the environment can be reused and repurposed based on the requirement. In this case, increasing capacity.
An environment can be decommissioned if future demand does not warrant continued investment. This helps in optimising resources and saving cost.
For more information, read Test Environment Management.