<p>You can separate the steps, especially as it would let you do divide the work among different agents. You can also leave them in a single agent if you wish. </p>

<p>The primary advantage I see is leveraging different pools for different sets of work.</p>

<p>With releases last I checked variable scope was limited (as of 2018) to the "phase". </p>

<p>I wouldn't necessarily worry about performance due to connections unless you've observed this issue and have more specific detail you can add.</p>

CC BY-SA 4.0
2019-03-14T08:03:56.540Z
2019-03-14T08:03:56.540Z
sheldonhull
<p>I am new on DevOps world and I am making my first build/release pipeline for a .net web application using Azure DevOps. On the picture bellow, I just add some build steps and create some tasks groups to avoid duplications on the builds (that are similar). I have the <code>Run on agent</code> that I called it as <code>Qa Agent Job</code>  which runs over the local build agent hosted on my build server (as a windows service). </p>

<p>My question is related with organization. I have some build steps here and I would like to organize it by sessions, for sample, Nuget Restore, Versioning, Build, Testing, Building services, Publishing artifacts etc. Is that a problem to organize it using the <code>Run on agent</code> item on build step? Should I lost any performance like "connecting on the server again" or "start a new process" or something like that?</p>

<p>Thank you.</p>

<p><a href="https://i.sstatic.net/Zzq8F.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Zzq8F.png" alt="enter image description here"></a></p>

CC BY-SA 4.0
2019-03-07T14:34:20.080Z
Do you want to run the tasks in many agents?
Shayki Abramczyk
CC BY-SA 4.0
2019-03-07T14:38:39.587Z
Well, we have an agent pool defined and inside this one we have 3 agents (windows services).
Felipe Oriani
<azure-devops><build-pipeline><release>
Organizing the build steps on AzureDevOps
Felipe Oriani
# Organizing the build steps on AzureDevOps

(Asked by: username_0 on 2019-03-06)

I am new on DevOps world and I am making my first build/release pipeline for a .net web application using Azure DevOps. On the picture bellow, I just add some build steps and create some tasks groups to avoid duplications on the builds (that are similar). I have the `Run on agent` that I called it as `Qa Agent Job` which runs over the local build agent hosted on my build server (as a windows service).

My question is related with organization. I have some build steps here and I would like to organize it by sessions, for sample, Nuget Restore, Versioning, Build, Testing, Building services, Publishing artifacts etc. Is that a problem to organize it using the `Run on agent` item on build step? Should I lost any performance like "connecting on the server again" or "start a new process" or something like that?

Thank you.

[![enter image description here](https://i.sstatic.net/Zzq8F.png)](https://i.sstatic.net/Zzq8F.png)

**Tags:** azure-devops, build-pipeline, release

> **Comments:**
> **username_1**: Do you want to run the tasks in many agents?  
> **username_0**: Well, we have an agent pool defined and inside this one we have 3 agents (windows services).  

---

## 1 answers

### Answer by username_2 on 2019-03-14. Score: 1 | Accepted answer

You can separate the steps, especially as it would let you do divide the work among different agents. You can also leave them in a single agent if you wish.

The primary advantage I see is leveraging different pools for different sets of work.

With releases last I checked variable scope was limited (as of 2018) to the "phase".

I wouldn't necessarily worry about performance due to connections unless you've observed this issue and have more specific detail you can add.


---

