When you are developing a software project, your development environment will be constantly changing. By the time you come to deploy the finished product, you should have figured out the necessary hosting requirements, which systems you need to provision, and all the relevant configuration settings. In reality, the development environment was in a constant state of flux, nothing was documented, and no dependencies were tracked. If you are lucky, you will have everything back on track by the scheduled release date, but there’s bound to be at least one major inconsistency or missing dependency that causes service outages and diminished your customers trust in your product.
You can solve this recurring nightmare with Software Configuration Management (SCM). Traditionally configuration management is the responsibility of corporate IT, who assign the task to software configuration managers. Due to increased automation, the traditional roles and responsibilities of development and operations have merged into DevOps. As a result, an automated approach to SCM has emerged. This article introduces you to this new approach, gives you the relevant background, and gives you an easy to follow, step-by-step guide to getting started. The article also introduces the relevant tools, presents their relative strengths and weaknesses, and tells you how to choose the one that meets your needs.
Step 1: Do your homework
Like many forms of automation, code-based SCM often overpromises but underdelivers. To ensure that your SCM effort succeeds, you need to define what you want to improve, define the intended outcomes, and start mapping out how you achieve your intended outcomes.
Once have this in place, you can figure out your next steps.
For a start, do you need an automated SCM solution to manage systems across your organization? For example, do you need a way to provide a standard set of settings for backend servers, track changes, and synchronize them across your corporate network? Alternatively, do you need a system that manages specific types of activities, such as being able to spin up virtual development, testing, and deployment environments? Both of these areas can benefit from automated SCM, but require different solutions and operating environments.
Before you start implementing your intended solution, you should research modern SCM and understand it in depth. Your research should involve understanding both the differences and similarities between Configuration as Code (CAC) and Infrastructure as Code (IAC), when to use them, and what each approach involves.
The CAC approach deals with managing and deploying the configuration settings of existing systems. A common use for the CAC approach is to handle the migration of configuration settings between new and old systems. IAC takes advantage of newer technologies, such as cloud computing, virtualization, and containers to provision and manage infrastructure. It is often used to provision infrastructure on-demand in organizations that want a self-service approach to providing infrastructure.
Step 2: Understanding the operating environment
Successfully implementing code-based SCM, requires that you understand your organization’s operating environment. Specifically, you must understand the systems that your solution needs to configure. If the intended purpose of SCM automation is to support your Continuous Integration/Deployment/Delivery (CI/CD) pipeline, you must ensure that your SCM tool integrates with them.
A solution designed for provisioning virtual machines or deploying containers will have a different operating environment. Your operating environment also includes the people who operate and use the system. A system designed for support and operations staff, will be different from one designed to meet the needs of developers and testers. In addition, the system’s users and support staff require a broad range of skills, practices, and systems, as well as the ability to write and debug source code.
Step 3: Pick the Tool That’s Right for You
After you have identified the problem, chosen an approach, and understand your operating environment, you can pick the appropriate tool. In order to help you decide, we have chosen four tools that address specific SCM solutions.
Safe and Secure
If you work in a large organization, your employer will take a cautious and conservative approach to configuration management. You will need to show that the tool you are considering has a proven track record, is scalable, widely supported, centralized, and highly secure. In addition, if they have given you the task of selecting an SCM tool, this must mean that you properly work in IT operations and support as a system administrator. In this role, you perform a wide range of configuration tasks and need a tool that organizes configurations based on a system’s assigned role, such as monitoring, web server, etc. The tool that best meets your enterprise SCM needs is Puppet.
If Puppet’s role-based model isn’t enough to convince management, you can inform them that Puppet has been around longer than other CM platforms. Puppet also, has a large and mature-user base, the widest range of available extensions, and high-quality documentation. You can also tell them that Puppet has a reputation for security, especially when compared to some of its newer rivals.
If Puppet is the tool of choice for large organizations, Chef has become the tool of choice for smaller companies and startups, that often lack the dedicated support and operations staffs of established companies. Chef emerged shortly after Puppet, and both offer very similar feature sets and abilities. According to Chef’s advocates, Chef’s procedural model provides more flexibility over its rival’s more rigid role-based approach. While both platforms provide their own Ruby-based Domain Specific Language (DSL). Puppet’s DSL is more declarative. Chef’s DSL is more programmatic and lets users build configuration workflows and save them as recipes. Chef’s programmatic approach may be one of the reasons why Chef is favored by developers. In addition to recipes, Chef also integrates with the major cloud platforms, such as Amazon Web Services (AWS), and Google Cloud Services, and works well with most CI/CD pipelines.
The Fast and the Furious
Agility and simplicity are great, but what if you have a need for speed? Most SCM systems use a pull model, where a local agent periodically polls a central server and requests the most recent set of configuration changes. In theory, the best way to overcome the slowness of a pull model, is to replace it with a push model. A push model could send configuration changes to the relevant systems without having to wait for a request from a client machine. So far, the only SCM that uses a push instead of a pull model is SaltStack. As a result, Salt is a highly scalable system that is highly resilient, and highly performant. Salt is also designed to remotely execute tasks on managed nodes. This gives Salt a measure of control over client systems that other systems can’t match.
Agility and Simplicity
Many of the original SCM tools are large, complex, and have a steep learning curve. If you work at a small company, you will be looking for a system that is easy to install, has a small footprint, doesn’t require huge system resources, and does not need much care and feeding. Finding a tools that meets these requirements, would make it preferable to a more mature system with more features. This is why you should take a look at Ansible. Ansible claims that its less complicated system architecture and smaller footprint makes it easier to install, configure, and manage.
Conclusion: Step by Step to Successful SCM
Configuration management deals with the problem of managing system configuration across multiple environments. Often times, the most common approach to configuration management is probably to ignore it completely and put out local fires as and when they emerge.
As we have seen, a more systematic approach has emerged for handling this problem. Based on the existing engineering principles, Software Configuration Management tried to provide a complete solution to the problems of tracking and synchronizing different software environments and their configuration. Over the last decade, the emergence of the DevOps movements has led to a code-based approach to configuration management.
In this article, we recommend taking a step-by-step approach to choosing your SCM solution. The first step is to understand the actual problem you are trying to solve. Once you have identified the problem, you can move on to the second step of selecting a CAC or IAC SCM approach.
The third step is to understand your operating environment. This is important because your SCM tool will need to support your existing toolchains and systems. After you have everything in place, you can pick the right tool for the job. In our selection, we picked four tools that should meet your needs, but still might not be right for you. Either way, if you follow steps 1 to 3, you should have no trouble finding your ideal SCM solution.