3

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.

Robert Johnson
  • 31
  • 2
  • 1
    This has a high chance of getting closed as opinion based... My answer is it depends... One release with a matrix stage would allow you to at least standardize the workflow to a single workflow. You could also look at deployment groups as an option to target multiple servers all at once or with different deployment patterns. If per client approval is important you'll and up with a pattern that has a release stage per client. Either in one big workflow or in many similar ones. You can use templates to at least align all the workflow logic in a single place. – jessehouwing Feb 10 '22 at 17:57

1 Answers1

1

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.
piotr.gradzinski
  • 873
  • 1
  • 10
  • 22