Configuration Management Plan
The Configuration Management Plan (CMP) aims to provide the technical and administrative guidance for managing the configuration items (CI) associated with the Continuous Authorization Service (CAS) project which is to be placed under configuration control. This document defines the project’s structure and methods for identifying, defining, and baselining CIs, as well as controlling modifications and releases of CIs.
| Process | Tools & Techniques |
|---|---|
| Change Management (Code) | Github, Jira (or other issue trackers) |
| Documentation Management | Wiki, Change log in documentation |
| Quality Management | Jira (or other issue trackers) |
| Name | Responsibility |
|---|---|
| Yue Qi | Quality management Configuration management Software development |
| Tong Xiao | Project monitoring and control Software development |
| Haoqi Hu | Risk management Requirement engineering Software development |
| Jingze Shi | Architecture design Software development |
Configuration identification process consists of selecting proper CIs of the system, and setting and maintaining baselines of each CI throughout the CAS development lifecycle. CIs shall include:
- All CAS related requirement documents
- All CAS related design documents
- All CAS related testing plans and results
- All development code required to build the CAS components
- All CAS related data and configuration files
- All CAS related cloud infrastructures Configuration baselines shall be established progressively according to the current development phase. Detailed information of each baseline shall be tracked and maintained using the methods and tools described in Section Methods & Tools.
There are two types of configuration baselines that will be established for the project:
- Development baseline
- For code components, a development baseline will be established after passing all the unit testing, integration testing, and a simple code review process. It allows the new changes of code to be merged to the master branch of the project development repository.
- For documentation, a development baseline will be established after the documentation changes passed the documentation inspection. After that, the new changes could be added to last development baseline, which is stored locally and shared by only the development team.
- Production baseline
- For code components, a production baseline will be established for a release of intermediate or final product, based on the most recent development baseline. It requires the code component changes to pass all the unit testing, integration testing, system testing, and acceptance testing, and no major defects found in the static analysis and code review. It allows the new changes of code to be merged to the release branch of the project development repository.
- For documentation, a production baseline will be established after the documentation changes passed the documentation inspection and are validated by the clients. After that, the new changes could be updated in Wiki.
In this section, version control is mainly focusing on code components. The main tool for version control of code component is Github. The version control process for the CAS project is defined as follows:
- One central repository for the CAS project should be established, which holds the current and historical versions of all configuration code objects.
- Two branches should be established: the master branch for development, and the release branch for deployment.
- Each developer creates his or her own working folder to develop and make changes.
- Each developer creates his or her own branch to record the local changes.
- When the changes of code have passed all unit and integration testing, the developer can start a pull request to the master branch.
- A pull request must be reviewed and approved by other developers before merging into the master branch.
- If there is an intermediate or final release of product, the commit of this release must be tagged by the release version in the master branch.
- The commit tagged by the release version shall be then merged into the release branch (also properly tagged) by the configuration manager.
CAS project mainly uses the Amazon AWS as its cloud infrastructure. The cost of the cloud resource usage shall be properly managed using a standard process.
- Initialize the cloud infrastructure using AWS EC2 on demand instances.
- Estimate the usage of cloud infrastructure resources of next working week.
- If there is no need for development on the cloud infrastructure, the instances should be stopped by the configuration manager for budget managing purpose.
The configuration audit should be part of an informal technical review. The audit will discuss about:
- Has the change specified and approved been made?
- Has the process been followed?
- Has the change management procedure been followed?
- Has the change of code been consistent with the change of architectural design?
Potential solutions should be also discussed in the configuration audit. For example, if the change of code is inconsistent with the architectural design, the impact of change towards the key quality attributes and the refactorization cost should be considered to make the final decision.