Free for small team

Amazon EC2 Integration

In a large infrastructure with many projects, your CI server often experiences variable task loads with unpredictable load peaks (such as during releases). In an environment with fixed resources, this leads to build queue growth, increased build times, and poor build scheduling control.

TeamCity raises scalability to a new level, by integrating with Amazon Elastic Cloud (EC2). Computing clouds such as Amazon EC2 provide a nice and efficient way to scale resources to fulfill variable demands with random load spikes. Such rapid demand growth is exactly what happens during CI "rush hours," when everyone starts personal builds before going home, and also during pre-release days, when every new fix needs another round of unit tests, and build feedback time becomes mission-critical.

TeamCity utilizes EC2 via virtual build agents. Virtual build agents are similar to standard ones, except that they run on virtual instances on the Amazon EC2. This means that TeamCity is able to dynamically start as many instances of such agents as needed, in order to keep the build queue under control under high loads. Additionally, TeamCity can shut down virtual build agents when they are not needed anymore, to minimize EC2 instances uptime.

While being a great solution for mitigating peak loads and maintaining constant build feedback time, Amazon EC2 integration also provides great cost optimization opportunities, as each resource accumulates costs only while in use.

Amazon EC2 and TeamCity

To start using Amazon EC2 virtual build agents in TeamCity you should only perform a few steps.

  1. Create Amazon EC2 virtual build agent
    First, create one or more Amazon EC2 machine images (AMIs) and install a standard TeamCity build agent on them.
    Refer to TeamCity documentation to learn how to prepare AMI with TeamCity build agent installed.
  2. Register created AMIs within TeamCity


    Now, when you have AMIs ready to act as TeamCity build agents, next step is to notify TeamCity of your newly created image. This is done in the Administration area, at the Agent Cloud page. You can also set the maximum number of instances that can be started from the attached image, and define the idle time after which instances will be shut down by TeamCity.
  3. Use Amazon EC2 virtual agent as regular build agent


    Once you have created a cloud profile in TeamCity with one or several images, TeamCity does a test start for all the new images to discover the environment of the build agents configured on them. If for a queued build there are no regular non-cloud agents available, TeamCity will find a matching cloud image with a compatible agent and start a new instance for the image. After that, a virtual agent acts as a regular agent.
    You can specify idle time on the agent cloud profile, after which the instance should be terminated or stopped, in case you have an EBS-based instance.