2

We currently have 4 Azure DevOps team projects that require two Deployment Groups to be created for their SIT and UAT release pipelines. All 4 team projects will share the two Deployment Groups, the idea being to create the deployment group from one team project and then sharing or extending it to the other 3 (which I believe is common practice).

My main concern though is that due to some budget constraints, the decision has been taken to create both SIT and UAT Deployment Groups on a single target server. Much as I strongly believe this is probably not best practice, are there any technical reasons why this cannot or shouldn't be implemented?

hitman126
  • 699
  • 1
  • 12
  • 43

1 Answers1

5

In simple terms, deployment groups is that:

A deployment group is a logical set of deployment target machines that have agents installed on each one. Deployment groups represent the physical environments; for example, "Dev", "Test", "UAT", and "Production". In effect, a deployment group is just another grouping of agents, much like an agent pool.

We support registering the same machine to multiple deployment groups. However you would need to edit the agent name in our PS "registration script" provided in the UI. Or log into the machine physically and execute the script in a different folder than the default one specified in the script.

Normally, we set up deployment groups with multiple agents and run deployment just to target agent according to requirements.

What you can do is assign tags to deployment agents and use tags to assign releases to specific agents.

In summary, it's able to register the same machine/server to multiple deployment groups if you insist on.

But due to server performance, environmental isolation , Disaster Tolerance and other factors.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62