How My Team Is Leveraging Configuration as Code to Deploy Faster

Today, I’d like to give you a personal story and talk about topics I spoke about in the past, and how I and the team I’m on are applying them. To begin, let me give you some backstory. I used to work on a small team of four, called the DevOps team. Basically, we’re in charge of automating test deployments and deployments to production.

We have recently started changing the way we do deployments. Previously, when doing deployments, we used a custom-built tool that we call environment orchestration, which is a bunch of PowerShell modules. No other tools were used, just PowerShell. That was everything from automating the VM creation, operation system tweaks, SQL Server, IIS server, installs, configuration, and all the infrastructure stuff. Plus, creating actual application deployments. We would take a build output from TFS and deploy it to whatever environment that the developer needed. All of this is done in PowerShell.

I talked a lot about infrastructure as code or configuration as code in the past. For a brief intro, configuration as the code is essentially taking some sort of plain text file with either JSON, XML, YAML, etc., and using that as the input for code execution. For a deployment example, consider you need to deploy a test environment of three VMs, two IIS servers, one SQL server, x number of databases; all the configurations items needed to take the environment from absolutely nothing all the way to a configured state. This is what would be located in the document.

Some tools call this document a manifest, some call it a module, some call it a playbook. This document is domain-specific language that outlines the state of what you want the deployment target to look like. We didn’t have this before.

We’ve already seen a lot of great advantages since starting just a few months ago. The first, we can easily tell what an app consists of, all the way down to the virtual machine that’s going to be created. This has some inherent benefits, not only can we see everything, we can easily change things. This has a few different advantages, such as eliminating the need for creating an entirely new version of our environment orchestration product to be able to give the value to the developers right away.

When that build kicks off, these developers they currently have will be able to go to their self-service portal and tell it what to do. For example, install EO packaged Food. The engine then looks for a manifest with that particular name from that build dropped location, reads it, then executes everything in there. This eliminates us completely.

It’s been a struggle getting this kind of mindset communicating this new kind of way of doing things. It’s also been a struggle extracting all that stuff out of a bunch of code from many various places.

Another benefit is idempotency. We build them idempotent, where you can run them as many times as you want previously; if you want to create a VM, create it, if it fails somewhere, completely remove it and create it again.

This post was brought to you by yet another #CarTalks YouTube video. Be sure to check out all of the other #CarTalks videos and other video content on the Adam the Automator YouTube channel!