Understanding Configuration Management

Unless you have been living in a bubble, you will probably have seen that Configuration Management automation has taken the IT world by storm. That is to say that hosts can now be automatically configured and provisioned to be in a specific state via code (Packages Installed, Users Created and so on). The idea that infrastructure can be defined and codified is not only novel but is now the norm. Configuration Management in many ways represents to infrastructure what software development represents to end-user software products. If it's unclear at this point what CM actually is, let's quickly define it:

Now that we have a basic idea of the textbook definition of CM, let's look at how the definition fits into modern software organizations.

Rapid delivery systems in software have added a significant amount of pressure to maintaining clean and stateful systems in production. This means that the development and rollout schedules of the past are just that: a thing of the past. No longer can companies and their product development teams rest on their proverbial laurels after the launch of a new version of their product. With the rapid adoption of broadband, mobile devices, SaaS, and internet access, consumers now demand more frequent updates at a faster pace than ever before. With such a strong demand and no sign of it easing, automation is a must for any company wishing to manage distribution channels in order to remain competitive in today's fast-paced digital world.

Configuration Management has in many ways changed the landscape of modern development patterns. It has encouraged teams to work more collaboratively, push incremental changes to a software system or IT infrastructure item, manage change-control processes, and track changes as they move from one logical group in an organization to another. While Configuration Management techniques are continuing to evolve (about as fast as technology stacks change), the core concepts of CM are holding steady. These core traits are illustrated in this diagram:

From this diagram, we can see there are a few core tenets of Software Configuration Management. These are defined as follows:

• Release Management: Release management is the practice of creating automation and processes working in harmony to reliably publish a piece of software for consumption by the target end user.
• CM Environment: CM environments represent a set of physical or virtual replications of a production-release environment. As a best practice they should be automatically provisioned through an Infrastructure as Code (IaC) solution such as Ansible and the infrastructure should be easily replicated using automation.
• Continuous Integration and Deployment: Continuous integration and continuous delivery have taken the DevOps world by storm. They are actually an important set of practices that encourage collaboration and span the entire delivery pipeline. These practices are detailed further in later pages.
• Version Control: Version control is where all source code and development efforts should be stored. This includes any automated Configuration Management scripts, Ansible playbook's, development code, and automated QA tests.
• Work item Tracking: Work item tracking is simply the practice of dividing, tracking, developing, testing and deploying large implementation efforts for a project into smaller, more reasonable chunks that can be worked on individually. Using a work item tracking solution such as JIRA can help small or large teams develop and release solutions more effectively.
• Traceability: As a software system, infrastructure-development effort, or quality-assurance automation becomes more complex, it's important to try as far as possible to shrink each work effort into smaller, more easily accomplished tasks. As a result of breaking work items into smaller, more easily accomplished tasks, it's important that the traceability of each change to a given software system be available throughout the delivery pipeline.
• Baselining: Baselining an infrastructure solution is important because it provides a solid starting point for all future infrastructure implementations. This means that at any given time, you can reimage a system with the known good baseline and build on it from there. In many ways, this also provides a level of consistency.