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.
One thing we wanted to change was that everything was tied to a release of our own internal tool, environment orchestration. We versioned this tool like other software applications making us at EO 5.23 right now. What this did was, tying all the new functionality for the app for all these different applications, tweaks, etc., that was hard-coded in the EO project itself. Before we could release any new functionality, we had to actually go into PowerShell to change it. We had to wait for the next release and go through all the testing. Basically, we were developers, developing a tool, when we really didn't have to.
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.
I took it upon myself to introduce a concept we called "vnext". The point of vnext is to take all that logic and code and move it into what we call manifests. These are just JSON files; it's our own kind of custom solution. The biggest takeaway was that we had so much stuff. We had almost 50,000 lines of PowerShell code and dozens of applications that was embedded in the PowerShell code. The first step in breaking all that stuff out was to develop some kind of manifest. We have a specific schema that we follow which is a JSON and it has different nodes in it. Now, all the instructions are in the manifest.
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.
Another advantage is having everything in a manifest to allow you to explain to others what you're doing. Previously, we worked with various development teams and QE, and we had to explain to them everything that we were doing because it was so obscured in all that code. Even if we wanted to, we could give the various teams our PowerShell code, but we wouldn't or shouldn't expect other people to read our code. Now, when they need an explanation, we simply send the manifest to them so they can see the state of their application or their test environment as it's seen today.
Since the manifest is human readable, it's easily understood for even those without developer knowledge. Changes are also easily made by those reading it before sending it back to us. This cuts down all that back and forth.
That was Phase 1 of how we're doing our configuration as code concept. The next phase will involve actually taking these package manifests and putting them directly into the TFS bills themselves. We're not even going to be in the picture whatsoever. Once we have an easily readable manifest that we're able to put inside of each of the application builds themselves, the developer will be able to change whatever themselves, such as adding resources or removing stuff. Any changes they need to make will be inside of the build for the manifest, completely removing us.
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 an 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.
If you're in DevOps, IT professional, doing deployments, the configuration is code concept significantly cuts down a whole lot of things. It's been a big win for our team.
Join the Jar Tippers on Patreon
It takes a lot of time to write detailed blog posts like this one. In a single-income family, this blog is one way I depend on to keep the lights on. I'd be eternally grateful if you could become a Patreon patron today!Become a Patron!