0

Deployment Agent seems to be single threaded but we need multiple

We have 2 Release Pipelines and Stages in our Azure Devops Release Pipeline that share the same "Deployment Group" which has a single agent on a single server.

+----------------------+-------------+-------------------------------------+
|   Release Pipeline   |   Stage     | Maximum No of Parallel Deployments  |
+----------------------+-------------+-------------------------------------+
| VegaDW-Full-Release  | Smoke       |                                   5 |
| VegaDW-Regular-Tasks | Safe Backup |                                   1 |
+----------------------+-------------+-------------------------------------+

I've indicated the number of parallel deployments set in the Deployment Queue settings of the Pre-deployment conditions of each stage above

However when VegaDW-Regular-Tasks\Safe Backup is running it seems to block the progress of any VegaDW-Full-Release\Smoke releases and so single-threading our releases. I also don't see setting the Smoke to 5 made any difference, it still seems to be single threading.

Is there any way to solve this?

The Agent.Version is showing as 2.140.2 is this an old version that can't do multithreaded releases? How do I update the agent if necessary? Thanks for your help

I've also read that you can't deploy more than one agent on a machine at a time, which was another idea I had to solve this, but this seems overkill.

Brett
  • 719
  • 1
  • 7
  • 19

1 Answers1

2

Agents are single-threaded. One agent = one degree of parallelism. That's by design. For additional degrees of parallelism, you need additional agents.

The problem is that you are not using deployment groups for their intended purpose. Deployment groups are for defining sets of individual servers, with each server being represented by a single agent. Think of something like a Puppet or Chef agent. If you want to run one set of activities across a bunch of servers, you use deployment groups and install the agent on each server, then you can run those activities on all of those machines.

For your scenario, you want to use regular agent pools with a set of agents installed on a dedicated machine (or multiple dedicated machines, depending). You can then parallelize the running of your smoke tests however you'd like.

Your release definition configuration is also a little bit suspect. I'm not sure why you'd have two release definitions that are supposed to be run in parallel. That's just asking for race conditions to pop up. If you were to describe the goal of each of these release definitions in more detail, it's entirely possible there's a more idiomatic way to achieve the results you're looking for.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • Thanks. I have now created 2 agents on the same machine and given them different tags. That allows parallel workloads to happen between two different release pipelines. Just to answer that question about why the Regular-Tasks pipeline are basically scheduled tasks that happen daily (cleanup activity on old development dbs/folders etc). It just gets the latest git commit and uses the various scripts to do the scheduled tasks each day The other one "Full-Release" is the actual deploy from artifact method with a Smoke, Test, Acceptance and Production stage. only Smoke should be parallel – Brett Oct 08 '19 at 20:20
  • I had assumed that Agent Pools were just for build agents (i've inherited this configuration). But I get it now. Deployment Agents are for single target single threaded deploys, (standard) Agents are for multi threaded and I guess that is what the Maximum no of parallel deployments is for. Thanks, I'll mark as the answer – Brett Oct 08 '19 at 20:31