As teams work on bigger and more complex projects, it is not just code that can be versioned. Implementing configuration as code can help your team accelerate because you are managing all your digital assets together. You can continuously deliver higher quality products, fast.
What Is Configuration as Code?
Configuration as code is the practice of managing configuration files in a repository. Config files establish the parameters and settings for applications, server processing, operating systems. By managing your config files alongside your code, you get all the benefits of version control for your entire product.
Config files provide information that allows your application or product to work differently depending on the platform, hardware, and more. It helps the actual code work smarter and perform better in a variety of environments. This practice of versioning and storing config files just like code can help streamline your release pipeline.
Configuration as Code vs. Infrastructure as Code
Configuration as code (referred to as CasC or CAC) and Infrastructure as Code (IaC) are often referred to as the same thing. But IaC is about managing your IT infrastructure. This includes servers, networking, load balancing, and security.
Configuration as code is about how your software components interact with each other. If you change a setting on your application or product, it can be built and tested earlier in the pipeline and released with a higher confidence.
Back to top
Why Teams Use Configuration as Code
Implementing configuration as code has several benefits for teams.
Scalability
Just like with IaC, managing your configuration changes as code allows teams to add, edit, and maintain config files from one centralized location, using a consistent deployment strategy. For example, if you are building USB devices, you need config files for each of your storage options.
Combining these files with the necessary software means you potentially have thousands of variations. Managing these variations requires a consistent, centralized, and stable source control that can be accessed from several steps in your CI/CD pipeline.
Standardization
When configuration is written like source code, you can implement all of your development best practices — linting, security scanning, etc. Having config files reviewed and tested before they are committed ensures that changes follow your team’s standards. If you have a complex microservices architecture, this can keep your configurations stable and consistent. Having a predefined processes in place helps services work better together.
Traceability
Version control is a critical element for setting up configuration as code. You need a powerful system that can easily store and track changes for your code and config files. This can elevate your release quality. If a bug does slip in, you have the ability to trace the source of the problem. You can diff the versioned config files to see what went wrong and fix it quickly.
Increased Productivity
When configurations become managed code, you simplify your build pipeline. It increases productivity for both IT and end users. Your admins can pull everything into a release or build from a single version control system. Developers know that their changes are accurate, because everything is tested together at various parts of your pipeline.
Back to top
When to Use Configuration as Code
Configuration as code is used to manage package and component settings. This works across a variety of industries. App development may use configurations to support different operating platforms. For embedded development, managing configuration as code means you can track hundreds, potentially thousands of hardware schematics and testing data.
In our previous example we talked about having multiple USB devices. But what about semiconductor chips. These are used in USB devices, and for most of our technology. A chip that works in a camera would have a different file than one for a computer. To manage all of these packages and components, it is easier (and better) to store them together.
Back to top
How Teams Implement Configuration as Code
When you set up or refactor your config files into code, you need to figure out how to store it in your version control system. Teams do this in a variety of ways:
- Store code and config files into the same repo (monorepo).
- Store code and config files in together based on your microservices/component based development).
- Store code and configs in separate repos.
Monorepo Strategy
Having all your files in one repo can simplify your pipeline. But if you are treating config files like source code, it could mean that every change to a setting would trigger a new build. This may not be necessary and could actually slow your team down.
Not all config changes need a build. Your admins would need to set up your system to allow changes to config files to be merged. Then they could be deployed to one of your pre-prod environments for future testing.
When you go to audit, because of everything is code, it can difficult to tell what a config files and what is source code. It is important to establish a naming convention that is consistent across teams.
Microservices/Component Based Development
There are a lot of reasons teams split up their code into a number of repos. In this model, config files are stored and versioned along with the specific microservice or component.
Although you could potentially have a similar issue with triggering builds, it can be easier to manage. If you plan to version config files with their microservice or component, work with your DevOps teams. You should have a plan on how config changes are propagated.
Separate Repos for Configuration Files
No matter how you store your source code, some teams choose to have their configuration code in a repo all by itself. Although this can seem like a good idea, it is not practical for most applications.
Even the most complex projects might have just a few thousand config files. So, they would be taking up just a small portion of an entire repo. Your admins would need to spend time setting up your build pipeline. Although this model can be helpful for audits, rollbacks, and reviews, you may want to consider other options.
Automate Your Development Process
What would it mean for your team if you could ship 20% faster? Learn how Perforce Streams –– the flexible branching model in Helix Core — lets you remove bottlenecks and automate development.
Back to top
What Your Version Control Needs for Configuration as Code
Configuration as code needs a strong version control foundation. Not all version control systems are the same. You want to give teams fast, automated, and repeatable results. So, your tool needs to both provide visibility into your code and be powerful enough to handle all of your files for a build.
With Helix Core — version control from Perforce — you can version everything (code, config files, and more). This creates a single source of truth for your build pipeline. Other version control systems you need to tag code and document a naming convention. This is often maintained outside your system.
But with Helix Core, you get versioning best practices built in. This gives your team unparalleled traceability into changes. You always know who made the change to what and when. For configuration as code, it’s vital.
Simplify Configuration Management with Perforce Streams
No matter your development model, Perforce Streams simplifies your pipeline. This is because Streams manages how code changes (including config files) are branched and merged. For DevOps, it can enhance automation. This is because Streams tracks relationships between versions and files.
For example, if you have a fix or new configuration, it is probably applicable to multiple products. In our USB example, this configuration could apply many models of a USB flash drive regardless of its internal storage capacity. Propagating this change across each product would be difficult, time consuming, and error prone. You may have to do this manually across repos. But not when using Streams.
How Streams Works for Configuration as Code
Because Streams tracks the relationship between files, you always know where changes need to go. Teams do not need to go in and manually apply the change. They can simply add the config file and it will show all the applicable components. Streams organizes all this information, making merges seamless. When managing multiple variants, Streams makes sure that you do not have a costly mistake.
With Streams, your team can version, diff, and manage Stream specs (config files). This allows your development teams to self-service. And if you want more control, you can restrict access down to the individual folder or file level.
Now your teams can easily make changes to all their code, including configuration as code changes.
Try Helix Core free for up to five users.