At first blush, infrastructure as code (IaC) and continuous integration / continuous deployment (CI/CD) don’t seem to go together. They represent two completely different processes, don’t they? One is a mechanism for defining how you configure and build your hardware; the other is for building, testing, and deploying your software.
But they go together very well, and you’ll benefit from combining them. Let’s see how.
Your pipeline is the path your code travels from development to production. It contains the automated steps that take code and build it, test it, and finally deploy it. Those steps are the stages of your CI/CD pipeline.
Version control triggers the first stage of integrating your code. Your build automation system polls Git. When a developer commits and pushes a change, the system retrieves the code and starts a build. Hopefully, your build includes automated tests designed to verify that the change didn’t create any regressions while testing the new change. These steps represent the “continuous integration” part of CI/CD.
Once the tests pass, the deployment part of the CI/CD pipeline begins. Your automation system deploys the code to development, testing, or production systems.
Typical examples of a CI/CD system would be Git for version control, Jenkins for automation, and Ansible for automated deployments via playbooks.
Infrastructure as Code
The definition of infrastructure as code (IaC) is right there in the name. It uses code to describe how to provision and configure infrastructure. It’s most often associated with cloud infrastructures like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft’s Azure.
IaC eliminates the tedious and time-consuming process of manually creating and configuring servers. Even though cloud platforms provide tools for saving or snapshotting cloud resources, provisioning new systems by hand is costly and error prone. Tools like Terraform allow you to describe your system in JSON to create it by simply running a script. Ansible serves a similar role with its YAML configurations.
While automating tedious tasks is a significant advantage, it’s not the only reason to use IaC. You can version code. That means you can deploy a change, roll it back, and deploy it again. It also gives you a way to compare two different deployments and figure out what went wrong or right.
Additionally, it means that you can make your infrastructure configuration available to your CI/CD pipeline.
IaC and Your CI/CD Pipeline
What happens when you add IaC tools to your pipeline?
You can provision new resources on demand as part of a deployment. You don’t have to create them before your pipeline runs, and you can destroy them as soon as you complete your testing. That saves you time and money.
A build and deploy pipeline for user acceptance testing (UAT) creates the systems it deploys the new code to. When the testing is complete, you shut it down and remove it until the next iteration. A canary release does the same.
Does the new release candidate require an infrastructure change? Deploy it with the release. Your infrastructure configurations are code. You tag them with the code changes, with the same tag. You release them together, withdraw them together, and try them again.
Your CI/CD pipelines watch your code for changes. They can manage your infrastructure for changes too. You can now integrate, deploy, and test changes to system configurations the way you do with your code.
Level up Your Pipeline Today
You don’t have to limit your CI/CD pipeline to just your application code. IaC tools like Terraform and Ansible describe your infrastructure in a high-level language. You can manage that code in version control and deploy it as part of your pipeline.
How to get the most out of your CI/CD pipeline isn’t always obvious or easy. Cprime has a three-day, instructor-led, hands-on, technical class that shows you how to create a pipeline that builds, tests, and deploys code every time you push a change. Sign up today!