Keeping Confidence in Your Shared Infrastructure ARM Templates

We've been having fun the last couple of weeks working on a cloud enablement project with a great client. We have been working closely with their infrastructure team in the "war room" defining and building out the foundational components for Azure. This first phase will set the stage for other teams to build secure applications using DevOps practices. The team is doing a great job picking up infrastructure as code. It is much more than just building ARM templates. They have been practicing the whole process of using Git version control with branching and Pull Requests to deploying the networking infrastructure using a software delivery pipeline.

We break out the Azure infrastructure into two primary categories. Application Centric infrastructure is infrastructure that supports a single application and should be used as much as possible to prevent dependencies that can slow down your deployments. Not all infrastructure can and should be application centric. Shared Infrastructure is the other category that usually includes all of your networking and hybrid connectivity that is used by all of your applications.

One concern about infrastructure as code can be trusting that the code repository matches the environments. Changes can be made outside of source control and deploying the infrastructure code becomes more risky as the more time passes since it has been run. Once the networking infrastructure has stabilized, there typically isn't lot of changes. How can we ensure that the template matches the environment and there won't be any surprises when the template is deployed. One technique for keeping the infrastructure code from getting stale is to deploy the code regularly even if there are not any changes. In fact, some tools encourage you to have the code run against the environment every 15 or 30 minutes to ensure there environment is in sync and not encountering any configuration "drift". Drift is what happens when changes are made directly to the environment and the source code differences begin to grow.

Azure provides several tools for doing this. You can use Azure Automation but I prefer to use Visual Studio Team Services (VSTS), the same tool as our networking infrastructure deployments when there are changes. Often we create two releases, one for the continuous delivery of the network infrastructure changes and one that runs nightly to ensure nothing has changed since the last deployment.

We typically schedule this to run nightly and usually only deploy to the development environment. By using the same tool for all deployments, it helps build confidence in the entire process and can include any number of additional quality validations. Schedule your VSTS release to run each night so you can deploy your infrastructure changes with confidence.