This is a series of posts:

1. Introduction
2. Principles (this post)
3. Layers
4. Traffic
5. Secrets

First and foremost, you have to threat your service’s infrastructure as you threat your service’s code. In other words as infrastructure-as-code. This may include the techniques that are now common in general engineering processes such as:

• Gated build. Each change is built and verified. If this an ARM template, you can run Test-AzResourceGroupDeployment
• Gated deployment. Each change can not just be synthetically validated for the syntax correctness but actually deployed to a test cluster, alongside the basic infrastructure services if possible, what combined would help to ensure the changes are valid and functional
• Continuous Integration (CI). Each change is immediately merged into the main branch and a ready-for-production build is produced
• Continuous Delivery (CD). Each build is immediately deployed to an early test environment and the appropriate tests are performed. Then to another environment, then another.
• Safe Deployment Practices (SDP). Each is build is not deployed to all available environments simultaneously but instead is slowly rolled out across environments and regions. They’re are grouped by kind (prod, pre-prod), geography (North America, Europe, Asia), type of customers (internal, partners, public), and so on.

You may refer to the Build and Deployment section of the Twelve-Factor App for more ideas how to the CI/CD process for both your services and infrastructure should look like.

Employing these and other techniques will help you to achieve multiple goals:

• Increase the confidence in the changes
• Increase the overall quality of the infrastructure by decreasing the number of errors slipping into production
• Allow to catch issues early in the rollout
• Increase the overall time-to-production, the total time it takes for a new feature or a fix to reach the target environment

To be continued…