问如何提高团队的构建稳定性

EN

由于您已经收到了失败构建的通知，因此修复它们主要是人员问题。

您应该在团队成员之间达成一致，即一个失败的构建是一个严重的问题，需要在其他事情之前加以解决。

只要构建仍然是坏的，你就应该同意

• 任何工作都不能标记为已完成，除非可以证明所有提交都包括在上一次成功的构建中。
• 除非修复导致构建失败的问题，否则无法对主分支进行新的合并。

如果构建经常中断，那么您应该调查发生这种情况的原因以及可以采取的对策。

这里的一种可能是，在将功能分支合并到主分支之前，看看是否可以将功能分支构建在竹上的过程到位。或者更好的是，应该构建合并的预计结果。只有在此生成的分支/合并是绿色的情况下，才能完成实际的合并。

有几件事情我会更改为构建过程，因为越早发现问题，它们就越容易修复：

• 让构建运行对每个分支和拉请求。这包括特性分支，所有单元测试都应该针对该构建运行。
• 只对主分支保持长时间运行的功能测试。
• 防止合并拉请求，直到功能分支和拉请求都是绿色的。

最后一点非常方便，既可以防止中断的代码被合并，也可以迫使开发人员在合并之前处理中断。下一步的方法是由开发人员从主分支中提取，修复它们不同步的部分，然后创建一个新的拉请求。

我第一次使用这台自动化设备的时候是使用Github和Appveyor。在实际合并之前，了解合并是否会中断测试是很有用的。

如果仍然存在频繁的构建中断问题，可以查看以下内容：

• 这个问题是草率开发，还是您的代码体系结构脆弱？
• 也许会带来惩罚。上一家我为你工作的公司，如果你弄坏了建筑，就付给你1美元。这些钱花在了团队建设上，比如快乐时光之类的事情。
• 找到使代码在架构上具有弹性的方法。