How to setup Azure DevOps Pipelines and Releases with multiple apps

Question

Wanting to deploy a collection of .NET Core API's (microservices) using Azure DevOps I run into some challenges:

Having 10+ small API's, how should I setup the Release Pipeline? One pipeline with one "stage" for each API/application? Or a separate Pipeline for each API?
The API's are deployed to IIS on Windows Server. I'm using the FTP Task now but it's really cumbersome as the AppPool needs to be stopped, then the code is copied over, then the AppPool is started again. I know (non-disruptive) deployment on Azure with App Service is way easier with deployment slots, etc. but what tools can I use on a plain VPS with IIS on Windows Server?
How can I transform or inject the correct appsettings.json values for each environment during Release using Azure DevOps? I could use Pipeline variables but they seem to be shared across the whole Pipeline, so I would need a separate Pipeline for each API then (see question 1). There's the task "Magic Chunks" but it doesn't handle arrays well (which is widely used for Serilog for example). Environment variables on the target machine would be an option, but the API's are deployed to IIS so how can I separate the environment variables per API (there could be the same keys with different values for multiple API's)?

4c74356b41 · Accepted Answer · 2019-02-07 15:13:20Z

2

I use separate pipeline for each app
you could use powershell task to restart IIS, but I dont think there is a way to do this without shutting down the website. You can also reconfigure website, so copy new code to location X, repoint website to location X, restart website. Then you can easily point it back if something fails and switch is almost instanteneous
You can use library variable sets (or groups, dont remember). those can be tied to the stage in the release. it might also be possible to scope regular variables, but I've never tested that.

answered Feb 7, 2019 at 15:13

4c74356b41

1675 bronze badges

To comment further here. 1) each pipeline represents a finished product. Lifecycle of each microservice should be independent thus will need a separate pipeline but that is rarely true unless you have true micro service architecture. 2) Web Deploy task uses MSDeploy.axd underneath; it will take the iis site down but gracefully (there is an outage page you can go to); true blue-green must be achieved with usage 2 web apps and some kind of load balancing device 3) you can tie a variable group to a specific stage and do not need a separate pipeline
– Roman
Commented Sep 13, 2019 at 19:52
What about when various apps have the same pipeline process? How can they be combined.... without cloning pipelines and changing every one when the process changes slightly? @Roman
– AndrewRalon
Commented Jan 6, 2020 at 17:46
you can use templates for that. so create a template and all the "identical" pipelines use the template. and then when you need to change the process - you change the central template
– 4c74356b41
Commented Jan 6, 2020 at 17:53
@4c74356b41 Custom stage templates have issues.... 1) They're only available within that project's Release. link 2) To use them in other Releases, you'd have to export and import it to each Release. link #3) They can't be updated. link
– AndrewRalon
Commented Jan 6, 2020 at 19:07
I have no idea what is a custom stage template. regular yaml templates do not have those issues
– 4c74356b41
Commented Jan 7, 2020 at 5:18

| Show 1 more comment

Sumo · Accepted Answer · 2019-03-28 15:46:18Z

Depends on whether or not these small APIs change together or separately (meaning you may have code changes for only 1 API and be able to deploy it distinctly vs. deploy it all together). If you may have distinct deploy needs, set up separate pipelines.
There are extensions specifically for deploying IIS applications that give you all of the features necessary to properly deploy these sites and control other aspects of IIS.
There are plenty of extensions and built-in features for transforming configuration files or modifying them using variables from within your pipeline. In addition, each environment can have specific variables so that you can configure the same named variable, but change its value per environment.

2 Answers 2