Deployment Groups in Visual Studio Team Services

If you use Visual Studio Team Services for your build and deploy process, you may have noticed a new menu item pop up a few months ago – “Deployment Groups”. I’ve been using this new feature in new projects since it came out in preview in May and it’s a great way to handle deployments to multi-server environments.
What’s a deployment group?
A deployment group is effectively a logical organization of your servers. Let’s say you have a staging environment with 2 load balanced web servers and a SQL Server. These 3 servers would constitute a deployment group. Each of these servers would have an agent deployed on them that would handle the deployment. Whenever a release is initiated, VSTS signals these servers and requests them to initiate a deployment. This is more in line with how products such as Octopus Deploy handles deployments.
That’s neat. But I’m already deploying to multiple servers using the “Environments” feature in the current release management. What’s the difference?
In non-deployment group world, this is what your release process would look like:

The build agent is still performing all of the deployment steps by remote access to the web servers through a secure connection. It works great but there are a couple of things to be aware of:

• The servers that the build agent interacts with must have specific incoming ports opened for services such as WinRM and remote PowerShell and the build agent needs to be whitelisted in any firewalls throughout the network stack. This may be more difficult with internal non-production environments that require more security.
• The number of concurrent deployments occurring at any given time is limited by the number of build agents you have in your build agent group. If you have 2 environments with 3 servers each but only one build agent, it will perform the builds on each server sequentially.
• Since all of the deployment work is happening outside of the server, the servers really have no dependency on the release management tool. There isn’t any extra software to install on the servers to support this type of deployment.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

For comparison, this is what the release process would look like if you had deployment groups:

The deployment processes are handled by each web server through an agent that can be installed. This allows the build agent to be more hands off and play more of an orchestration role for the deployment process. Each server in a deployment group can subscribe to a deployment group and deployments can be targeted to deployment groups. Once a server is notified that a deployment needs to occur, the agent on the server goes out and pulls the build artifacts then performs the deployment locally.

• This paradigm uses more of a pub/sub model for deployments. VSTS acts as the publisher and each server acts as the subscriber. Release definitions are then mapped to a deployment group. This makes it easy to add/remove servers for deployments as it’s a matter of subscribing/unsubscribing that server to a deployment group without needing to modify the release process.
• Since each server is performing its own deployment, all deployments are run concurrently across all the servers in the deployment group. Status updates of the deployment are reported back to VSTS, however, the actual deployment work is being performed on each individual server. From a management perspective, everything can still be managed and viewed through the VSTS release management functionality.
• Each target server will need a small agent to be installed in order to register itself with a deployment group and communicate with VSTS as well as provide tooling for deployments. As such, the steps for deploying a deployment group are a little bit different and may not match full parity with its build agent counterpart at the moment. There hasn’t been anything that I’ve seen as potential blockers from lack of support as the ability to execute PowerShell directly on the server covers most anything you need. This also minimizes the attack surface for security as the agent runs locally on the server itself instead of over the network.

So you’re saying I should use deployment groups?
Much like any tool, you should use the right tool for the right situation. But yes. You should.
Have you been using deployment groups for your environments? What are your thoughts on it?