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

Question

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

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

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

• 第1步:编译所有内容(5分钟)，如果失败，中止链。触发基于SVN更改的构建。
• 步骤2:编译、验证和部署。(20到40分钟，主要取决于Nexus和/或网络性能)定义快照依赖于步骤。触发SVN上的构建更改，但只有在快照依赖项已更改时才触发。

这方面的好处是:步骤2只有在步骤1的更改成功的情况下才会生成。

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

我们尝试过的替代方案：

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

有没有人知道一个更好的方法，如何更好地设置这个？

非常感谢，斯特凡

Answer 1

我们现在有一个星期的快照依赖关系，除了它们的低效之外，我已经开始喜欢它们了。

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

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

Answer 2

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

部署到Nexus是一个瓶颈，因为它需要10到20分钟(取决于网络和Nexus)，而其余的步骤也是10分钟。我注意到，我们向Nexus部署的不仅仅是持续集成所必需的:不仅是Maven工件，还有可交付的，比如rpms或wars。可能一半的部署时间就是因为这个原因。

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

但我不确定这是否是在Maven或TeamCity中进行此类工作的最佳方式。不过，我还是希望有其他的解决办法或想法。