by Mossy9 on 3/4/25, 4:25 PM with 48 comments
by jiggawatts on 3/8/25, 7:46 AM
You absolutely should not remote into the web server box from the agent box! This goes entirely against the grain of how modern Azure DevOps pipelines deployments are designed to work... hence the security issue that the hapless blogger is trying to unnecessarily solve.
The correct approach is to install the DevOps Agent directly onto the IIS web hosts, linking them to a named Environment such as "Production Web App Farm A" or whatever. See: https://learn.microsoft.com/en-us/azure/devops/pipelines/pro...
In your pipelines, you can now utilise Deployment Jobs linked to that named environment: https://learn.microsoft.com/en-us/azure/devops/pipelines/pro...
Deployment jobs have all sorts of fancy built-in capabilities such as pre-deployment tasks, rolling and canary strategies, post-deployment tasks, health checks, etc...
They're designed to dynamically pick up the current "pool" of VMs linked to the environment through the agents, so you don't need to inject machine names via pipeline parameters. Especially when you have many apps on a shared pool of servers, this cuts down on meaningless boilerplate.
All of the above works even with annoying requirements such as third-party applications where active-passive mode must be used for licensing reasons. (I'm looking at you ESRI and your overpriced software). The trick is to 'tag' the agents during setup, which can then be used later in pipelines to filter "active" versus "passive" nodes.
by bob1029 on 3/8/25, 8:38 AM
IIS isn't "bad", but it's definitely way more complicated than these newer hosting models.
Controlling 100% of the hosting environment from code is a really nice shift in responsibility. Takes all the mess out of your tooling and processes. Most of the scary is resolved at code review time.
by bragh on 3/8/25, 7:00 AM
Can't find the documentation for it now, but in some version of msdeploy they also added a way to automatically bring the site offline while deployment was done so that the deployment is not blocked by files in use.
by egamirorrim on 3/8/25, 7:06 AM
I'm very unfamiliar with IIS hosting though, does it support any kind of containerisation/deployment immutability at all?
by Mossy9 on 3/8/25, 7:17 AM
For those wondering how anyone is dealing with such an ancient process, I've written a piece about the history of automation in our org that might shed some light: https://rewiring.bearblog.dev/automation-journey-of-a-legacy...
by Kwpolska on 3/8/25, 1:08 PM
by junto on 3/8/25, 9:39 AM