Agent-based deployment in Release Management

Agent-based deployment in Release Management

Our approach in Release management so far has been to integrate with various deployment tools and platforms while providing rich control over the flow of bits, traceability, and auditability.

When it comes to PaaS deployments, we have first-class integration with Azure, platform abstracts out the complexity. For IaaS deployments, we have provided the ability to run scripts on a proxy agent or on the target servers using remote scripting tasks.  Though it’s not always that hard to deploy to a single target, the promise of continuous value delivery relies on the ability to continuously publish updated versions of an application across a variety of environments for various purposes each having multitude of targets/roles, which can be very difficult to perform and manage.

We have been working on adding robust in-the-box multi-machine deployment pipeline using Release Management. Where you can orchestrate  deployments across multiple nodes, perform rolling updates while ensuring high availability of the application throughout. Agent based deployment capability relies on the same build and deployment agents. However, unlike the current approach, where you install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers, you can install the agent on each of your target servers directly, and then drive rolling deployment to those servers.

With this you can use the same proven cross-platform agent and its pull-based execution model to easily drive deployments on a large number of servers no matter which domain they are on, without having to worry about the myriad of pre-requisites.

Before we get started, here are some concepts you need to get familiar with:

Deployment Group (aka Machine Group)

Deployment group is a logical group of targets (machines) with agents installed on each of them. They also specify the security context. For example, ‘Dev’, ‘Test’, ‘UAT’, and ‘Production’ – each of them having one or more physical/virtual machines.


Each Phase represents a composite step in build or release process. It is a logical group of tasks that contains everything that is required to support that step. A Phase has a run characteristic, it can be run against an ‘Agent queue’ or a ‘Deployment Group’ or just call out to an external service by pausing the workflow  – ‘Server phase’.

Let’s get started with agent based deployment in release. Here are a couple of screenshots to explain how this experience is shaping up.

  • Create your ‘Deployment Group’ by installing and configuring ‘build and deployment agents’. Note: In the screenshots below, they are still being referred to as ‘Machine Groups’createdeploymentgroup
  • Monitor the targets under the deployment groups tab in Release hub. You can even track the deployments on each machine. You can tag the machine in the group so that you can deploy to the targets having ‘specific’ tags. For example, you can have few of them tagged as ‘Web’ and direct your web packages to be delivered to them using ‘Tags’ feature in phase properties. deploymentgroupreleases
  • Deploy to the targets in the deployment group using phase control.deploytodeploymenggroup

Deployment group phase

A bit more on deployment group phase, as mentioned before deployment phase targets a deployment group. Additionally, it lets you target a subset of machines in the group with help of ‘Tags’.

‘Deployment Configuration’ enables rolling deployment to the targets in the deployment group. Deployment configuration specifies the percentage of targets that are being deployed to and inturn computes the targets that must remain available at any time during deployment.

For example, Deploy to ‘1/2 of the targets in parallel’ –  If the deployment group had 10 targets, it attempts to deploy to 5 targets in parallel. Once the deployment to ‘5’ is successful, it attempts deployment on the remaining ‘5’ targets. The overall deployment will succeed if the deployment to 5 or more targets succeed else the deployment fails.

Bootstraping agents: We have made bootstrapping the agents on the target simpler. You can just copy-paste the cmdlet appropriate for the OS and it will take care of downloading, installation and configuring the agent against the deployment group. It even has an option to generate the cmdlet with ‘Personal Access Token’ so that you don’t have to.

  • If it is Azure, you can do it on-demand using Team Services extension for the VM or use Azure PowerShell/CLI to add the extension which will bootstrap the deployment agent.
  • You can automate using resource extension in the Azure template json.
  • We plan to enhance ‘Azure Resource Group’ task to dynamically bootstrap agents on the newly provisioned / pre-existing Virtual Machines on Azure.teamservicesagent

Push, Pull deployments

We have taken a new approach with Team Services. It is an approach that has both the models, push and pull: i) proxy agent based model where user has the power of orchestration. And ii) pull-agent on the targets participating in the orchestration driven by Release Management. 

Got feedback?

Agent based deployment feature is currently in early adopter phase, if you would like to participate or If you have suggestions on how can we make agent-based deployment better for you? Here is how you can get in touch with us