Multi-environment deployment in Azure

by Yuriy Parkhuts,
Senior .NET developer

May 3, 2017
Reading Time: 2 minutes

Microsoft Azure is a great choice when you need a flexible and reliable multi-environment hosting with easy extensibility flow and pay-per-use model. With the introduction of a new resource manager feature, it became pretty straightforward to manage different environments in absolutely automatic and declarative way.

In our project we host every environment as a separate resource group that aggregates resources like web app, virtual machine, database, etc. The architecture of the resource group (environment) and configuration of its resources are declared in the json templates files. This way we have a different setup (e.g. size of VM, hosting plan of web app, volume of storage account, etc.) for different environments. Then we use a set of Power Shell scripts that deploy an environment with defined resources template. The deployment process is absolutely automated and tightly coupled with the continuous integration flow. Here are some main steps we follow:

VCS branch deploy

  • 1
    ​We develop every new project feature in the separate VCS branch and when it’s ready we create a pull request.

Pull request

  • 2
    ​We use Team City as a CI tool. It listens to the GitHub repository and starts a new build triggered by the pull request.

The new release trigger

  • 3
    ​If the build is passed successfully Team City packs the solution projects into the NuGet packages, publishes them to the Octopus Deploy packages repository and triggers a new release in Octopus.

Power Shell scripts

  • 4
    ​Octopus Deploy runs a deployment process using Power Shell scripts mentioned before to deploy a new feature into the testing environment in Azure.


  • 5
    ​Then Team City runs integration and Selenium tests on the Azure testing environment.


  • 6
    ​If tests pass successfully Team City triggers a new release in Octopus Deploy to promote the deployment into the new feature dedicated environment.


  • 7
    ​When deployment is done Octopus Deploy pushes a notification to Slack to let the team members know that new feature is ready for review and manual testing providing the link to the feature environment.


  • 8
    ​After review and manual testing, we merge VCS feature branch with the master brunch and then Team City with Octopus Deploy takes care to deploy a new feature into the staging environment in Azure. Then feature dedicated environment can be removed to save hosting costs.

​Blue and Green deployment

  • 9
    ​When we decide to make a new release in the production environment we use the Blue-Green deployment strategy there. So we have two production environments (blue and green) in Azure using the Traffic Manager to switch between them so at any moment of time one of them is live (e.g. blue) and other one is idle (e.g. green). Firstly we deploy to the green environment and verify that it works correctly with the production database and configurations. Then we switch the Traffic Manager to the green environment so it becomes live and the new feature is available for the clients. In case of some unexpected behaviour we can immediately switch back to the old blue environment to provide the working version to our clients. This approach allows us to minimize the risk and reduce any downtime during releases.

​Microsoft Azure also provides a great monitoring and diagnostics tool called Application Insights which we use to detect and debug issues, optimize the performance and get some statistics.

Find out more about our client-partner for whom we develop a software solution, using Microsoft Azure.

Read more about our technical expertise to find out how can we help your business.