Configuration As Code and How to Use It Successfully

When it comes to developing and deploying software, there is usually a separation of concerns between an application’s codebase and its server deployment configuration. Typically, it’s left up to the Ops team to devise the tools and configuration settings to build and deploy your app across server instances and environments. Configuration as code advocates for treating your configuration settings the same as your application code. This means taking advantage of version control for your configuration settings.

Why is this useful and why might teams want to do so? This article will cover the reasons behind configuration as code, as well as cover some of the biggest advantages and disadvantages of the approach.

What is Configuration as Code? 

Configuration as code is a method of managing your software that advocates for configuration settings (such as environmental settings, resources provisioning, etc.) to be defined in code. This means treating your software configuration settings as you would the rest of your code, committing it to a version control repository. This is in contrast to having your configuration contained somewhere outside of the repository or perhaps requiring configuration to be created and customized for each deployment.

Benefits of Configuration as Code 

Configuration as code advocates for your application’s configuration settings to be stored as code and maintained in version control, exactly like the rest of your codebase. This consistency brings all of the benefits that version control has: its history can be tracked, changes can be managed and rolled back, and a copy of the config settings is always available in the repository.

This also makes it much easier to synchronize configuration changes across several deployments or instances. Instead of having to manually configure server changes or use some other, out-of-code solution, you can push server change updates to the repository like any other commit, which can then be picked up and pushed to the server like any other update.

Practical use of Configuration as Code 

As a practical example of using configuration as code, we’ll take a look at the Jenkins Configuration as Code (JCasC) plugin for Jenkins, a popular open source automation platform. Using this plugin allows you to generate a simple YAML file that allows you to define virtually everything from security protocols to access management and user credentials, as well as build instructions. This YAML file can be run on both classic Jenkin instances and Dockerized Jenkins instances, allowing for a flexible and portable deployment solution.

There are several examples of codeless tools and services that offer configuration as code. These generally generate configuration files based on specified settings and can work as a good base for further modification and customization by teams. Very often these services also offer smooth integration with automated CI/CD development and deployment pipelines, making server configuration part of the same process.

Guideline for Implementing 

There is an important distinction between implementing configuration as code and storing your config settings in your repository. Obviously, storing sensitive configuration settings, such as passwords and cryptographic salts, in a shared repository represents a security risk and should not be done. Rather, configuration as code means storing information like database drivers, cache settings, and build instructions inside a folder or file that is stored in your repository.

Storing specific configuration information inside your config file (or files) means that making configuration changes requires pushing and deploying your codebase to production, which can potentially mean having to run your entire testing and deployment process. Depending on your project and pipeline, this could take hours. This is obviously undesirable, particularly for large enterprise projects. The config file (or files) should serve instead as a template with an initial push and then a .gitignore (or your preferred SVN’s equivalent) so that the specific configuration details for each specific deployment can be made per deployment, using a configuration defined in code and used by the codebase.

Rules for Configuration as Code 

Generally speaking, you want to avoid explicitly keeping your configuration code in a config file or folder inside your repository, as this can conflate your application code with your configuration code and tie them together. Keeping your configuration in a separate repository and synchronizing when necessary allows you to manage different configuration instances and mix and match as needed.

However, Guide-Rails_® has the ability to store configuration templates in source control with the code, so what your deploy mechanism is pinned to your code version. Each deployment can have different properties that do not necessarily have to live with the code, but can. This removes the need of creating and managing separate repositories for configurations and simplifies the overall use of configuration as code.

Some teams choose to use configuration as code as a disaster recovery tool, rather than a regular part of their workflow. It creates a recovery process that can quickly get a defined environment up and running again after a disaster. The problem with this is similar to issues with other backup processes – if it’s not regularly tested and maintained, it can quickly become outdated. Application configuration settings can change frequently, especially across different deployments, so it’s important to keep your configuration up-to-date if you choose to use configuration as code in this way.

This is another benefit of utilizing Guide-Rails_®, as when configuration settings change the templates render them automatically. In addition, previous version deployments are easily accessible in a drop down, so when a failure in production occurs it’s a simple process to perform a complete rollback and restore service.

Potential Challenges When Using Configuration as Code 

While configuration as code does undeniably offer some practical advantages for maintainability and deployment, like everything else, it also has its downsides. There are some challenges to working with configuration as code that you should be aware of.

Treating configuration as code can result in adding additional unintended complexity to a project. Programmers may recognize a familiar problem that goes by many other names, such as a monolithic model. That is, your configuration file is at risk of becoming a monolithic entity that both developers and Ops throw the kitchen sink at.

Configuration as code can result in configuration files that are too complex and unwieldy to manage, which can result in making changes to your configuration needlessly complicated. Proper separation of concerns and programming best practices should be applied to your configuration code just as it is to your application code.

Another potential challenge of configuration as code is the mixing of team concerns. Generally speaking, developers take care of application code and logic, while Ops takes care of server configuration and management. By treating configuration as code, you are blending concerns and potentially introducing additional complexity to both teams used to having separated concerns. This needs to be managed carefully and members of both teams must understand how configuration as code works and how introducing particular changes will affect their individual responsibilities.

Make the Move to Start Using Configuration as a Code Now 

Configuration as code is a valuable mechanism for managing your applications across instances. It allows you to define your environment in a way that can be traced, collaborated on and customized as needed. It also works nicely as part of an automated CI/CD or deployment process.

There are some pitfalls that inexperienced teams can run into and the overall complexity can make the use of configuration as code difficult. Because of this, it can be advantageous to make use of a Value Stream Delivery Platform (VSDP) such as Guide Rails.

A VDSP is essentially a system for your CI/CD pipeline, automated policy enforcement, test and build automation pipelines, and code as configuration settings into one single management platform. As a uniform, integrated service, it reduces the additional complexity introduced by moving to configuration as code. Teams can work from the same unified platform and it introduces a standardized workflow that all staff can follow, whether they are a developer or Ops.

Final Thoughts 

If your team is looking to introduce configuration as code to your project, or you are interested in the benefits that using configuration as code as part of a VSDP can offer, then get in touch with the team at Guide-Rails_®.

Learn more about the Guide-Rails_® software.