Integration With Amazon EC2 Cloud
Brief Description
In a large infrastructure with many projects, the 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 growths, increased build times, and poor build scheduling control.
With version 5.0, 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 growths is exactly what happens in TeamCity 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.
Starting To Work With Amazon EC2
Creating Amazon EC2 Virtual Build Agent
First, you create one or more Amazon EC2 machine images (AMIs) and install a standard TeamCity build agent on them. There are several things you should remember when setting up a virtual agent AMI:
- A TeamCity agent should be correctly installed;
- A TeamCity agent should start on machine startup;
- buildAgent.properties can be left as is. "serverUrl," "name" and "authorizationToken" properties can be empty or set to any value - they are ignored when TeamCity starts the instance.
Registering created AMI within TeamCity
The next step is to notify TeamCity of your newly created image. This is done from the Server Configuration page, under the Cloud tab. 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.
Working with virtual build agents
Once an image is configured, TeamCity starts a probing instance to make sure that the agent is properly installed, and to discover the machine environment.
After the image is probed, each time there is a build waiting in the queue and the virtual agent can run it based on the requirements, the virtual agent is started and automatically attached to the TeamCity server. After that, virtual agent acts as a regular agent.
You can also start and stop virtual agents manually.
