使用TeamCity为大型项目设置持续集成构建链的首选方法是什么？

Question

有一段时间我的公司正在使用Maven和TeamCity来构建Java。目前，我们在持续整合和最终持续交付方面进行了大量投资。

在许多较小的应用程序（应用程序）中，我们正在运行一个大型的整体应用程序。 100万LOC。相当大的构建代理上的这个应用程序需要5分钟编译（包括2分钟svn）。它的12k单元测试再运行5分钟。将构建结果部署到Nexus至少需要10分钟。

为了向开发人员提供快速反馈，我们尝试分割在不同构建任务中要完成的工作量。目前我们正在使用以下设置：

• 步骤1：编译所有内容（5分钟），如果失败，则中止链。触发SVN更改的构建。
• 第2步：编译，验证和部署。 （20到40分钟，主要取决于Nexus和/或网络性能）定义与Step的快照依赖关系。触发SVN更改的构建，但仅限于快照依赖性已更改。

关于此的好处：第2步仅在成功构建且步骤1更改时才构建。

这种方法存在一个主要缺点：步骤2完成了步骤1的所有操作。如果我将步骤3和浏览器级别的Selenium测试部署到测试系统中，那么很多事情将被执行两次或三次。

我们尝试过的替代方案：

• 将步骤2配置为与步骤1在同一构建代理上运行，但无论如何都要完成svn，因此这里没有优势。只有更好的东西：Maven缓存。
• TeamCity构建步骤。据我所知，他们几乎没有任何优势来分离构建任务与缺乏中间构建结果的缺点。

有没有人知道如何更好地设置它？

非常感谢， 斯蒂芬

Answer 1

我们现在做了一个星期的快照依赖，我已经成长为喜欢它们，除了它们的效率低下。

TeamCity确实在构建中显示依赖性问题，并且有一个专门用于Build Chains的文档页面，告诉我这就是解决这些问题的方法。

感谢那些对这个问题感兴趣的人。我现在要关闭它。

Answer 2

我想分享自己的可能性，虽然我不确定是否应该这样做。目标仍然是缩短反馈周期：

部署到Nexus是一个瓶颈，因为它需要10到20分钟（取决于网络和Nexus），而其余步骤也是10分钟。我注意到我们正在为Nexus部署超过持续集成所需的内容：不仅是Maven工件，还有可交付成果，例如rpms或wars。可能是部署时间的一半只是因为这个原因。

我们可以设置第三步“第3步：构建可交付成果”。这可以基于该问题的自己的POM，以避免一切都被编译和测试。此POM将对第二步中创建的Maven工件具有快照依赖性。

但我不确定这是否是在Maven或TeamCity中做这些事情的最佳方式。我仍然希望有其他解决方案或想法。