Azure DevOps can be a powerful automation tool, but making decisions about your build server can be a complicated process. There are several factors to consider, such as security, speed, and flexibility. But, if it’s set up correctly, you’ll forget it’s even there. Here is a comparison of your options, as well as a guide to setting up a self-hosted server.
Self-Hosted vs. Microsoft-Hosted Build Servers
You’ll need to set up your build server as a self-hosted or Microsoft-hosted server, and each option has its pros and cons.
A Microsoft-hosted server is created as a fresh virtual machine each time a build is initiated. It’s separate from your own infrastructure, which means any potentially insecure code run during a build won’t run in your environment and won’t expose you to any risk. It also means you don’t have to set up any build servers of your own, and running parallel jobs is just a matter of paying for them (although they are more expensive when hosted by Microsoft).
On the other hand, self-hosted servers require time to set up - but with good documentation, you can typically set up a new server in under an hour. The benefit is that builds run faster since you can cache resources and enable incremental builds. Debugging is easier as well, as you can see the build files as they’re updated.
Using existing resources, such as underused servers or developer’s computers, can minimize costs for self-hosted servers. While using your own computer as a self-hosted server can be convenient, it doesn’t always work well for large teams because the computer always needs to be turned on, otherwise builds will stay queued indefinitely.
One big reason I prefer to use self-hosted servers is that they can have a static IP address. My build pipelines require accessing external servers that only whitelist a small number of IP addresses. Microsoft-hosted build servers use a different IP address range each week, which would require constantly updating that whitelist either manually or programmatically. With self-hosted servers, the IP address remains constant, requiring less ongoing maintenance.
How to Set Up a Self-Hosted Build Server
While Microsoft provides documentation on setting up a build server, I’ve found the experience less straightforward than the steps they provide.
Set Up the Target Server
If you’re deploying code to a target server, complete these steps first.
- Add exceptions for the Windows Remote Management ports in the firewall. Specifically, go to Windows Firewall with Advanced Security → Inbound Rules, and add exceptions for the build server’s IP address for ports 5985 and 5986.
- Set the registry entry for LocalAccountTokenFilterPolicy to 1. Open Registry Editor and update the entry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
- This process involves downloading and installing the Web Platform Installer.
Set Up the Self-Hosted Server
Follow the steps Microsoft provides: create an “agent” directory, run the Add-Type command, run the config file, and follow the prompts. When that’s finished, here’s a trick to prevent your requests from being rejected without knowing why: while running PowerShell as an admin, set the target server as a trusted host using the command: set-item wsman:\localhost\Client\TrustedHosts -value {Target Server IP Address}.
Set Up the Azure DevOps Pipeline
Whether self-hosted or Microsoft-hosted, the last step is to ensure your pipelines are prepared to use an agent, including making sure any build dependencies are included on the server. For example, certain builds may require calling “NuGet restore” to download dependencies, or an application may depend on NPM, so calling “npm install” is necessary for each build.
Deciding which build server to use requires reviewing your environment and project structure to make the best decision. Regardless of which kind you select, it’s possible to set up your processes securely and reliably to make your builds much more convenient with Azure DevOps. Contact DragonSpears to get started.
