TeamCity和IBM Rational Team Concert（RTC）集成

作为与Team Concert合作的IBM，我可以说RTC具有开箱即用的持续集成。您可能需要查看构建定义 - 调度选项卡 - 以启用它。     

我没有将TeamCity与RTC一起使用，但我们有一篇关于将外部构建系统（如Hudson）与RTC Build集成的文章： http://jazz.net/library/article/350/ 基本上，方法是让Hudson继续驱动构建，但使用RTC Build Ant任务来创建和填充与Hudson作业相对应的RTC构建结果。     

是的，Team City将使用RTC，您只需要在RTC中使用CLI启动的构建定义，或者从TeamCity端调用RTC scm。 没有特定的集成，因此如果您想要回复具有状态和结果的RTC，您将需要从ant访问buildtoolkit库。 我成功地使用了Team City，Hudson，Jazz Build Engine，Cruise Control和Build Forge以及RTC，我相信还有很多其他的，因为它们很容易被松散耦合连接起来。     

我们目前正在评估Team Concert，其中包括尝试在RTC和TeamCity之间进行自己的集成。 基本练习是您利用两个java API创建一个Version控件插件。您需要为团队城市实施少量功能;我们的原型大约有1000行来源。 最大的问题似乎是：TeamCity期望问题getCurrentVersion（）具有一致，稳定的答案，而流和工作空间似乎并非如此。目前，我们试图通过允许vcs root在必要时创建基线来解决这个问题，但是当您尝试使用存储库工作区时，这会产生一些不受欢迎的副作用（特别是 - 放置基线也会关闭（完成）任何开放的变更集.... 此外，RTC模型允许您在源系统中进行不连续跳转 - 当前同步到Baseline 20的工作空间可以重新用于基线25或基线15，这两者都不是该组件的先前历史记录的一部分。工作区。那么我们应该告诉团队城市应该“将其修补到当前版本”的答案应该是什么？ 有一个用于学习RTC Java API的wiki页面。 记录的一个方面，但无论如何设法让我感到惊讶的是，默认情况下，获取与存储库的连接的逻辑将为您提供共享连接。当开发人员尝试为自己的工作区创建VCS根时，这会弄得一团糟。有标志可以避免共享。