That means that all the scripts, configuration files and templates that you are used to write to describe, deploy and configure your infrastructure can also be stored in a source control repository, be versioned and have the exact same lifecycle than applications that are being deployed on this infrastructure. If it’s relatively common for development teams to centralize the source code of an application into a source code repository (like GitHub or Azure Repos, for example) to be able to share it, to merge / resolve conflicts between developers working on the same items, to version it and eventualy to revert to any version at any time, it may not be the case for all infrastructure / IT teams.īut it is totally possible today to apply the exact same patterns and practices to your infrastructure, just by treating it as code. In this blog post series I will detail some best practices about using Terraform and setting up continuous deployment and testing for Microsoft Azure infrastructure.īefore going deep dive into the technical details, I’d like to come back briefly on the concept of Infrastructure as Code, which is really important. Cloud platforms like Microsoft Azure enable a high level of automation of these deployments and there are several options and tools available to you to make sure that you are able to deploy the different components of your infrastructure in an automated, repeatable and idempotent way. Recently, I have been involved in several projects to help customers to improve the way they are dealing with their infrastructure deployments. Terraform on Microsoft Azure - Part 1: Introduction in DevOps

Azure terraform examples