Configuration as code is a technique of controlling your program that promotes the use of code to describe configuration settings. In this article, we covered what Configuration as Code is.
When it comes to building and deploying software, there is often a separation of concerns between the application’s source and the configuration of its server deployment.
Typically, the Ops team is responsible for developing the tools and configuration settings necessary to create and deploy your application across several server instances and environments.
Configuration as code promotes the idea of treating configuration settings the same way you would approach application code. This entails using version control to manage your setup settings.
Why is this beneficial, and why might teams choose to use it? This article will discuss the rationale behind implementing configuration as code, as well as some of the major benefits and drawbacks of the method.
What Is Configuration as Code?
Configuration as Code is a technique of controlling your program that promotes the use of code to describe configuration settings (such as environmental variables, resource provisioning, and so on).
This requires handling your software configuration settings the same way you would your other code and committing them to a version control repository. This is in contrast to storing your configuration outside of the repository or needing configuration to be built and changed for each deployment.
Utilization of Configuration as Code in Practice
We’ll examine the Jenkins Configuration as Code (JCasC) plugin for Jenkins, a prominent open source automation platform, as a practical demonstration of configuration as code.
This plugin generates a simple YAML file that contains practically everything you need to declare, from security protocols to access management and user credentials, as well as build instructions.
This YAML file can be executed on both traditional Jenkins instances and Dockerized Jenkins instances, enabling a very flexible and portable deployment option.
Numerous instances exist of codeless tools and services that provide setup through code.
These normally produce configuration files depending on supplied parameters and serve as an excellent starting point for future modification and customization by teams.
Frequently, these services also integrate seamlessly with automated continuous integration and delivery (CI/CD) development and deployment pipelines, including server setup into the same process.
Advantages of configuration as Code
Standardisation and Automation
Because the configuration is defined in source code, it may benefit from all best development practices, including the creation of reusable definitions for plans, parameterisation, and the use of loops to generate a large number of distinct entities such as plans, jobs, or repositories.
This is critical for big Bamboo instances that include hundreds of plans. Additionally, it is fairly usual in the microservices environment to have comparable development strategies.
Change Versioning
You can keep track of who modified what and when in your Bamboo setup by storing configuration code in a version control system such as Git.
Tags let you to categorize versions that have been published to Bamboo. You may utilize branches to separate development changes and operate in parallel streams without impacting your production Bamboo instance.
Changes Are Traceable
If your source code is versioned and handled correctly (e.g., using tags), you may determine which modifications have been made to your Bamboo server.
Analyzing code differences (using git diff, for example) is often easier and more efficient than reviewing Bamboo audit logs.
Changes From Test to Production Are Promoted Smoothly
If you’re utilizing two Bamboo servers – one for production and one for testing – it’s far simpler to push changes using configuration as code.
In the “UI world,” you were required to click through several UI pages, verify that everything worked well, and then repeat the process on the production instance.
With CaC, you can easily deploy plans to a test instance, review changes, and then replicate the plan to the production instance by just changing the destination URL.
Maintaining a Build Environment That Is Compatible With a Product
It is extremely usual for build configurations to be stored in the same source code repository as the product being created.
As your product changes, the ecosystem in which it is built evolves as well.
Due to this synchronization, you can always construct an appropriate environment, regardless of whether you’re building the most recent commit from the master branch or a bug fix branch produced many years ago.
Assistance With Coding and Validation
Editing build plans in an integrated development environment (IDE) such as Eclipse or IntelliJ IDEA enables you to take use of IDE capabilities such as code autocompletion, parameter tool tips, pop-ups with JavaDoc, code refactoring, and searching for instances of a specific method/object.
Additionally, you may easily validate the code offline by building and executing it.
Possibilities for Difficulties When Using Configuration as Code
While configuration as code undoubtedly offers certain practical benefits in terms of maintainability and deployment, it, like anything else, has drawbacks.
There are several considerations to make while dealing with configuration as code.
Treating settings like code might result in unnecessary complexity being added to a project.
Programmers may be acquainted with an issue known by a variety of different names, such as a monolithic model.
That is, your configuration file runs the danger of becoming a monolithic entity that developers and operations alike attack with all they have.
Configuration as code might result in configuration files that are too complex and burdensome to maintain, complicating configuration updates unnecessarily.
Separation of concerns and best practices for programming should be applied to your configuration code in the same way that they are to your application code.
Another possible issue with CaC is the intermingling of team interests. In general, developers are responsible for application code and logic, while operations is responsible for server setup and administration.
By treating configuration as code, you are combining concerns and perhaps adding complexity for both teams that are used to having distinct concerns.
This must be done with care, and members of both teams must understand how CaC works and how specific changes will effect their own roles.
Configuration as Code vs Infrastructure as Code
The words Configuration as Code (CaC) and Infrastructure as Code are sometimes used interchangeably (IaC). Many believe CaC and IaC are synonymous, which is incorrect.
The key distinction between infrastructure as code and configuration as code is that with infrastructure as code, you are needed to manage and provide the infrastructure using code, but with CaC, no human procedure is utilized to configure the systems or devices.
You employ management technologies such as Chef, Puppet, AWS CloudFormation, and Terraform to implement infrastructure as code.
In the case of configuration as code, you are responsible for managing the application’s configuration data or settings, not its infrastructure.
This is incorrect to say that IaC and CaC are diametrically opposed. Both are often utilized in production environments since they complement one another.
CaC is related to but not identical to Infrastructure as Code. Rather of specifying the infrastructure, you will describe the configuration of your application in CaC.
Your application’s settings are saved in the source code. Thus, everything is now versioned in unison. Now, when you construct the CICD pipeline to deploy your application to production, you have both the infrastructure and the configuration necessary to configure it.
Conclusion
That concludes our discussion of CaC. Instead of defining the infrastructure itself, CaC describes how the infrastructure should be configured to operate your application.
Thus, we are neither provisioning infrastructure nor deploying resources. It’s rather a matter of setting it in the manner in which we want it to execute the application.
You may also be interested in:
