Private build agents are a benefit

Azure DevOps offers a hosted build pool. This pool requires no installation on the customer’s part. If your project only depends on the software installed on our hosted build agents, this is a great way to get started quickly building your project.

We also offer a private agent option. This is where the customer installs the build agent on their own personal machine running Windows, Linux, or macOS. I have even seen the agent installed on a Raspberry Pi. This machine can be anywhere. It could be a physical machine or virtual machine, in your datacenter or in the cloud.

When I mention the private build agent option, to my disbelief, it is often met with concern and negativity. This post offers some food for thought on why you need to rethink the private agent option. You need to stop looking at this as something you have to do and be thankful it is something we allow you to do.

1. Your server can cache dependencies. When you are using the hosted build agent, it will be forced to resolve all your packages upon each build even if they have not changed. When you have a private build agent that is not the case. You can benefit from caching dependencies to greatly speed up your build.

2. You can perform incremental builds. When using the hosted build, all the source for your project must be downloaded. Depending on the size of your code base, this could be a considerable amount of time. Because the code had to be downloaded, no binaries from previous builds will be available on the agent and will required a complete build of the code base even if only a few files were changed. A private agent can use the existing code and binaries to do an incremental build which can reduce your build time drastically.

3. You can build an enormous machine. Your build machine can have the fastest CPU, solid state disk, and tons of memory. This will allow the build to complete in a fraction of the time.

4. You are the only one in line. The queue time for each build be will be greatly reduced because this is a private agent just waiting for you or your team. The queue time is also reduced because the machine does not have to be provisioned. The machine is ready and waiting for build requests.

5. You can install anything you want on it! We do our best to have the latest versions of tools on our hosted build agent. However, if you want to start testing with beta versions of software, that will not be possible on our hosted build agents. It also takes time for us to create new build images when new versions of software are released. With a private agent, you can update it whenever you need to whatever version you desire. Furthermore, there are products you may use that will simply never be installed on a hosted build agent.

6. You can run your agent in interactive mode. Our hosted build agents run as Windows services which prevents them from interacting with the desktop. Therefore, you cannot run UI tests that attempt to start applications on the build agent, such as Coded UI Tests.

7. You can install on Apple OS X. Our hosted pools are Windows and Linux (coming soon) machines only. Therefore, if you want to build for iOS on a Mac, you cannot in our hosted pools.

8. You have unlimited build minutes. With your Azure DevOps account you are allotted a fixed number of free build minutes each month. If you have a very long build, this could result in you having to purchase additional minutes. However, on a private build agent, your builds can take as long as they need at no additional cost.

9. Your first private agent is free. Included with your Azure DevOps account is the right to install a private build agent at no additional cost.

10. You can log into the machine. This might not seem like a big deal while your builds are working, but I find it very useful when trying to troubleshoot a build. When something goes wrong I can log onto the machine and look around to see what is going one. Once I have it working I can then target Hosted Pool with a higher degree of confidence that the build will succeed.

11. You can run as administrator. Depending on what you are trying to do, you might have to run the agent as administrator. That is only possible on a private build agent.

12. You can produce builds of any size. Some projects produce a large amount of output. If your output is greater than 10 GB you cannot run that build on the Hosted pool.

For the reasons listed above, I almost exclusively use private build agents. The installation of the agent is as simple as running a script, and the power and control it offers more than outweighs the occasional need to install updates and reboot the machine.

Comments (10) -

  • Brent Anderson

    12/11/2016 6:09:53 PM | Reply

    I've been using the private Mac agent for over a year now and immediately realized the FREE value MSFT was providing from the moment I came upon the VSO agent bits on github. Having the option to run iOS builds with all the Team Services cloud functionality without needing to go elsewhere for the Mac portion is very very nice.

    I want to express EXTREME GRATITUDE for providing this feature to us!! Thank you!!

    And you're right, anyone that doesn't get it, is totally missing the point: it's a real gift, that we can CHOOSE to use, not a burden. I saw you make this point during the recent Connect() presentations and was dumbfounded anyone would be looking this gift horse in the mouth any other way.

    While I'm here, a question - I'm just reading the recent MSDN mag article on Mobile Center... it seems that we get free iOS builds in the cloud there?

    • Donovan

      12/11/2016 9:16:29 PM | Reply

      With mobile center the Macs are provided.

  • Thierry, Brunet de Courssou

    12/11/2016 8:54:21 PM | Reply

    The benefits of using private agents as detailed in your post is quite clear. Can you possibly give further insight on how load balancing with private agent queue pools works? How is the caching resolved? Load Balancing for BUILD definitions, load balancing for RELEASE definitions. How an executing release gets its components from previous builds? With a complex release definition comprising many tasks, each task is placed in the queue waiting for an available private agent, in accordance with capability demand. Successive tasks in  a release definition may be executed by a different agent. A the present time, for long release definitions, as developers are complaining that the wrong code is being deployed, I set a demand for executing only on a predetermined agent, which defeats the benefit of load balancing. 3 months ago the VSTS sprint release was unstable (CIs would not trigger) and the load balancing may have been incorrect then. May be it is fixed. Anyway, clarifying the load balancing scheme design with be helpful.

    • Donovan

      12/11/2016 9:15:19 PM | Reply

      I will track down the details.

    • Chris

      12/12/2016 1:30:35 PM | Reply

      Agents are picked based on demands of the definition and then the first idle agents is picked from that list.  On the agent each build definition has its own directory and that is either clean or not between build depending on the settings of the definition.

      For release the bits are downloaded from the build the release is triggered on and all tasks in a given phase of a release environment are run in sequence on an agent, they are not queued individually.

  • Thierry, Brunet de Courssou

    12/11/2016 8:57:39 PM | Reply

    Can private agents run on my W10 laptop or in a Hyper-V VM on my laptop? I don't want to consume my free private agent. This would be handy to learn the full benefits of private agents and for training.

    • Donovan

      12/11/2016 9:14:43 PM | Reply

      Once you register the agent that will consume your private agent no matter where the agent is running. However, given the fact the code is all open source if you build your own copy you might be able to get it to run locally without registering it.  I have not tried but I might now that you have sparked my interest.

      • David Parvin

        2/20/2017 5:20:25 PM | Reply

        When I tried this, the agent can be turned on or off, so if you have more than one registered, you can turn off the one that you do not want to use and turn on the one you do.  I found this out because I had to register a new one to replace one that I was not using and the warning showed.  As soon as I disabled the old build agent, the warning went away.

  • Thierry, Brunet de Courssou

    12/11/2016 9:14:53 PM | Reply

    The "Check Certificate" option for WinRM deployment tasks over https needs to be set when using the hosted agent because the remote machine self-signed certificate cannot be imported into the hosted agent. Thus this "Check Certificate" option means "dear host execution security context, please don't check the certificate, simply use SSL encryption using the remote machine self-signed X509 certificate but without checking that the self-signed certificate has been issued by a trusted authority or intermediate authority". Confusing contradicting english between the intent above and "Check Certificate" option label. What am I missing?

    The comments in the pop-up associated to the "Check Certificate" label are not clear on this, and updating the comments in a next sprint would be helpful to avoid confusion.

    • Roopesh Nair

      12/12/2016 5:13:14 AM | Reply

      Can you please elaborate where you find "Check certificate" option? I double checked WinRM deployment tasks. 
      The option is 'Test certificate' - which indicates it is a self-signed one and not from a trusted CA.
      The help text is - "Select the option to skip validating the authenticity of the machine's certificate by a trusted certification authority. The parameter is required for the WinRM HTTPS protocol."

Pingbacks and trackbacks (4)+

Add comment

Loading