Configuration and Change Management
Configuration Management
Configuration Management is about anticipating and planning for changes in your product before they happen. It involves scaling your project through different stages of the SDLC while maintaining the product value in different environments. It opens up the opportunity for change control through documentation, accountability and the regular auditing of the project.
Once a project has a baseline, configuration management comes in and evaluates the system to allocate different rights to different stakeholders.
- It coordinates who will make changes and how changes will be made.
- It coordinates who approves and disapproves changes and when changes can be approved.
- It audits changes and maintains that the new changes do not harm the base project.
- It oversees how any change in the product specification should be done in regard to maintaining a healthy and product.
- It provides guidelines on how the project integrates with other tools and stages in the SDLC.
Configuration management encompasses all activities that reduce the risk of integration failure due to component changes on the project at any stage of the SDLC.
The key elements of configuration and change management are:
Version Control: The ability to commit code into a common repository, retrieve it anytime, maintain full version history and allow teams to commit changes to the same repository.
Baseline and release information: Tells when the last version was released, what it contained, and having a baseline version to roll-back to at any time.
Audit & Review: Audits the process to ensure that people are actually following the configuration management and versioning system properly, correctly and consistently.
Document Process: All agreed upon process are thoroughly documented as an effort to manage changes in the development team and allow scalability outside the development team. This way new developers can pick up on what and why specific things were done when they were done.
Build, Integrate and Deploy Scripts: Scripts are written to prevent the need to re-do specific tasks over and over again. Some scripts are written to maintain the state of the infrastructure i.e Infrastructure as code. These scripts are then used in pipelines to run specific tasks and ensure that all the steps of the SDLC are successful before publishing changes.
Different products have different configurations, specific to the product and its needs and integration with other products or services. It maintains some level of sanity in a project seeing as it sets standards and regulations to be followed in order to accomplish specific tasks. Examples of configurations include software versions, authentication credentials, API keys, project requirements e.t.c
Change Management
Change management is the methodology or procedures used to handle updates or new elements introduced into systems, ranging from code, configurations, system updates e.t.c. Change is a constant in all products and it requires a sound process to implement it in order to avoid chaos.
Why do we need change management?
We need change management because it outlines the steps necessary to ensure a streamlined, transparent and efficient way of introducing and keeping track of change in systems. It provides a safe way to implement approved changes to the project without interfering with the base project. It also introduces a change management board(usually comprised of the product developers) that understands the product and approves or disapproves changes.
Change management also involves having a change control process. This is the process to be followed when implementing or requesting changes. This is usually handled in Continuous Integration/Continuous Deployment pipelines. They ensure that new changes do not break the previously implemented changes.
Change management also calls for accountability in the development team as someone is always accountable for ensuring that changes are successfully implemented and deployed. Every release version of the product has to be adequately documented in order to allow users to see changes made from previous versions and cope accordingly.
Configuration and change management in servers.
Servers, like any other software product, require configuration and change management. Configurations in servers range from subtle things such as Linux image versions to more detailed things such as port routings and memory allocated to specific instances. Most servers have their states stored in repositories as code, this approach is known as Infrastructure as code and became popularised due to the increase in the use of cloud computing platforms. Changes in server states are usually requested by the product stakeholders but implemented and approved by the devops engineers.
