Azure DevOps - Deploy One Build Artifact To Multiple Web Sites

user_14204939 0
Viewed 367

We currently have one build artifact that needs to be deployed to a deployment group of multiple ASP servers with multiple IIS client sites. There are up to 20 servers with 30 client sites on each server. One advantage is each site has the same physical path except for the client name:

  • C:\Web\Sites\Client1
  • C:\Web\Sites\Client2

Has anyone deployed one build artifact to multiple sites? I also want the flexibility of deploying to individual sites for support/upgrade purposes. I was thinking about the following options:

  • A release pipeline for each client site (30 release pipelines)
  • One release pipeline with a production stage for each client site (30 stages)
  • Some way to dynamically trigger one production stage for each client site

Any ideas or examples would be greatly appreciated.

azure-pipelines-release-pipeline azure-pipelines azure-devops
1 Answers

I have a similar situation, where I deploy one build to many environments. As @jessehouwing is suggesting you can use Deployment Groups but this is not working for me since I don't have VMs but Azure Webapp Services.

What works for me:

  • 1 release pipeline per client - you can easily perform deployments in batches (or trigger automatic release), and when you want to deploy only to one client, it's not a problem. For me, it's better than 1 release pipeline with many stages - one per client, because very quickly you will have a lot of update releases, which are mixing with deployments to all clients and it will create a mess.
  • triggers - you can tag your build and then use this tag to automatically create releases to all of the release pipelines. On a release pipeline stage level your can decide about automatic release creation/execution based on build branch and tag. See my post on how to add tag to your build and use it in release pipeline in Azure DevOps.

To ease the process around release pipeline creation (for new environments/clients) you can use:

  • cloning - you can just clone existing pipeline and just change the config
  • export/import - you use this process to export pipeline definition, then modify it in some script and then import as a new pipeline
  • tasks groups - something I find very useful. You can group whole bunch of tasks you have within a stage into task group. Basically you can create your own tasks based on existing tasks. Then, you can add such task group to other pipelines and instead of configuring 10 tasks you can add 1 task group.
  • variable groups / library - instead of putting variables into the pipeline you can create variable group and then just connect such group to particular stage or to whole release. I find this very helpful, especially when I have multiple release pipelines for one client and they share a lot of configuration.
user_7790840
Related