Introducing TeamCity Azure plugin – Run builds in the cloud

Microsoft AzureIn 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.

Plugins List

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.
    Visual Studio MSDN image on Azure
  • 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.

Create an Azure cloud profile

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.

Run TeamCity agent in Azure

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.

TeamCity agent running in Azure

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

Happy building in the cloud!

This entry was posted in Features, FYI, How-To's, News & Events, Tips&Tricks and tagged , , , , . Bookmark the permalink.

16 Responses to Introducing TeamCity Azure plugin – Run builds in the cloud

  1. eric hexter says:

    this looks really nice. the one recommendation would be to support multiple subscriptions, this way we could use all of the msdn subscriptions to run agents. rather then a single subscription which means we cannot take advantage of the msdn credits for dev&test

  2. Pingback: An autoscaling build farm using TeamCity and Windows Azure

  3. Pingback: Microsoft Azure cloud plugin for TeamCity (dabbling in Java code)

  4. George says:

    That’s really neat. How does agent licensing work with this? Do you need a license for each concurrently connected azure agent, or for the max number of agents you can configure?

    • Pavel Sher says:

      Nothing changes with licensing so far. Number of licenses should correspond to max number of agents you plan to connect to the machine.

      • Johan Aftonstråle says:

        Then what is the purpose of this set-up? If we still need to pay for the maximum number of agents, then we can as well have these running all the time and we do not even need to do it in the cloud, we can keep our environment locally as before. I do not see any benefits of paying for agents turned off?

        • Terje says:

          You can reduce the cost of running the build agents though. We have no need to run build agents outside of work hours and can therefore have TeamCity automatically turn off the build agents.
          Cost savings will be in virtual machine uptime, not in licensing cost.

          (Of course, if you have the local environment to support your needs you have probably already invested in servers to support your needs)

  5. Jeff Key says:

    We’ve been waiting for this…and it’s worked perfectly so far. Well done, and thanks!

  6. joseph says:

    Billing in Amazon EC2 will be based on number of agents used? Meaning, depending on teamcity load?

  7. Pingback: TeamCity VMware vSphere plugin | JetBrains TeamCity Blog

  8. Keith Patton says:

    Really great thanks. However a couple of feature requests:

    we would like the option to be able to enable the cloud integration such that users can manually start and stop the servers from within team city. Currently, if enabled they auto scale. As servers cost money, this option would be nice to simply offer azure vm managment easily.

    Secondly, the scaling is automaticaly when more than 1 build is in the queue. If builds are quicker than the time it takes to fire up a usable VM (which isn’t that unusual) then the server gets spun up unnecessarily. We would like to able to define a time period to wait before scaling when the build queue total changes. This allows a delay and will avoid unnecessary costs.

    Other than that, thanks!

  9. Pingback: Team City with Azure Virtual Machines | Marker Metro

Comments are closed.