Azure DevOps has brilliant build pipeline options and as easy as it is to get set up with their hosted build agents, it can get quite costly rather quick. In this post I cover off setting up a self-hosted build agent for use with Azure.
This post won’t cover setting up the build box, but can be covered in a later guide if required. I actually have my build box scripted out using Choco commands to allow building of .NET projects to make this step easier.
Pros/Cons
- Pro: Full control over the build
- Pro: Can have your builds build items or run services which simply aren’t available in the Hosted agents.
- Pro: Low cost. If you already have the hardware, why pay for Azure VMs?
- Con: Maintenance and redundancy. If the machine goes down or breaks it blocks your pipeline.
- Con: Extra setup steps.
Prerequisites
Before starting you will need to make sure:
- You are a collection/build admin
- You have a server configured to build the appropriate software (i.e. Correct SDKs etc which won’t be covered in this post)
Personal Access Tokens
First of all, you will need a personal access token for your account. This is used to allow your build agent access to Azure without hard-coding your credentials into your build scripts. You can use your own account for this, or a specially created service account – Just note it will need permissions to access the collections it will be building.
To get this, log in to your Azure Devops portal, and navigate to your security page.
In here, select “Personal Access Tokens” and then “New”. A panel will be displayed to configure this PAT. Specify a friendly and unique name, select the organisation you are using this token for, and then set its security access.
For the security access, I recommend selecting Full Access under “Scopes” so you can use this PAT for general Dev Ops activities. You can fine-tune the control, but you must ensure it has read/execute on the build scope as an absolute minimum. For expiry I typically select the longest period which is 1 year.
Agent download and configuration
Next up you will need to navigate to the project settings > Pipelines > Agent Pools.
Create a new Agent Pool with an appropriate name (You don’t *have* to do this and can just use the default pool if you wish, but I like the separation). When your pool is created you will see the option to add a new agent to it.
Clicking “New Agent” will give you the instructions for the OS of your choice. As per the instructions, download the agent (A ~130 ZIP file) and then place somewhere sensible on the machine that will be acting as a build server. When extracted, run config.cmd in an elevated command window
When running the config.cmd command you will require the following information:
- Server URL
- This will be https://dev.azure.com/{organisation name}
- What type of authentication you will use (Just press return as it will default to PAT)
- Your PAT to access the server, as set up in the first step.
- The Pool to connect to. This will be the name of the agent pool created above.
- The working folder. The folder to use for storing workspaces being built.
- A name for this agent. Call it whatever you want, but I would personally always include the machine name as it makes it easier to work out which agents are running.
Providing all the above settings are specified correctly and there are no authentication issues, it should now attempt to start.
Confirming the agent is active
Going back to the Agent Pools configuration screen you should now see the agent listed in the appropriate agent pool.
If the agent is not displaying after a few minutes, something went wrong in setup.
If the agent is displaying offline, try running the “run.cmd” command in an elevated command window on your build server.
Now all you have to do is select your new agent pool when creating your next build!
The post Setting up a self-hosted build agent for Azure DevOps appeared first on yer.ac | Adventures of a developer, and other things..
Top comments (0)