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

Question

一段时间以来，我的公司正在使用 Maven 和 TeamCity 来构建 Java 东西。目前，我们在持续集成和最终的持续交付方面投入了大量资金。

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

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

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

这样做的好处是：只有在步骤 1 的更改成功构建的情况下，才会构建步骤 2。

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

我们尝试的替代方案：

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

有谁知道更好的方法如何更好地设置它？

多谢， 斯特凡

Answer 1

我们现在确实使用了快照依赖项一周，除了它们效率低下之外，我已经开始喜欢它们了。

TeamCity 确实显示了构建上的依赖问题，并且有一个专门针对 构建链 的文档页面告诉我们这正是解决此类问题的方式。

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

Answer 2

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

部署到 Nexus 是一个瓶颈，因为它需要 10 到 20 分钟（取决于网络和 Nexus），而其余步骤总共也需要 10 分钟。我注意到我们对 Nexus 的部署超出了持续集成所需的范围：不仅是 Maven 工件，还有可交付成果，例如 rpm 或 wars。可能一半的部署时间就是因为这个。

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

但我不确定这是否是在 Maven 或 TeamCity 中执行此类操作的最佳方法。我仍然希望有其他解决方案或想法。