What is Configuration Management in DevOps?
Shreya Bose, Technical Content Writer at BrowserStack - September 7, 2020
What is Configuration Management?
In software development circles, configuration management refers to the process by which all environments hosting software are configured and maintained.
Every development pipeline requires multiple environments for multiple purposes – unit testing, integration testing, acceptance testing, load testing, system testing, end-user testing, etc. These environments become increasingly complex as the testing moves towards pre-prod and prod environments. Configuration management is an automated process that ensures the configuration of these environments is optimal.
The configuration of testing environments is critical for the success of testing teams. Accurate configuration makes every resource – servers, networks, data centers, operating systems, IT assets, configuration files – function as they must to facilitate success. These environments must be meticulously managed, and all configuration changes must be tracked to ensure that they are traceable.
Inadequate configuration management can lead to system outages, data breaches, and leaks. Not to mention the fact that bad environments make for improper, incomplete, and shallow tests.
Using Configuration Management is imperative in DevOps infrastructures. Remember, DevOps is about facilitating speed, accuracy, and efficiency. Configuration Management helps to automate mundane maintenance tasks, which frees up dev time for actual programming. This increases agility, both on the part of individual devs and the organization as a whole. At this point, it would be correct to state that Configuration Management is fundamentally necessary for setting up a DevOps-driven framework.
Elements of Configuration Management in DevOps
- Configuration Identification: Identify the configuration of the environment to be maintained. One can also use discovery tools to identify configurations automatically.
- Configuration Control: Remember that once the configuration has been identified, it might not remain unchanged. Consequently, there needs to be some kind of mechanism in place to track and control changes to the configuration. Most configuration management frameworks have a change management process in terms of regulating these configurational changes.
- Configuration Audit: Even with control mechanisms in place, changes may bypass them. Configuration audits at regular intervals prevent such incidents. When choosing Configuration Management tools in DevOps, select one that facilitates these three functions with the greatest measure of efficiency and ease.
Like DevOps itself, Configuration Management spans across operational and development activities within an organization. The primary components that comprise comprehensive configuration management are:
- Artifact repository
- Source code repository
- Database for Configuration Management
An artifact repository stores machine files – binaries, test data, and libraries. Consider it as a database for infrequently used files within an environment.
In a DevOps setup, Continuous Integration practices often create artifacts such as binaries. Think about it: developers are encouraged to push builds to the mainline continually. Each code push triggers a build, which generates a binary. The bigger the project, the more the number of binaries. It is not uncommon to end up with thousands of binaries in the artifact repository. These files don’t always have to be accessed, but they must be kept at hand.
Source Code Repository
The source code repository contains all versions of code. In other words, it is the database of source code used by all developers on a team or project. Apart from storing all the code, it also stores other relevant components – test, build and deployment scripts as well as configuration files.
Now, certain teams or projects may use the source code repo as an artifact repository as well, to store binaries. This, however, is not an ideal practice. When dealing with DevOps Configuration Management, one has to handle a massive number of builds and resultant binaries. Among these numerous binaries, some may need to be stored in specific ways and formats. It is much less confusing if they are stored in a separate artifact repository.
Everything that is readable by humans goes into the source code repository. This does not include software binaries, so store them elsewhere.
Source code repos fall into two categories:
- Centralized version control system (CVCS)
- Distributed version control system (DVCS)
In the former (CVCS) the source code is stored in a centralized location. In the latter (DVCS), the code is stored across numerous terminals accessed by developers. DVCS is usually considered the quicker and more dependable option. Most DevOps teams choose to work with it.
Database for Configuration Management
Data architecture or a database devoted to Configuration Management works across different systems and applications related to said management. This takes into account all the relevant services, applications, servers, and the like.
A database like this is especially useful for Configuration Control and Audit because managers can view and record how systems function before any changes have been made to their configurations.
What should successful Configuration Management deliver?
If all configurations are being adequately managed, it results in a couple of outcomes. Two of the most prominent ones are infrastructure-as-a-code and configuration-as-a-code.
In basic terms, infrastructure-as-a-code (IaaC) refers to the existence of code that automatically prepares the necessary environment so that it is ready for development and testing activities. Needless to say, this is far more efficient than manual preparation.
In this case, the “environment” refers to all the resources required for DevOps operations – servers, networks, everything comprising the IT infrastructure. These details are crafted as a piece of code rather than some formal document. This code pushed to the version control system, becomes the singular mode of defining this environment. It can also be used to update the environment.
Configuration-as-a-code (CaaC), like IaaC, is code that defines the configuration of servers or any computing resources. Again, like IaaC, this code is pushed to a version control system as part of the software deployment pipeline. This automatically sets up the configuration of the relevant infrastructure so that it is ready to develop and test the software in question.
To define configuration, get the parameters to establish the settings that will allow the software to run as expected.
Benefits of Configuration Management
- Reduces risk of unpredictable system failures and data breaches because it offers perfect visibility and tracks every change made to test environments.
- By offering detailed knowledge of all configurational elements, it reduces costs by lowering the possibility of duplicating technological assets.
- Offers greater agility and better resolution of issues by making it easy for personnel to view changes (unforeseen or otherwise) that may have led to said problems.
- Implement faster restoration of services. This is because the configuration, including all changes, is automated and documented. Not only is it easier to detect the problem, but it is easier to revert the failing environment to its last functional stage.
- Offers greater control over relevant workflows by establishing and enforcing formalized policies and procedures for status monitoring, asset detection, audition, change implementation, etc.
As mentioned in almost every article here, all software tests must, without exception, be performed in real user conditions. Tests must have access to an in-house device lab or a real device cloud that allows them to execute manual testing and automation testing on the latest and legacy devices installed with various real browsers and operating systems.
However, no tests can be conducted in flawed test environments. Configuration Management ascertains if test environments are ready for test executions. Since the software is released in increasingly short timelines, tests have to be more frequently, which means test environments have to be in pristine condition at any point in time. Automated configuration is the only possible option to enable this.