Disclosure: This post assumes you are familiar with Team Build and Release Management

Recently Microsoft announced Deployment Groups Preview for Visual Studio Team Services (VSTS). Until now, if you were using the latest version of Release Management, the only option for deployments are the agent-less option, referring for the no need for an agent on the deployment machines (of course you need a VSTS Build/RM agent). For me this has it advantages, enabling deployment scenarios in which you are not able to install an agent on the final machines, which usually is preferred by operations guys, and for me also (less things to take care of …)

But this leads us to other disadvantages, in example, if you want to deploy an application to a set of servers using current tasks, you will need first to enable Powershell Remote by hand, also you will have to manage by yourself all the pipelines to do a roll.out deployment (not deploying the latest version to all machines at once), so you don’t have an easy way to just deploy just to a set of machines and gradually deploy the new version to all machines to prevent service stops and also to be more aware of possible fails.

With Deployment Groups, you will need to first install the deployment agent on the final machines, and then you will be able to add the different machines to different deployment groups to be used in the pipelines, but also, instruct Release Management to deploy gradually to the machines belonging to a Deployment Group. Also, this can be used to create different pipelines, to deploy gradually, in a controlled way, the version to different set of servers so you can gradually provide the latest version of the application to different group of users (this will sounds you familiar if you are used on how Facebook, Twitter or even VSTS deploys its new versions).

Let’s start with this, first, of course this is only “supported” for On-Premises scenarios, or IaaS scenarios on any cloud, this is not supported on PaaS, as you won’t be able to install the agent.

To install the agent, if you have your own on-prem servers or you are using IaaS on a cloud different from Azure, you will need to go to your VSTS subscription, to the Deployment Groups section under Build & Release section, and you will see this:

First time you enter here you will be shown to create a new Deployment Group, when you click “Add deployment group” you will be asked the provide a name and then you will be shown this screen, with a Powershell snippet to be execute on the machine you want the agent to be installed, be sure to select “Use a personal access token” for the case you just want to use a token for authentication, select copy script to clipboard, paste t on the machine on an admin Powershell console and that’s all.

If you are using a Virtual Machine on Azure, this is even more simple, as you can install it as an extension, just be sure to have the Deployment Group (just create it with a name) on VSTS, and then on your VM, under extensions, select and configure the Team Agent extension:

Now, when creating the Release, in the pipelines for the environments, you can select add a new phase of Deployment Group type:

If we add a new phase like this, on its options, we can see this options:

Notice we can even use tags for the machines inside the Deployment Groups to even have more fine grained control on which machines we are going to deploy a version of the application. Also notice how in the Deploy To options, we can gradually deploy (1/2 targets, 1/4 targets, 1 target, custom …) the application to the machines belonging to the Deployment Group. In this capture I have selected a Deployment Group with only 1 machine, that’s why shows Not applicable …

This gives us a lot of control, so for example we can deploy to one quarter of the machines of the group at once, taking them out of service, but not affecting the global service, deploy the application here, put them onto service again, stopping the next subset of machines, deploying, starting, and so on to the rest of the machines. Also if the deployment fails on any subset of the machines, it won’t continue thus not affecting the rest of the machines in the Deployment Group, givin us that fine grained control over the deployments.

Now we can start adding the needed tasks for our deployment, but notice this tasks will execute directly on the machines we are deploying, so if in our previous agent-less deployments we used to have Remote Powershell tasks in example, here we will use normal Execute Powershell tasks to execute any Powershell needed on the target machines, as it will be the deployment agent inside the target machines the one which will execute them, this applies also for any file copy tasks and so on, as everything will be launched locally.

Hope this leads you to interest on Deployment groups, and start to thinking on them for your on-prem or IaaS deployments. You can have more info on Deployment Groups here: https://www.visualstudio.com/en-us/docs/build/concepts/definitions/release/deployment-groups/