Control of CIs
Something that I have come cross regularly is that CIs have been changed or modified regularly on the environments after the release and deployment stages. It is very hard and time consuming to debug environment problems when CIs are not controlled. If project teams dramatically alter CIs in environments without the knowledge of the release team or without a change process, it can be difficult for the release team to identify why the run-time behavior of the application varies across environments. Someone mistakenly uninstalling software or changing some configuration in an environment can cause the application to behave differently than originally expected. Having a configuration item repository helps in resolving such issues, because one can refresh or restore an environment based on the CIs from the repository.
As project teams occasionally introduce on the fly changes to an environment in order to improve functionality for the QA team, new undocumented changes are being implemented. The release team needs to resolve the same CI issues across multiple environments. If a change to a configuration item is not managed in the CI repository, the change can go unnoticed until a major issue occurs later. The release team, which is the key contributor to a CI repository, should own and define the control and updates of CIs.
The environments verification is a process where the release manager regularly validates environments used across the broad spectrum of projects. It’s quite common that environments are allocated during the planning phase to projects, and over a period of time, the environments may not be required. Depending on the environments requirements across multiple projects, there could be a demand for a multiple number of environments in order to facilitate either testing or training. When either the projects have been completed or the training has finished, it is essential for the release manager to review if the environments allocated are still being used. The environments verification process provides general housekeeping activities to implement in the environments, and it regularly validates the usage of resources. These housekeeping activities could involve backing up servers, stopping the servers, uninstalling applications, upgrading servers, and clearing out installed files and applications in order to free up space.
The process provides several methods for collecting metrics and providing feedback to management, including:
- Visibility and information to feed project plan and delivery commitments, such as explaining what is available and when it is available.
- Data and metrics to calculate the cost—associated with the hardware, software, and people—and return on investment as part of the individual project and organization as a whole.
- Measurements for utilization, productivity, and costs associated with the resources.
- Informational data pertaining to what the team has and what the team needs or does not need in the future.
Environments communication is a process where the release manager communicates information relating to the environments. In order to provide good communication, the release manager should have answers to the following questions: What needs to be communicated? Who needs to know? How should we communicate?