及时修复夜间建筑有多重要？

Question

我们有一个自动构建服务器，每晚构建我们的代码，这对我们很有用，因为我们团队中的每个人都不能构建整个源代码树。最近，团队中的一些成员对于及时修复构建错误变得越来越松懈;有时几周没有成功的建设。我甚至无意中听到一位开发人员说，“构建已经破坏，现在是添加[一些突破性变化]的好时机。”由于我处理最下游的代码，我通常使用与源代码库非常不同步的树的部分，这使得在提交之前测试更改非常困难。

我觉得我们失去了每晚建造的大部分好处，因为它不断被打破。我是不是在这里离开基地，还是应该更好地修复构建？

Answer 1

修复夜间构建应该是最高优先级。正如你所说，如果它们被打破，它们没有任何价值。如果人们希望检查导致破坏的代码，他们应该在分支上执行此操作，并且仅在测试时将其合并。

Answer 2

这些开发者显然需要重新成形。

如果没有签到，我建议每天至少建造几次。一旦你有一个成功的构建周期再次进行，就可以去打破构建的那个人（以一种开玩笑的方式） - 当它发生时。

每个人都需要拥有代码库的所有权并承担责任。

说实话，它也是为你的手艺感到自豪。如果最终人们在构建被破坏时不会给出一个该死的，并且在被要求排除之后他们没有这么做，这听起来他们做其他工作会更好。

Answer 3

修理它的时间越长，修复所需的时间就越长 如果它立即被修复，那么导致它被打破的东西应该更加清新。突破性的变化也可能会使人们更加难以理解，以后再进行修复。

Answer 4

解决这个问题至关重要。你把它推迟的时间越长，你以后会发现的东西越多。如果他们不是以干净的构建开始的话，怎么能告诉他们他们的更改是否破坏了构建？

我们的标准是在提交后将所有单元和功能测试在中性集成框上运行“绿色”。当然，测试驱动开发适合我们的情况，但可能不适合您。如果你甚至无法构建项目，那么在之前的提交中可能存在潜在的意外情况。

如果它太大以至于构建它所花费的时间阻碍了它的修复，那么将它分解成更小的项目和持续集成的技术可能会有所帮助。

Answer 5

我的一位朋友告诉我他的团队有 Zucchini of Doom。任何打破夜间建筑的人都必须在桌面上展示ZoD。这种蔬菜处于相当高级的分解状态，它清楚地发出了一个信息，即破碎的构造不是可以容忍的。

如果团队没有足够的动力来保持夜间建设，那么管理者应该强制/鼓励这一点。