Configure build agents

Completed

Every pipeline, whether a build or a release, needs to be configured to run with a build agent. The build agent is a small application that will either run in the cloud on Azure Virtual Machines or on-premise on one of your own servers.

The build agent will download the source code from your source repository, compile the code into an application, and run tests on that compiled application. Within a release pipeline, it'll publish the application to a production or test environment.

Depending on the type of subscription you have with Azure DevOps, you have one or more jobs included. With the free basic subscription, you have one parallel job available. A build agent will execute a job, which means that only one job can run before another job can start. You can purchase more jobs if you want to run more build pipelines at the same time.

Build agents are configured within Azure DevOps on an organizational level. Each build agent belongs to an agent pool.

Click on organization settings at the start page of your Azure DevOps environment, and select Agent pools under the Pipelines section. You'll see two pools already configured; Azure Pipelines and Default. The Azure Pipelines pool is used to configure your build pipelines to run the agent on an Azure Virtual Machine. The default agent pool is to group your on-premise build agents. A new pool can always be added using the blue Add pool button.

Screenshot of the Agent pools on the Organization Settings.

If your build process needs to access some local resources, like a SQL Server database or a local webservice, then using the Default agent pool is the only pool you can use.

The Microsoft hosted pools are also limited to 1800 free minutes per month. Of course, you can pay extra to get more available build minutes. If you host the agents locally, you are not confronted with this time limit. If you select a pool, it will display the jobs the pool has executed.

Screenshot of the Agent Pool Job overview.

Under the Agents tab, you can see a list of all the configured and available build agents installed on your different machines. You can immediately see the status of each agent. When a pipeline runs, it will take an available build agent from this pool. If you can run multiple jobs in parallel, then multiple agents will be used in this pool. You can also easily enable or disable an agent in this pool.

In the next example, the three available build agents are all offline.

Screenshot of the build agents offline in the default pool.

Installing a new agent is very easy with the blue New agent button. This will open a pop-up window where you can download the agent in the architecture you want (x64 or x86). Installing an agent is done by following the PowerShell commands listed in the popup screen.

Screenshot of the new build agent steps.

When you run the config.cmd file, you'll have to configure your build agent. It will first ask you to enter the server url. Here you can put the Azure DevOps URL including your organization name.

https://dev.azure.com/organization_name

In the next step, you'll be asked for the authentication type. You can press ENTER to agree with Personal Access Tokens (PAT) and enter your personal access token in the next step. We discussed the creation of PATs in the Use Application Lifecycle Management for Business Central module of this learning path.

You'll then be asked for the name of the Agent pool you'd like to add this agent to. Pressing enter will agree with the default pool. Then you'll be asked for a name for the agent, so you can clearly distinguish your agents in the Azure DevOps agent pool window. By default, it'll suggest the name of the machine where the agent is installed on.

screenshot of the configuration window for a build agent.

In the final steps of the configuration, you need to configure a work folder for the build agent. You can go with the default _work folder, which will be created under the installation folder of the build agent. You can also configure the build agent to run as a service, which will start at your Windows startup. If you select No for these options, then you need to manually run the run.cmd file each time. So, the best practice is to set these options to Yes.

Screenshot of the testing agent connection run as service.

Executing the run.cmd file manually will open a Command prompt that will try to connect to your build server and waits for jobs to be executed. You'll also see that your build agent appears online in the agent pool window in Azure DevOps.

Screenshot of the Default Agents status.

You can repeat this process on all machines that you'd like to add to the agent pool. Once finished, you can start configuring your Azure Pipelines.