Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-03-14T08:03:56.540Z
Answers: 2019-03-14T08:03:56.540Z
Answers: sheldonhull
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2019-03-07T14:34:20.080Z
Comments: Do you want to run the tasks in many agents?
Comments: Shayki Abramczyk
Comments: CC BY-SA 4.0
Comments: 2019-03-07T14:38:39.587Z
Comments: Well, we have an agent pool defined and inside this one we have 3 agents (windows services).
Comments: Felipe Oriani
Tags: <azure-devops><build-pipeline><release>
Title: Organizing the build steps on AzureDevOps
UserDisplayName: Felipe Oriani
ThreadText: # 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.
  
  
  ---
  
  