Configuration Management Plan
November 3, 2019
Revision History - (see this repository's git history)
Executive Summary iii
1 Overview 1 1.1 Purpose 2 1.2 Scope 2 1.3 Program Description 2 1.4 Reference Documents 2 1.5 Glossary 2 2 Configuration Management Roles and Responsibilities 3 2.1 CM Responsibilities 3 3 CM Activities 4 3.1 Configuration Identification 4 3.1.1 Configuration Item Identification 4 3.1.2 Configuration Documentation 5 3.1.3 Product Structure 5 3.1.4 Product Identification 6 3.1.5 Naming Conventions 6 3.1.6 Labeling 6 3.1.7 Classification Requirements 6 3.2 Configuration Baseline Management 6 3.2.1 Functional Baseline 7 3.2.2 Allocated Baseline 7 3.2.3 Developmental Baseline 7 3.2.4 Production/Operational Baseline 8 3.3 Change Control 8 3.3.1 Change Management 8 3.3.2 Communications 9 3.4 Configuration Status Accounting 9 3.5 Configuration Auditing 10 4 Build and Release Management 11 4.1 Libraries 11 4.2 Automated Tools 11 4.3 Version Control 11 4.4 Build Management 11 4.5 Version Description Document 11 5 Reviews 12 6 Configuration Management Measures 13
| Version Number | Description | Date |
|---|---|---|
| 1.0 | Initial Version | 2019-11-26 |
Configuration Management (CM) is a uniform practice for managing changes in software, hardware and documentation throughout the acquisition or development project.
The CM plan should be produced as part of the project planning phase of the Solutions Lifecycle (SLC). The CM activities should continue throughout the life of the delivered end-product, and therefore, at the project’s end, the adopted approach should be transferable to the organization responsible for operational maintenance. The executive summary should be an overview of the CM plan, highlighting the major points of each section in the plan.
Touchpoints is a government wide service provided by the Office of Products and Programs, of the General Services Administration. The core service is run on Cloud.gov. Touchpoints PMO uses Agile development methodologies, and this configuration management plan outlines the manner in which the team establishes and maintains consistency and reliability of the system’s performance and its functional attributes as they relate to requirements, design, and operational maintenance throughout the systems lifecycle.
This CM Plan documents Touchpoints' development processes, configuration management policies and practices, roles and responsibilities, and the tools used to support these workflows.
- Program Management Office (PMO) – serves as Product Owner (PO) and is collectively responsible for the system’s operation and maintenance. The PMO sets development priorities, reviews and approves all requested changes prior to development, and gives final approval prior to changes being pushed to production. The PO also performs acceptance testing for user-facing changes and deployment scheduling.
- Developers – create code changes and tests, provide code reviews, and prepare Pull Requests for deployment after changes have been accepted/approved. Developers also perform acceptance testing for back-end changes.
- System Administrators – deploy code changes to production.
The entire Touchpoints system should be under configuration management throughout the Software Development Lifecycle (SDLC):
- Touchpoints related custom applications
- The Cloud.gov infrastructure for infrastructure related changes
- Connections to relevant components managed by GSA IT and Cloud.gov, such as Nessus vulnerability scanners, Firewalls, DNS, OS logging, etc.
Specifically, the Configuration Items identified for Touchpoints are identified in Table 10-2 of Section 10.2 of the Touchpoints LATO SSP.
This CM Plan describes policies and practices for common source control, build automation, automated migration and deployment, test automation, and continuous integration. The workflow for change scoping, requests, testing/approvals, and deployment is described. This is also described in the SSP in Section 13.4 Configuration Management.
All changes must be reflected in GitHub. As an agile team, all development cycles are incremental, there is no final push to production followed by a maintenance phase, as in waterfall style software development.
To ensure continuity and reduce the risk of loss of work, all developers check their code in to GitHub as Pull Requests. As such, the entirety of the codebase is discoverable at any time and all changes are tracked on a change by change basis. All code is versioned via Git, including application code, tests, builds, and deployment automations. Continuous Integration is performed by CircleCI and all Pull Requests are reviewed under an enforced peer review process requiring a Touchpoints PMO or Developer’s approval before adoption into the code base.
None of the servers in the production or staging environments are created by the Touchpoints PMO. All physical hardware and networking is managed by Cloud.gov and/or GSA IT SecOps. Configuration management for these static assets/inventories of hosts is accomplished through the use of Cloud Foundry manifest files and Cloud.gov configurations maintained in a GSA controlled GitHub repository.
By automating the configuration of application(s) and baseline OS configuration, we are able to provision and audit the (re-)deployment to servers during routine maintenance or a failure scenario.
The application provisioning code is run through automated testing using RSpec in CircleCI.
All tests must pass before code can advance in the development lifecycle (using the develop branch at https://github.com/gsa/touchpoints which is then automatically deployed to the staging environment. Staging features are verified by the Touchpoints PMO.
Next, code is merged to the master branch and automatically deployed to the Demo environment.
Then, code is merged to the production branch and automatically deployed to the Production environment.
Code changes may include new features, security fixes, or improvements on existing features, and tests are written as needed for new features in the code or bugs (regression tests).
The iterative nature of agile kanban development requires continuous integration.
Developers always begin work on stories from fresh branches off the develop branch.
This ensures that every new change will work with the most recent updates to the system and that there will be fewer unforeseeable issues.
The small size of the team means there is minimal overlap in the areas of the code any one developer is working on, so conflicts are relatively rare.
In the event that a code change affects the System Security Plan (SSP),
the affected control response is updated, and the ISSO and ISSM are alerted to the change by the PM.