Configuration Management Plan
- Revision History
- Executive Summary
- 1.0 Introduction
- 2.0 Configuration Management (CM) Roles and Responsibilities
- 3.0 CM Items
- 4.0 Configuration Management Activities
- 4.1 Common Source Control
- 4.2 Build Automation
- 4.3 Test Automation
- 4.4 Continuous Integration
- 5.0 Configuration Management Tools
- 6.0 Change workflow
| Version Number | Date | Description | Authors |
|---|---|---|---|
| 1.0 | 2019-11-26 | Initial Version | Ryan Wold, Lynnette Jackson |
| 1.1 | 2021-02-05 | Initial Version | Ryan Wold |
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 Technology Transformation Services division of the General Services Administration. The core web application service is run on Cloud.gov.
The Touchpoints PMO practices agile development, and this configuration management (CM) 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 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 code 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 main 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.
Touchpoints uses GitHub to manage the product life cycle.
This section identifies these tools and their purpose:
- Git and GitHub – Uses Git to control versions of Touchpoints code. GSA has an organizational account on GitHub, which stores all code repositories for Touchpoints applications. Git and GitHub track code changes at the commit level. Code branches for work in progress are synced to Github at least daily to minimize the risk for lost work.
- Any change/fix/feature is initiated and discussed, during Touchpoints Sprint Planning which can be tracked here in the Backlog. Every change will have agreed on prioritization and acceptance criteria before work is started and referenced when a Pull Request for any item that is submitted for review.
- All configuration change requests must be represented in GitHub.
- Steps taken from a Pull Request for any change to application within our Production environment consist of the following workflow:
- A continuous integration (CI) server handles automated tests of the committed changes to application code repositories or remote codebases.
- That Pull Request is run in CircleCI to ensure tests pass. If tests pass and a Touchpoints PMO or Developer reviews and approves the Pull Request it can be merged into the
developbranch. - All changes are deployed from the develop branch to staging environment automatically, and manual testing is performed by the Touchpoints PM.
- Proposed changes are then discussed within the Touchpoints PMO, any uptime concerns or timing preferences on deployment to production are communicated.
- After inter-team communication occurs, code changes can be applied to production. Then, the system is actively monitored and logs are reviewed briefly to ensure there are no visible issues after deployment. If issues exist, changes can be reverted to previous state.