Roy Osherove did a great post on how to run Teamcity in the Cloud. You can find this post here. A while ago I did the same with LieberLieber, a Software Company from Vienna famous for their Product Amuse. The goal was to give additional flexibility to their build process. They use Teamcity for their Build Process and we the problem is that they sometimes need more computing power if they have a peek in projects. So we looked at the possibility of hosting additional Agents in the Cloud. Their Servers are still on-premise, but now additional Servers are in the Cloud for their Build process – and that’s on demand. They start a new Server once they have too much Build processes in the queue.
Roy and TeamCity as well provide a really great How-To on implementing this task. However, we discovered some minor problems. All TeamCity Installations for LieberLieber are Windows Servers as their projects are .NET Projects. We configured everything as described in the blogs, however, the Windows Firewall didn’t allow connections over Port 9090 – which is essential for TeamCity. If you configure TeamCity on Windows, make sure you add this Rule to the Windows Firewall:

After this was done, we could move on with the TeamCity build. For this first step we used the Windows Micro Instance at Amazon EC2. In the Screenshot below you can see that the Agent is up&running  .

Another Problem is the combination On-Premise <> Amazon EC2. The Build takes very long as the Agent needs to get the data from the Repository – which is On-Premise. In order to improove Performance, the Repository itself should be in the same Availability Zone as the Agent(s) and the TeamCity Installation. To compare the Performance of the Build Process, we told TeamCity not to Cleanup after a Build. This means that the Agent loads the Sources only when new Sources are available.

Once we could run the build at -almost- the same conditions, we were able to see the performance of the micro instance – and this was very impressive:

ip-0AE4F5A7 is the Amazon EC2 Server with the TeamCity Agent on it. As you can see, the Agent running in the Cloud was faster. Of course, this is just one run. To get a good comparision more runs need to be done. But imagine one thing: it is only 0,35$ per Day – the Agent needs to be available for 10 Hours per day. If more machines are required, it is absolutely possible to start more machines.