Source controlling your Infrastructure as code (IaC)

Introduction

One would argue that among the core advantages of going cloud today, Infrastructure as Code (IaC) is at the top of the list. In order to realize it's full potential, your IaC needs to be part of your DevOps pipeline. You may have encountered this concept before and be wondering what it is exactly or for those more acquainted with the cloud or modern Information Technology trends, you may be looking at taking full advantage of IaC and wanting to explore better practices around IaC Source controlling and versioning. Regardless of which of the above categories you may fall under, I think this article will prove beneficial. 

Concepts Explained

1. Infrastructure as Code (IaC)

Let's go back to the past (Well, the present for some). 

John is working on a new software project, so he asks the infrastructure team from his company to provision a Test environment where he can test the new piece of software on. 

He puts together a ton of documentation describing the infrastructure needed for the environment and goes through all the necessary challenges to get all the approvals. The environment eventually gets provisioned and he deploys his project for testing and Quality Assurance. John discovers during the testing phase that the environment hasn't been provisioned correctly for his project needs and keeps having to go back and forth trying to correct this with the infrastructure teams.

After everyone is finally happy and ready to go to production, John goes through the same struggle only this time worse because he needs to get more approvals since it's for a production environment. The project finally goes live only to find out after that it doesn't work in production as in the test environment. Only to find out after a long troubleshooting exercise this is because the infrastructure for the two environments is not configured the same way. 

If only there was a way to easily build and modify infrastructure which can be easily replicated. This is what Infrastructure as Code does. A simple way to build out Infrastructure using computer code which can be recreated in another instance using the same code.

Here is a blog for further reasons  on why you should embrace IaC: Infrastructure as Code: A Reason to Smile

2. Source Code Control

Software developers spend most of their time writing source code. In order store their hard work safely in an access controlled environment, they utilize source code control systems (SCCS) such as Git, Team Foundation Server, Bit Bucket etc. This is commonly referred to as Source Control.

Source control systems also enables source code versioning and collaboration

We won't explore source control in depth in this article, for a deeper understanding of source control you can read: What Is Source Control?

Source controlling your Infrastructure as code

As explained above, IaC is about writing code to build your infrastructure. In order to manage this code, one would need to make use of Source Control.

Why it is so Important

Although IaC is considered the best way to provision infrastructure, without source control your IaC scripts are almost as good as a traditional infrastructure specification document.

For IaC to provide it's full benefit, it needs to be used as a DevOps practice with properly defined Source control. The core advantages of using IaC are based on having the ability to re-produce identical infrastructure perfectly over and over and being able track any changes through IaC versioning. Your IaC must be testable and deployed automatically.

To achieve this, you need a Continuous Delivery pipeline which includes Source Control.

Conclusion

IaC has revolutionized the way we roll out infrastructure and added among many things, reliability, consistency, roll-out speed, ability to test infrastructure before provisioning and many more advantages. Any organization should make IaC source control part of their cloud strategy.

Why would you do this if a task consists of no more than a few simple manual steps that everybody knows? Even if everybody on your team knows these steps now, there’s no guarantee that someone who needs to recreate your build-and-release process later will know about them. In fact, anyone who has spent much time working in development, QA, or operations can tell a few stories about those crucial “everybody knows” steps that were missing from a set of instructions.

So you script everything, including the simple, obvious steps. You’ll know that you’ve scripted everything when you can precisely and reliably recreate the build, the deployment, and the state of the infrastructure immediately after deployment strictly by running scripts (or better yet, one master script).

Once everything is scripted, you need to store the scripts in a standard version-control repository.  The repository that you use is up to you (or your organization), but it should all of the features needed for full version control, because you are going to treat every script, no matter how seemingly trivial its function, as if it were an important piece of source code. The goal is to be able to pull all of the infrastructure code in the same way that you would pull the application source code.

At some point in the not-at-all-distant future, questions like “Should I version my infrastructure?” will no longer even make sense, because versioning will be built into the tools that you use to manage infrastructure, and it will be hard to imagine how anyone ever got along without infrastructure version control.  Until then, however, we will all need to take those few extra steps required to place DevOps infrastructure under version control.