How to build and deploy Azure Cloud Service with multiple configurations in VSTS Release management?

2
votes

We are using Team Services to maintain our web projects and Azure for hosting. At now, there are several Web Roles (asp mvc) and Worker Roles which is being hosted as Cloud Services. We are going to setup Continuous Integration and Delivery for them.

As you know, Team Services Build Definitions suggest to use Azure Cloud Service Template for building and Azure Cloud Service Deployment Task to deploy. We’ve tried it for single cloud service and it works.

In our case, there are web project (web role) and scheduler (worker role) as separate Cloud Services and they should be deployed simultaneously (in sequence), let it be DEV environment. But we have much more environments: dev, qa, ta, demo, preview, production, etc. Furthermore, each of them has slightly different web.config, ServiceDefinition.csdef and ServiceConfiguration.cscfg. And it became much more complicated task than just deploy one Cloud Service.

Questions are:

  • Should we build dozens of Cloud Service pachages (artifacts) and later decide which of them deploy or not? Could you suggest how to do it in a proper way? (in most cases it will be only Dev environment and we will waste time and resources for building other artifacts).

  • Will it be better to build one common artifact and later replace all configurations for specific environment? (It’s more complicated task because Cloud Service package zipped on several occasions with preconfigured ServiceDefinition and ServiceConfiguration)

  • What is the best way to replace configuration tokens (web.config, serviceconfiguration, etc) in Deployment mode, or it should be done while projects is being built?

I would be grateful if you suggest any best practices.

1
asp.net-mvcazure-devopsazure-pipelinesazure-cloud-servicesazure-pipelines-release-pipeline

1 Answers

0
votes

For azure cloud project, it’s better to apply changes to the project per to the environment before build, so you can build the project during the release process.

Regarding to deploy to corresponding environment, you can configure artifact filter with build tag.

For example:

  1. Add a file (e.g. json, xml or txt) to project that used to determine which environments the release should deploy
  2. Add a PowerShell task to build definition to read the data from that file (step1) and add build tag(s) through logging command (Write-Host "##vso[build.addbuildtag]build tag")
  3. Add Publish Build Artifacts task to upload the source files
  4. Create a release definition and link artifacts and add multiple environments
  5. Configure Pre-deployment conditions for each environment: Enable Artifact filters=>Select artifact=>Specify build tags
  6. Add tasks and variables (e.g. visual studio build) for each environment to deploy to corresponding environments.

On the other hand, regarding replace value, there are many ways, such as Replace Tokens, XDT Transform