我在一家使用持续集成（TeamCity）的公司工作。每当有人进行代码提交时，CI软件就会启动构建并运行所有单元/自动化测试。问题在于，我们有超过7000个单元测试和756个自动化测试（用于测试JavaScript，因为我们有非常复杂的UI逻辑来进行计算等）。正如你所想象的那样，每次有人提交代码，整个过程需要超过2小时才能完成所有步骤（构建-单元测试-自动化测试），因此我需要等待这么长时间才能得到结果，以了解我的提交是否破坏了自动化测试或单元测试。最糟糕的情况是当多个人同时提交代码时，TeamCity开始排队构建，而在我能够获得有效结果之前，我可能需要等待半天！我们应该采取什么策略来加快这个过程？是否最佳实践是针对即使是小变更也运行所有自动化测试？
4个回答
3
我建议你将测试套件分为两部分，以便你和你的团队可以提交代码后喝杯咖啡，回到桌子前收到来自Team City的有意义的反馈。
1. 确定每次提交需要测试的内容，并将其余测试移动到定期运行的测试套件中（每小时、每晚等）。 2. 如果每次提交所需运行的测试集仍然很大，请将该集合拆分并在多个节点上并行运行。
另外，根据你的项目性质，你可能还需要加强CI机器。你可以将测试工作目录放在tmpfs（RAM磁盘）中。
1. 确定每次提交需要测试的内容，并将其余测试移动到定期运行的测试套件中（每小时、每晚等）。 2. 如果每次提交所需运行的测试集仍然很大，请将该集合拆分并在多个节点上并行运行。
另外，根据你的项目性质，你可能还需要加强CI机器。你可以将测试工作目录放在tmpfs（RAM磁盘）中。
- thekbb
1
我将从理论上讲解，虽然还未付诸实践，但CI是我在今年夏天末之前设定的目标。
根据那些在开发人员中赢得我最高尊重的人所做出的陈述，我最常见到的关于测试策略的CI元素是将测试分为长时间运行和短时间运行。
接着，您需要配置标准的检查点，以启动短期运行测试来进行解决方案的基本验证。 然后，在每晚的构建和部署构建时是您唯一需要运行完整测试套件来进行回归测试验证的时间。
另外一个答案是：由于我自己还没有为自己设置CI，所以我从来没有理解过TeamCity的商业模式，即他们基于构建代理进行定价。现在我明白了，如果您的测试套件需要很长时间，那么多个构建代理确实开始变得更加重要，能够同时运行5个构建变得更加重要。因此，一种选择可能是暂时花更多的钱并在弹孔上贴上创可贴。
- Chris Marisic
0
- Dennis Traub
3
我认为他们不太愿意更改他们目前使用的P4V源代码版本控制 :-(
还有其他建议吗？
无论如何，对于这个想法加1。 - Massimiliano Peluso
2虽然你的陈述是正确的，但Massimiliano所遇到的痛点仍然会在他想要推送到主代码库时显现出来。虽然分布式版本控制系统可能会让他的开发体验更好，因为他可以本地检查而不必等待提交，但这并不能以任何形式缓解OP的问题。 - Chris Marisic
@Massimiliano，虽然听起来很奇怪，但如果您想在提交到P4V CVS之间对您的工作进行版本控制，您可以在本地使用Mercurial或Git而无需更改解决方案，因为它们完全基于文件系统工作。只需确保在解决方案根文件夹的上一级文件夹中创建存储库，以防止意外添加文件到解决方案中。 - Chris Marisic
0
你考虑过使用预先测试的提交吗？如果你运行一个远程构建（没有提交到版本控制系统），你可以确信你没有在版本控制系统中破坏任何东西（只是因为你还没有提交）。而且你可以继续工作而不会出现问题。如果构建成功，你可以提交你的更改（即使你在同一文件中进行了其他更改）- 如果你通过TeamCity的插件提交，它将精确地提交你发送到服务器进行测试的代码。
这样，你就不必等待TeamCity的构建完成才能继续使用它。
免责声明：我是TeamCity开发人员。
- KIR
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接