TeamCity and IBM Rational Team Concert (RTC) Integration

Has anyone used Tea开发者_如何学编程mCity with Rational Team Concert (RTC) ? Is there any other continous integration for RTC?

As an IBM who works with Team Concert, I can say RTC has continuous integration built in out of the box. You might want to check out the build definitions - scheduling tab - to enable it.

I have not used TeamCity with RTC, but we have an article on integrating external build systems like Hudson with RTC Build: http://jazz.net/library/article/350/ Basically the approach is to let Hudson continue to drive the builds, but use the RTC Build Ant tasks to create and populate an RTC build result corresponding to the Hudson job.

Yes, Team City will work with RTC you just need to use either a CLI initiated Build Definition in RTC or call RTC scm from the TeamCity side.

There is no specific integration so if you want to contribute back to RTC with status and results you will need to access the buildtoolkit libs from ant.

I have used, Team City, Hudson, Jazz Build Engine, Cruise Control, and Build Forge with RTC successfully and I am sure there are many others since it is pretty simple to get them hooked up in a loose coupling.

We're currently evaluating Team Concert, and that includes trying to roll our own integration between RTC and TeamCity.

Basic drill is that you take advantage of the two java APIs to create a Version control plugin. There's a small handful of functions that you need to implement for team city; our prototype is about 1000 lines of source, total.

The biggest problem appears to be this: that TeamCity expects the question getCurrentVersion() to have a consistent, stable answer, and that doesn't seem to be true of streams and workspaces. For the moment, we're trying to work around that by allowing the vcs root to create baselines where necessary, but this has some unwelcome side effects when you are trying to work with a repository workspace (in particular - placing a baseline also closes (completes) any open change sets....

Also, the RTC model allows you do make discontinuous jumps in the source system - a workspace currently synced to Baseline 20 can be re-purposed to baseline 25, or baseline 15, neither of which are part of the prior history of that component in that workspace. So what should we tell team city the answer to "patch this to the current version" should be?

There's a wiki page for learning the RTC Java API.

One aspect that is documented, but managed to catch me by surprise anyway, is that the logic for obtaining a connection to the repository will, by default, hand you a shared connection. This makes a mess when you have developers trying to create VCS roots for their own workspace. There are flags available to avoid the sharing.