混乱与稳定发展是否构成矛盾？

我是一个拥有5个团队的开发团队的成员，该团队共有大约40个开发人员。我们遵循Scrum方法，并进行了3周的冲刺。我们有一个持续集成设置（Jenkins），其构建流程需要几个小时（由于进行了广泛的自动化测试）。基本上，开发过程运行良好。

但是，我们观察到进入新的Sprint几天后，我们的构建通常会变得不稳定，并且会一直不稳定，直到Sprint结束“提交停止”为止。这样做的不利影响是，构建步骤步入了管道，尤其是UI- / Webtest 几天没有执行（因为仅在“绿色”构建时触发）。因此，新引入的错误通常仅在冲刺的后期才检测到。

• 每个提交都通过一组基本测试进行验证。验证后，更改将在代码检查（德语）后推送至主版本
• 基本单元测试每30分钟运行一次，持续时间少于10分钟
• 集成测试每2h运行一次，持续时间1h
• UI / Webtest在成功的集成测试中运行，持续时间数小时

取决于谁在冲刺期间负责构建稳定性（每个冲刺都要移交责任），可能会有中间的临时“提交停止”以使构建恢复稳定。

因此，我们想要：

1. 我们的开发团队可以在不受阻碍的冲刺期间开发和提交更改
2. 如果构建步骤失败，我们将放弃构建过程，因为后续的构建结果意义不大
3. 我们的构建过程可为开发人员及时提供质量反馈

给定（2），点（1）和（3）似乎相互矛盾。有没有人有一个很好的做法来应对这个问题？

（我们目前正在松开要点（2），即使在失败的构建步骤中也允许继续构建。我还没有任何反馈意见，这如何影响我们的质量）

谢谢西蒙

首先要遵循几个基本原则：-重大更改应始终位于VCS中的功能分支上-功能分支在合并到主干之前应通过所有测试。已添加 -提交应该始终构建 -损坏的构建需要提交者和/或团队其他成员立即采取行动。-失败的测试仅在是关键测试时才应中止其余测试。

如果您作为一个团队，遵循这些实践并执行它们，例如：当构建被破坏时，执行“ name＆shame”，那么您应该很好，因为任何可能破坏构建的提交都将位于功能分支上。其他破坏构建的提交必须立即解决，然后您将获得下游测试结果。

您还可以为UI / Web测试添加最新的“成功”构建的自动测试（不一定是通过集成测试的构建），作为夜间运行的早晨报告第一件事。

与Scrum无关。无论如何，您的构建都应该持续稳定。

除非他们已经执行了本地构建并在本地运行单元测试（当然都通过了），否则任何人都不应检入任何东西。您本地的构建和测试过程应该对修改敏感，并且可以跳过未更改代码的测试。

任何引入导致构建失败或单元测试失败的事情的人都应该被公开羞辱。如果构建损坏，则必须立即修复。

您的问题似乎是测试需要太长时间才能运行。幸运的是，摩尔定律为我们提供了解决该问题的方法。如今，高端服务器CPU可能轻松拥有超过10个内核（和超过10个超线程）。一台计算机中可能有多个这样的CPU。

如果我进行的测试花费了这么长时间，那么我将使用更多的硬件来解决问题。我将购买一台高端服务器，然后并行进行测试，以便测试可以充分利用所有CPU内核。如果今天的测试是单线程的，那么利用10个内核和10个HyperThreds可能会使测试运行速度提高15倍。当然，这意味着它们还使用15倍的内存，因此计算机必须具有足够的RAM。

因此，几个小时将变成10-30分钟。

您没有说构建需要花费多少时间，但是标准的构建工具（如make）允许并行化构建。如果并行进行单元测试，并且典型的开发人员计算机具有4个核心和4个HyperThreads，则少于10分钟的单元测试将变成少于2分钟。因此，也许您可​​以实施一项政策，即每个人都应在提交之前运行单元测试？

关于测试失败，停止进一步的测试：不要在构建服务器上这样做！您需要有关故障的尽可能多的信息，进一步的测试可能会发现重要的内容。当然，如果构建本身失败，则无法运行单元测试。如果开发人员在自己的计算机上运行单元测试，则您可能希望在第一次失败时中止。

我看不到Scrum与您的问题之间有任何联系。这些问题实际上可能发生在任何开发过程中。

是否不可能有更多的Jenkins安装并让开发人员检查单独的Jenkins实例？

我认为最好的解决方案是让代码在进入主分支并由主要Jenkins实例编译/测试之前，先通过所有测试。不要让人们签入破坏版本的代码。

我将代码检入development分支，查看其是否通过测试并创建请求请求。但是您显然可以让詹金斯拉出一个功能分支并对其进行测试。

要点（2）似乎是最痛苦的一点，因此我将重点介绍这一点。

现在可能是将项目分为多个模块的时候了。

https://zh.wikipedia.org/wiki/Dependency_inversion_principle

答：高级模块不应依赖于低级模块。两者都应依赖抽象。

B.抽象不应依赖细节。细节应取决于抽象。

如果一个模块无法构建，则其他模块的构建将能够继续，只要其他模块可以依赖于接口，并且构成该接口的代码就可以成功构建。

这将为您提供有关可能发生的其他构建失败的反馈，以便您有时间在下一个构建发生之前修复多个损坏的模块。

通常，SOLID原则旨在处理库和构建问题。换句话说-这套原则旨在解决您面临的确切问题。

作为旁注（请参阅juhist的答案），如果不将构建划分到单独的模块中，则无法使构建运行更快（通过并行化）。

我认为您的团队缺少了Scrum的关键原则之一：完成工作的软件。在通过您的团队确定的“完成定义”之前，不应将PBI标记为已完成。每个团队对“完成”的定义都不相同，但可能包括以下内容：

• 代码具有单元测试
• 单元测试通过作为自动化构建的一部分
• 代码已合并为主要代码（并且冲突已解决）
• 等等

因此，从本质上讲，正在发生的事情是您的团队正在标记实际上是未完成的工作。本身就是一个问题。

除此之外，它归结为适当的版本控制管理。如果您使用的是Git，则所有工作都在开发人员的本地存储库中完成，除非将其“完成”并且可能发布，否则他们不应将任何内容推送到远程。不完整的工作永远都不应推送到您的主存储库。如果开发人员需要使用寿命更长的功能分支，并希望推送到远程以确保他们不会丢失工作，那么他们应该使用分叉，然后您可以将该分叉合并到主分支中该功能已“完成”并且可能会发布-并非之前。

对于TFVC，它稍微复杂一些，因为一切都发生在“远程”上。这意味着开发人员因此应该始终在分支机构之外工作，除非是快速解决方案。但是，此处适用与Git相同的规则：不完整的软件不会被提交。期。在正确管理的版本控制中，“ main”应始终是可释放的。如果已经提交了一个使“主要”失败的提交，那么您就做错了。