我们有一个自动构建服务器，每晚构建我们的代码，这对我们很有用，因为不是我们团队中的每个人都可以构建整个源代码树。最近，团队中的一些成员在及时修复构建错误方面变得更加松懈；有时几周会过去而没有成功的构建。我什至无意中听到一位开发人员说，“构建已经损坏，现在是添加 [一些重大更改] 的好时机。” 由于我在最下游处理代码，因此我通常使用与源代码存储库严重不同步的部分树，这使得在提交更改之前很难测试更改。
我觉得我们正在失去夜间构建的大部分好处，因为它不断被破坏。我是否在这里偏离了基础，或者修复构建是否应该是更高的优先级？
修复夜间构建应该是最高优先级。正如你所说，如果它们坏了，它们就没有价值。如果人们希望签入导致损坏的代码，他们应该在分支上执行此操作，并且仅在测试时将其合并。
这些开发人员显然需要恢复原状。
我建议每天至少建造几次，如果不是在签到时。一旦您再次成功地进行构建周期，请（以开玩笑的方式）对破坏构建的人进行尝试-当它发生时。
每个人都需要拥有代码库的所有权并承担责任。
老实说，这也是对你的手艺有一些自豪感。如果最终人们不在乎构建是否损坏，并且在被要求对其进行整理后也不在乎，那么听起来他们最好做其他工作。
你拖延修复它的时间越长，修复它需要的时间就越长。
如果马上修好，那么导致它坏掉的东西应该在每个人的脑海中都会更加新鲜。突破性的变化也可能堆积起来，使得以后修复它更加令人头疼。
修复它至关重要。你拖延的时间越长，你以后会发现的东西就越多。如果他们没有从干净的构建开始，如何判断他们的更改是否破坏了构建？
我们的标准是在提交后让我们所有的单元和功能测试在中立的集成盒上“绿色”运行。当然，测试驱动开发适合我们的情况，但可能不适合您的情况。如果您甚至无法构建项目，则可能在之前的提交中潜伏着不好的惊喜。
如果它太大以至于构建它所花费的时间阻碍了它的修复，那么将它分解为更小的项目和持续集成等技术可能会有所帮助。
我的一个朋友告诉我他的团队拥有毁灭战士的西葫芦。 任何破坏夜间构建的人都必须在他们的桌子上展示 ZoD。这种植物处于相当高级的分解状态，它非常清楚地发出了信息，即破坏的构建是不能容忍的。
如果团队没有足够的动力来保持夜间建设，那么这是经理应该强制/鼓励的事情。