{"id":12202,"date":"2023-09-22T13:48:18","date_gmt":"2023-09-22T20:48:18","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=12202"},"modified":"2026-04-09T07:57:27","modified_gmt":"2026-04-09T14:57:27","slug":"how-were-deploying-our-vwan-infrastructure-using-infrastructure-as-code-and-ci-cd","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/how-were-deploying-our-vwan-infrastructure-using-infrastructure-as-code-and-ci-cd\/","title":{"rendered":"How we\u2019re deploying our VWAN infrastructure using infrastructure as code and CI\/CD"},"content":{"rendered":"

\"MicrosoftEditor\u2019s note: This is the first in an ongoing series on moving our network to the cloud internally at Microsoft.<\/em><\/p>\n

We\u2019re building a more agile, resilient, and stable virtual wide-area network (VWAN) to create a better experience for our employees to connect and collaborate globally. By implementing a continuous integration\/continuous deployment (CI\/CD) approach to building our VWAN-based network infrastructure, we can automate the deployment and configuration processes to ensure rapid and reliable delivery of network changes. Here\u2019s how we\u2019re making that happen internally at Microsoft.<\/p>\n

Infrastructure as code (IaC)<\/h2>\n
\"Jimenez
Juan Jimenez (left) and Eric Scheffler are part of the team in Microsoft Digital that is helping the company move its network to the cloud. Jimenez is a principle cloud network engineer and Scheffler is a senior cloud network engineer.<\/figcaption><\/figure>\n

Infrastructure as code (IaC) is the fundamental principle underlying our entire VWAN infrastructure. Using IaC, we can develop and implement a descriptive model that defines and deploys VWAN components and determines how the components work together. IaC allows us to create and manage a massive network infrastructure with reusable, flexible, and rapid code deployments.<\/p>\n

We created deployment templates and resource modules using the Bicep language in our implementation. These templates and modules describe the desired state of our VWAN infrastructure in a declarative manner. Bicep is a domain-specific language (DSL) that uses declarative syntax to deploy Microsoft Azure resources.<\/a><\/p>\n

We maintain a primary Bicep template that calls separate modules\u2014also maintained in Bicep templates\u2014to create the desired resources for the deployment in alignment with Microsoft best practices. We use this modular approach to apply different deployment patterns to accommodate changes or new requirements.<\/p>\n

With IaC, changes and redeployments are as quick as modifying templates and calling the associated modules. Additionally, parameters for each unique deployment are maintained in separate files from the templates so that different iterations of the same deployment pattern can be deployed without changing the source Bicep code.<\/p>\n

Version control<\/h2>\n

We use Microsoft Azure DevOps, a source control system using Git, to track and manage our IaC templates, modules, and associated parameter files. With Azure DevOps, we can maintain a history of changes, collaborate within teams, and easily roll back to previous versions if necessary.<\/p>\n

We\u2019re also using pull requests to help track change ownership. Azure DevOps tracks changes and associates them with the engineer who made the change. Azure DevOps is a considerable help with several other version control tasks, such as requiring peer reviews and approvals before code is committed to the main branch. Our code artifacts are published to (and consumed from) a Microsoft Azure Container Registry that allows role-based access control of modules. This enables version control throughout the module lifecycle, and it\u2019s easy to share Azure Container Registry artifacts across multiple teams for collaboration.<\/p>\n

Automated testing<\/h2>\n

Responsible deployment is essential with IaC when deploying a set of templates could radically alter critical network infrastructure. We\u2019ve implemented safeguards and tests to validate the correctness and functionality of our code before deployment. These tests include executing the Bicep linter as part of the Azure DevOps deployment pipeline to ensure that all Bicep best practices are being followed and to find potential issues that could cause a deployment to fail.<\/p>\n

We\u2019re also running a test deployment to preview the proposed resource changes before the final deployment. As the process matures, we plan to integrate more testing, including network connectivity tests, security checks, performance benchmarks, and enterprise IP address management (IPAM) integration.<\/p>\n

Configuration management<\/h2>\n

Azure DevOps and Bicep allow us to automate the configuration and provisioning of network objects and services within our VWAN infrastructure. These tools make it easy to define and enforce desired configurations and deployment patterns to ensure consistency across different network environments. Using separate parameter files, we can rapidly deploy new environments in minutes rather than hours without changing the deployment templates or signing in to the Microsoft Azure Portal.<\/p>\n

Continuous deployment<\/h2>\n

The continuous integration (CI) pipeline automates the deployment process for our VWAN infrastructure when the infrastructure code passes all validation and tests. The CI pipeline triggers the deployment process automatically, which might involve deploying virtual machines, building and configuring cloud network objects, setting up VPN connections, or establishing network policies.<\/p>\n

Monitoring and observability<\/h2>\n

We\u2019ve implemented robust monitoring and observability practices for how we deploy and manage our VWAN deployment. Monitoring and observability are helping us to ensure that our CI builds are successful, detect issues promptly, and maintain the health of our development process. Here’s how we\u2019re building monitoring and observability in our Azure DevOps CI pipeline:<\/p>\n