The release manager must also plan the creation and allocation of environments to be in line with the environments requirements. It is a standard practice for a release manager to create and update environment plans. An environment plan can be a simple Excel spread sheet containing information, such as the type of environment (system test, UAT, etc.) used, the allocated hardware and its configuration, and dates. The environment plan can also be as detailed as a project plan.
Environment may differ based on configurations. Configurations are changes done on a environment to change the behavior of an environment, and they need to be managed in a controlled manner. Environment configurations are changes introduced to applications within an environment that affect the run-time functionality of applications. Configurations can be as simple as database connectivity or as complex as changing network configurations across a suite of servers in order to enable business functionality via an application. Whether it's hardware configuration or software configuration, configurations can change the run-time behavior of a test environment and its usability, and it is for this reason that you should never apply a development server configuration in a system test or live environment.
Configuration items (CI) are changes or configurations that need to be identified and managed on environments. The identification of CIs is one of the critical functionalities in environments configuration. This identification process involves gathering the attributes of CI, including the CI's name, version, location, and value, as well as its behavior across multiple environments. CIs are configurations that can change the run-time behavior of a system, an example of which is the information about a database connection, such as driver details or the initial connection pool size. In order to identify a CI, the release team needs to define a process to do so. Such a process involves reviewing and gathering details on CIs introduced in the system via the release process. This information should be gathered either via the documentation that comes with the release or by gathering the information from the teams introducing the CIs.
It can be a nightmare when development configurations have been applied to live. For example, if a database server name is not identified as a CI and the same configuration has been applied to live, there could be a situation in which information is available on development servers during live. It would take a major effort to resolve such an instance.
CI management is a process for managing the identified CI. In order to manage the CIs, you could perform activities such as creating a CI repository or defining the change control mechanism for managing changes to the CIs.
Creation of CI Repository
Identified configuration items used by the environment's release process need to be persisted (stored and documented. Persisting configuration items ensures that the release team maintains a unique set of CIs that can be used during the release cycle.
The Definitive Media Library (DML) is the ITIL v3 term used to outline the creation of a repository for CIs, and it is the centralized location for managing CIs that are then used for various releases. The structure of the DML—its design and contents—is based on factors including the configuration, release cycles, environments, and other specific information pertaining to the products used. The creation and management of DML is important from an environment management perspective, because environments will be configured based on the validated CIs maintained in the DML.