Any plans for a VMWare based / EC2 based TeamCity?

One of the biggest pains with TeamCity is making sure that all the agent machines are up; have the right versions of the software installed (JDK + Maven for example), ensuring builds don't hang and upgrading the JDK/mvn on each and every platform whenever - say - a mvn project now depends on a new 2.0.9 version of mvn etc.

I'm sure lots of folks are manually doing the same kinda thing with TeamCity. e.g. when mvn 2.0.9 comes out, we manually install it on each agent box. Ditto for JDKs etc.

What would be awesome - and I'm sure kinda popular - would be a way for TeamCity to basically control a bunch of VMWare images - which could be maintained centrally (e.g. latest JDK + latest mvn on windows / linux / solaris / aix).

i.e. we could share/reuse vmware images for most Java versions with most mvn versions and OSes to avoid having to manually do all this crap ourselves.

the next level of coolness would be an EC2 option.

So I could

host TC on EC2 if I wanted
(ii) get TC to kick off however many VMWare images are required on whatever platform to run whatever build/test/deploy

Often you want 1 build done on every checkin; but have nightly builds (say) on lots of platforms with loads of permutations of OS / JVM etc. So the EC2 cost could be quite cheap; running a load of images for an hour or so a night, with a couple of images on all the time for the checkin builds? You could even get the images to stop if there's been no checkins for an hour - or boot up loads of new images if there's loads of quick changes on a project that has a slow build etc

If TeamCity did a VMWare/EC2 hosted service to take all the maintenance pain away of keeping machines up & configured & available am sure we'd jump right on it and I'm sure others would to. All TC would have to do is control the EC2 images (or local VMWare images for folks with plenty of boxes). Preferably with a way of auto-upgrading JDK / mvn releaes too :)


Comment actions Permalink

Being able to manage tools versions in TeamCity would be a godsend... right now we're doing this by versioning the tools in svn and doing a checkout of a particular version for each build configuration (and of course, setting the appropriate env variables). This scheme kinda breaks down for large tools , like the JDKs. The managed VM instances (with tools already there) would be ideal but it would also be nice for TeamCity to have a managed tools section which would list tools/versions you can use in the build configs (i.e. mvn 2.0.8, 2.0.9, etc; java 1.5, 1.6, etc, ...). Then, in the build configs you could select say, a maven version from a drop down list...

The "virtual agent" idea is even cooler :) I would personally love to see an EC2 option for an agent... where EC2 instances would be spun up on-the-fly as needed. I guess you would need to have a AMI hosted somewhere with a build agent installed on it. Then, TeamCity could simply startup the AMI when a build is queued to it. When complete, the AMI could be shutdown... sounds somewhat easy :)

Comment actions Permalink

There is undocumented feature that could simplify installation of new tools on TeamCity agents. With help of this feature we distribute agent plugins on agent PCs. You can prepare a zip archive of your tool and put it in the webapps/ROOT/update/plugins folder. After that every agent will download this tool and unzip it to the plugins folder. You can then create paths to these tools with help of predefined properties: ${agent.home.dir}/plugins/ or %system.agent.home.dir%/plugins/]]>

If you choose to use this feature make sure that all files of your tool are stored in the single directory in zip archive and this directory is the single top level element in the archive (otherwise agent may start upgrading infinitely).

Pavel Sher

Comment actions Permalink

This might work for things like maven, ant, etc that are not platform specific but would still be nicer to managed from Teamcity itself so that the tools that were used for a build could be recorded with all the other build information.
Also, this would not work for something like JDK because these tools are platform specific so you would have to come up with a way to "push" tools to an agent depending on its OS, etc. Maybe you could have some variables defined in every agents config file that point to jdk1.5, jdk1.6, etc for each platform and that way you could define where each tool is on every agent. Then you could just select which jdk, maven, ant to use. And to take it one step further, you could even select 1.5 and 1.6 so the build would run against each version of the jdk for testing.


Comment actions Permalink

Just as a sidenote - we use the way pavel described with great success (we distribute cvs-nt, patched jdk's in different versions, patched ant's in different versions).
I don't see any problem with platform specific tools. Of course - they would be distributed to any agent regardless of the OS - but who cares ?
Compared to the disk space that is consumed by the actual builds this is negligible. And in the agent's plugin-dir even now are things that we never use (like ipr runner and all that other stuff).

I'd agree that than on each (agent-) platform you'd have to define a variable 'JDK15' pointing to the appropiate JDK say 1.5. Then you can use this variable in the build-configuration and builds will even run on different OS sorta finding their jdk by themselfes.

In the past the only thing that bothered us, was - when installing new agents - we had to do one manual step to define a cvs-nt password (since it is stored in windows-registry).
In the meantime our agents are running within vmware.
Agentinstall is than just a matter of copy-paste + rename agent name.
Even if the agent image is outdated - via the plugin mechanism it then autoupdates itself upon first connect to the team-city server.


Please sign in to leave a comment.