Forum Discussion
Share VM Environment with multiple DevOps projects
Hi, I created a VM Environment in my DevOps Project that I use in a multi-stage YAML pipeline to deploy a Web API to IIS. Is it possible to share that same VM Environment with other DevOps Projec...
I ended up creating a VM Environment for each DevOps Project and install those as separate agents on the same server. If you want to do this as well, make sure you use a different environment name for each project.
The reason for this is when you install the agent as a Windows service using Powershell, the environment name is used in the name of the service.
So if you use the same environment name, the installation will fail because a Windows service with that name already exists.
To make sure these conflicts never occur, I used this naming convention: <project name>-<environment name>
The reason for this is when you install the agent as a Windows service using Powershell, the environment name is used in the name of the service.
So if you use the same environment name, the installation will fail because a Windows service with that name already exists.
To make sure these conflicts never occur, I used this naming convention: <project name>-<environment name>
wbosland Thanks for the info, and for the heads up about the environment name, much appreciated.
Shame that MSFT don't allow you to set up a single environment and use it across projects. One of our servers has 20ish IIS sites on it for testing various web apps. That's gonna be a lot of agents!
No problem. There is another https://developercommunity.visualstudio.com/t/share-a-vm-resource-among-different-environment/963981 about this from 2020, so this has been a problem for a while now unfortunately.
By the way, I wrote an article on https://cloudfirstapproach.com/build-deploy-web-api-to-iis-using-multi-stage-pipeline/. You can almost copy paste the YAML code to get it working, you only have to change some names and paths.
- Cheers, that looks helpful - hadn't previously seen the task for stopping the IIS service (which no doubt we would need for production as .NET core is awful for locking the dll files up).