Easy Dynamics Blog

Continuous Integration: Infrastructure as Code in DevOps

Posted by Martin Ramos on Nov 4, 2015 2:00:00 PM

Find me on:

As technology continues to advance and more companies start to see the need to stay up-to-date on the “newest and latest,” the more I have become invested in researching ways technology is starting to impact roles in the workforce. As I dug deeper on Continuous Integration to elaborate further on my previously explored “DevOps” path, I stumbled upon this great concept referred to as “Infrastructure as Code” or “Programmable Infrastructure” and it really peaked my interest. This blog post will cover a high level description of Infrastructure as Code and how developers can start taking advantage of it while incorporating it into their everyday tasks. 

Even at first glance, it's apparent how expansive the Information Technology industry world is and how key it is for teams to continuously seek and adapt to new innovations and solutions. Developers using Agile methodology are sometimes forced to work in silos for their individual tasks, checking in code periodically into a shared repository, and then moving on to the next task. Infrastructure as Code will force developers to get a better sense of the bigger picture by adding on a layer of code (scripts) laying out the infrastructure of where this task will take place. We can think of this as the blueprint of the developer’s work.

Practicing Infrastructure as Code is taking it one step closer to Continuous Integration as the team starts automating the way they stand up environments and having automated configurations, making it easier to reach the ultimate goal that is DevOps.

Continuous Integration

“Continuous Integration” has become a popular buzzword in the IT field, requiring multiple components to be present in order for this methodology to live up to its meaning. Continuous integration forces teams to work at a faster pace, which results in increased configurations, server management tools, documentation, and overall, faster changes to the infrastructure. Even though the system’s admin is used to making all these changes on a daily basis, the amount of work multiplies if the team is moving towards DevOps and Continuous Deployment.

Infrastructure as Code allows developers to write code (scripts) at a high level in order to help manage configurations and automate building the infrastructure - all the while avoiding errors and lessening down-time. Infrastructure as Code will also configure servers and its associated components versions while tracking the order of which they were installed. This is very useful because developers only have to do it once and they can run the code and configure all of the environments and virtual machines from the same scripts. Developers will not have to dig through logs because the process can be retold by looking at the scripts. This, in turn, serves as documentation for the team, resulting in minimization of the team workload and will enable additional time to be used in other more critical areas.

Looking at the Tools and Architecture

Usage of a vast variety of tools - such as Vagrant, Ansible, Puppet, Docker - either independently or collectively, can aid developers in easily adopting the new procedure, because they are able to use Infrastructure as Code in languages they are accustomed to. In current times, server hosting sites like AWS are supporting this new DevOps movement by providing APIs that can be influenced and friendly to use. AWS gives developers the option to create templates of the infrastructure and applications they wish to host and the CloudFormation service automatically provisions the required AWS resources and relationships from the templates in stacks. It also keeps track of version control and integrates easily with the other tools mentioned above. 

Easy Dynamics Uses AWS's basic workflow for CloudFormation template

Looking at the Whole Picture

The required level of detail for the making of these scripts is consistently very high due to the amount of checks that you need the code to perform. For example, when standing up an instance of SharePoint, Infrastructure as Code can be used to install mysql-server on the server, and then ensure the following, that it

  • Is running
  • Creates a username with password
  • Deletes test databases
  • Creates sample databases, and
  • Copies it and restores it.

It can then be used to install the SharePoint Server instance, configure the SharePoint farm settings, database settings, security settings, and configure the SharePoint Central Admin web application settings. Finally, it provides the capability to write scripts in order to verify the installation. All of these actions are carried out when a master script is run - it will track the number of times it's run and if certain tasks have already been executed, then they will not be executed again.

If done successfully, developers can easily stand up and tear down environments with just the click of a button, which is where the real “value-added” goal comes into play. Dev teams can have a repository of these master scripts in file for anyone to use, giving them control and assurance that all of the environments have the same configurations. 

Looking at the Code

Here is a script sample CloudFormation template for creating a virtual network with servers:

Easy Dynamics showcases sample script to stand up a virtual network with servers

The scripts themselves also serve as a means of version control, allowing developers to follow along and know exactly what configurations have been done by just looking at the code and have the option to “roll-back” to a previous working environment. These configuration scripts become very valuable to teams because they can be run on the cloud, as well as virtual and local machines. 

It should be considered “best practices” to have the lead developer be well-informed and trained when trying to implement Infrastructure as Code as there is a high volume of planning involved ahead of time when transitioning to this new method. Plus, having bad configurations replicated on all of the servers is never a good idea.  

This new methodology incentivizes DevOps as it forces the developers to think like a Systems Admin imposing a more collaborative work environment for the team.


To learn more about “Continuous” practices and the big “DevOps” practices and how it all fits, read our Agile and Agile Methodology blog posts. Learn more about how we use Agile in our current work and while you're here, make yourself comfortable and check out our blog home page to explore other technologies we use on a daily basis and the fixes we've solved in our day to day work. To make your life even easier, subscribe to our blog to get instant updates sent straight to your inbox:

Subscribe to Blog at Easy Dynamics for Fixes and How-To's

Topics: Agile Methodologies, Agile, DevOps

Easy Dynamics: The SharePoint Experts

We are a leading SharePoint Services and Solutions shop located in Washington, DC. 

Thanks for coming to our blog! Here you will find relevant news and information about the technologies we use and other things we find interesting. Want to know more about who we work with? Or our first commercially available product, EasyBox

You can find links to all of these things and more right from this page. Enjoy reading!

Subscribe to Email Updates