Introducing TeamCity Azure plugin – Run builds in the cloud

Maarten Balliauw

In a large TeamCity setup with many projects, it’s often very difficult to predict the load on build agents, for example during releases. One minute we need only one agent to be running, the next minute we need 50. Not to worry! TeamCity supports scaling out builds to Amazon EC2, and starting today, also Microsoft Azure!

For each queued build, TeamCity first tries to start it on one of the regular, non-cloud agents. If there are no regular agents available, TeamCity finds a virtual machine or virtual machine image with a compatible agent and starts it on Azure. TeamCity ensures that the configured maximum number of instances is never exceeded. Let’s have a look at how we can get started with a Windows or Linux build agent farm on Microsoft’s cloud platform.

Installing the TeamCity Azure plugin

First things first, of course. The TeamCity Azure plugin is not bundled and therefore has to be installed on our TeamCity server. It is compatible with TeamCity 8.1 and the EAP of TeamCity 9. Shutdown the TeamCity server, download the latest version of the plugin from our build server and copy the downloaded zip archive to the <TeamCity Data Directory>/plugins directory. Next, start the TeamCity server again and verify the plugin was loaded correctly from the Administration | Plugins List page.

Once that’s done, we can get started with creating a virtual machine or virtual machine image for our build farm.

Preparing a Virtual Machine (Image) with TeamCity Agent

We’ll need to create a virtual machine (image) on which our builds will run. In short, we need to create a Windows or Linux virtual machine:

• on which all build prerequisites are installed (e.g. Java, .NET, Visual Studio SDK’s, …).
  Tip: When you plan on testing this plugin for .NET builds and have an MSDN-enabled Azure subscription, this is a step that can be quickly done by creating a virtual machine from a readily-available Visual Studio image.
  
  
• on which a TeamCity build agent is installed and configured.
• on which we’ve opened port 9090 (or a port range in case we want to have TeamCity create virtual machines for us) in the operating system firewall and as an endpoint on the Azure load balancer. This is required to enable two-way communication between TeamCity server and the agent.
• with which we have tested the connection between the TeamCity server and the build agent.

If we want TeamCity to create virtual machines for us, we will also have to create a generalized image of he virtual machine we’ve just created. Check the full documentation for a detailed list of steps involved in creating a build agent virtual machine (image).

Configure the TeamCity Azure plugin

Once we have the plugin installed and have a virtual machine (image) our builds can run on, we can configure the TeamCity Azure plugin. From the TeamCity | Administration | Server Administration | Agent Cloud page, we can create a cloud profile with the “Azure” type.

We will need at least a name for our cloud profile. The Terminate Instance Idle Time is an important one to configure: it tells TeamCity how long an instance can be idle before it will be stopped. As Microsoft calculates costs based on the number of minutes a machine runs, it is recommended to adjust this setting according to our usual build length. This reduces the amount of time a virtual machine is running and thus, reduces the cost.

TeamCity will need two more things to be able to provision virtual machines on Azure: a management certificate and the ID of the subscription in which to deploy build agents. After downloading the publish settings, find these values in the downloaded XML files and paste them in the plugin configuration.

Clicking Add Image lets us specify the virtual machine (image) we want TeamCity to run. The TeamCity Azure plugin supports two modes of operation:

• Start/stop, which starts and stops an existing virtual machine on demand.
• Image-based, which creates and destroys virtual machines based on an image.

Let’s go with an image-based approach and provision up to 10 agents based on the TC-Agent image I’ve created. We have to specify the service in which we want to provision virtual machines. The service must be either empty or contain only a virtual machine deployment. It is recommended to create a new, empty service for this.

Next we can choose the VM size, as well as a username/password for the user that will be created during the provisioning process. Note that the password has to match Azure’s password requirements.

After adding the image and saving the cloud profile, TeamCity does a test start for them to learn about the agents configured on them. Once agents are connected, TeamCity stores their parameters to be able to correctly process build configurations-to-agents compatibility.

From now on, TeamCity will first try to start builds on regular build agents. If none are available, it will start compatible agents in Azure. We can see the running images from the Agents | Cloud page and optionally start/stop them as needed.

Head over to the documentation for the TeamCity Azure plugin and give it a try.

Happy building in the cloud!

Subscribe to TeamCity Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!