及时修复夜间构建有多重要？
我们有一个自动构建服务器，可以每晚构建我们的代码，这对我们很有用，因为并不是我们团队中的每个人都可以构建整个源代码树。最近，团队中的一些成员对于及时修复构建错误变得更加松懈；有时几周过去了仍没有成功构建。我什至无意中听到一位开发人员说：“构建已经损坏，现在是添加[一些重大更改]的好时机。”由于我处理最下游的代码，因此我通常处理树中与源代码存储库严重不同步的部分，这使得在提交更改之前测试更改非常困难。
我觉得我们正在失去夜间构建的大部分好处，因为它不断被破坏。我在这里是否偏离了基地，还是应该更优先考虑修复构建？
We have an automated build server that builds our code nightly, which is useful for us since not everyone on our team can build the entire source tree. Lately, some members of the team are becoming more lax about fixing build errors promptly; sometimes weeks will go by without a successful build. I even overheard one developer say, "the build is already broken, now is a good time to add [some breaking change]." Since I work on the the code the furthest downstream, I am usually working with parts of the tree that are woefully out of sync with the source code repository, which makes it very difficult to test changes before I submit them.
I feel like we're losing most of the benefit of having a nightly build since it is continually broken. Am I way off base here, or should fixing the build be a higher priority?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
修复夜间构建应该是最高优先级。正如你所说，如果它们坏了，它们就没有价值。如果人们希望签入导致损坏的代码，他们应该在分支上执行此操作，并且仅在测试时将其合并。
Fixing the nightly build should be the highest priority. As you said, if they are broken, they have no value. If people wish to check in code that causes breakage, they should do this on a branch and only merge it in when it is tested.
这些开发人员显然需要恢复原状。
我建议每天至少构建几次，如果不是在签到时的话。一旦你再次成功地进行构建周期，就可以（以开玩笑的方式）攻击破坏构建的人 - 当它发生时。
每个人都需要拥有代码库并承担责任。
老实说，这也是对自己的手艺感到自豪的原因。如果最终人们不在乎构建是否被破坏，并且在被要求解决问题后也不在乎，那么听起来他们最好还是去做其他工作。
Those devs clearly need to be kicked back into shape.
I'd suggest building at least a few times daily, if not upon checkins. And once you got a successful build cycle going again, have a go (in a joking way) at the person who broke the build - when it happens.
Everyone needs to take ownership of the codebase and take responsibility.
To be honest, it also is about having some pride in your craft. If ultimately people don't give a damn if the build is broken, and they don't after being asked to sort it out, it sounds they'd be better off doing some other job.
你拖延修复的时间越长，修复所需的时间就越长。
如果立即修好，导致其损坏的事情应该在每个人的脑海中都更清晰。重大变更也可能会堆积起来，使得以后修复起来更加令人头疼。
The longer you put off fixing it, the longer it will take to fix.
If it's fixed immediately, the things that cause it to be broken should be fresher in everyone's head. Breaking changes could also be piling up making it that much more of a headache to fix later.
解决这个问题至关重要。你拖延的时间越长，你以后发现的东西就越多。如果人们不从干净的构建开始，如何判断他们的更改是否破坏了构建？
我们的标准是在提交后让所有单元和功能测试在中立集成盒上运行“绿色”。当然，测试驱动开发适合我们的情况，但可能不适合您的情况。如果您甚至无法构建该项目，则之前的提交中可能潜藏着糟糕的意外情况。
如果它太大以至于构建它所需的时间阻碍了修复它，那么将其分解为较小的项目和持续集成等技术可能会有所帮助。
It's critical to get it fixed. The longer you put it off, the more things you're going to find later. How can someone tell if their changes have broken the build, if they don't start with a clean build?
Our standard is to have all our unit and functional tests run "green" on a neutral integration box after a commit. Of course, test-driven development is appropriate to our situation, but may not fit yours. If you're not even able to build the project, there are probably bad surprises lurking in previous commits.
If it's so big that the time it takes to build it is standing in the way of getting it fixed, techniques like breaking it up into smaller projects and continuous integration may help.
我的一位朋友告诉我，他的团队拥有《Zucchini of Doom》。任何打破夜间构建的人都必须在办公桌上展示 ZoD。这种蔬菜已经处于相当严重的腐烂状态，这清楚地传达了这样的信息：破坏的构建是不能容忍的。
如果团队没有足够的动力来保持夜间睡眠，那么经理应该强制/鼓励这一点。
A friend of mine told me about his team that had the Zucchini of Doom. Anyone breaking the nightly build had to display the ZoD on their desk. This vegetable was in a fairly advanced state of decomposition, which sent out the message quite clearly that a broken build was not something to be tolerated.
If the team isn't motivated enough to keep the nightlies building then this is something that should be enforced/encouraged by the managers.