Reputation: 647
When it comes to deploying your code, VSTS gives you two options (1) Install a agent on a build server and deploy that way or (2) install an agent directly on the actual servers themselves (this is called Deployment Group - mainly because you can install agents on several servers and group them).
If you use option (1) your code is deployed from the build agent to your prod server using WinRM usually.
If you use option (2) the code is downloaded directly to the prod server you want to deploy to and the agent on that box deploys the code.
I have some reservations about installing agents directly on my production boxes and connecting them to VSTS (option 2).
Which method do you guys use?
Upvotes: 2
Views: 1404
Reputation: 38106
Whether use option1 or option2 for deployment it’s depend on whether you want to deploy parallel on the agent machines or not.
For a deployment group, you can add multiple machines. So in your release definition, if you run tasks on a deployment group, you can deply all targets in parallel.
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.
When authoring a VSTS or TFS Release definition, you can specify the deployment targets for a phase using a deployment group. This makes it easy to define parallel execution of deployment tasks.
More details about deployment groups, you can refer deployment groups.
For security of the two options, both of them are safe enough. But you can assign security roles for deployemnt groups.
Upvotes: 2