修复破碎夜间构建的政策

Question

我想每个人都同意，持续构建和持续集成有利于软件产品的质量。早期发现缺陷，因此可以尽快修复。对于需要几分钟的连续构建，通常很容易找到导致缺陷的构建者。但是，对于需要很长时间才能运行的夜间集成测试，这可能是一个挑战。以下是具体情况，我正在寻找最佳解决方案：

• 运行集成测试需要1个多小时。因此他们一夜之间运行。每天都会发生多次签到（大约15名开发人员的团队），因此有时很难找到“罪魁祸首”（如果有的话）。
• 集成测试环境取决于其他环境（Web服务和数据库），这些环境可能会不时失败。这会导致集成测试失败。

那么如何组织团队以便及早修复这些故障呢？在我看来，应该有人指定诊断缺陷。这应该是早上的第一项任务。如果他需要其他人的专业知识，他们应该随时可用。一旦确定了故障的源（组件，数据库，Web服务），所有者就应该开始修复它（或者应该通知另一个团队）。

如何指定诊断缺陷的人？理想情况下，有人会自愿（哈哈）。我担心这种情况不会经常发生。我听说过其他选择 - 无论谁先来到办公室，都应检查每晚构建的结果。如果整个团队都同意的话，这没关系。但是，这会奖励那些迟到的人。我想这个角色应该在团队中轮换。不应接受“我对构建知之甚少”的借口。故障源的诊断应该相当简单。如果不是，则向代码添加更多诊断日志记录应该可以提高对集成测试失败的可见性。

这方面的经验或改进上述方法的建议？

Answer 1

一项关于破坏夜间构建的着名政策，归功于微软，就是那个破坏构建的人负责维护夜间构建，直到有人破坏它为止。

这是有道理的，因为

• 每个人都会犯错误，因此必须进行必要的轮换（对于模棱两可的案例，使用最近最少使用的选择模式）
• 它鼓励人们编写更好的代码

Answer 2

我一般做什么（我为一个8到10人的团队做过）是两个有一个人来检查构建，这是他早上做的第一件事 - - 有人会说他负责质量保证，我想。

如果出现问题，他有责任找出/如何 - 当然，如果需要，他可以向团队其他成员寻求帮助。

这意味着团队中至少有一名成员必须对整个应用程序有很好的了解 - 但这无论如何都不是坏事：它有助于在应用程序在生产中使用的那天诊断出问题并受到影响失败。

而不是让一个的人这样做，我喜欢有两个人：一个一周一个，另一个一个星期 - 例如;通过这种方式，总有一个人可以诊断问题，即使其中一个人在假期，也有更大的机会。

作为旁注：在构建期间记录的内容越多有用，就越容易找出问题所在 - 以及原因。

为什么不让团队中的每个人每天早上检查一下这个版本？

• 嗯，不是每个人都想要，首先 - 如果那个人喜欢他做的话，那就更好了
• 你不希望10个人每天花半小时来^^

Answer 3

在你的情况下，我建议谁负责CM。如果那是负责太多的经理或技术负责人，为什么不把它交给初级开发人员呢？我希望有人在我的职业生涯早期强迫我更彻底地了解源控制。不仅如此，还要查看其他人的代码来追踪错误来源，这是一项真正的技能培养或知识学习练习。他们说你从看别人的代码中获得的收益最多，而且我坚信这一点。

Answer 4

与无经验的人一起经历

您可能需要考虑让对开发人员诊断出已损坏的版本。我好运。特别是如果您对熟悉构建系统的团队成员和对熟悉程度非常熟悉的团队成员进行配对。这可能会降低团队成员说“我对构建知之甚少”作为尝试退出职责的方式的可能性，并且会降低bus number并增加collective ownership。< / p>

让团队选择您指定的解决方案或自己制作的解决方案

您可以将问题提交给您的团队并要求他们提供解决方案。告诉他们，如果他们没有提出可行的解决方案，您将每周安排一次，每天分配一对，并确保每个人都有机会参与。

Answer 5

• 练习持续集成，这样您就不需要不经常的大型构建 **如果机器运行速度太慢，您可以在机器之间分配构建
• 使用构建状态监视器，以便任何检查过某些内容的人都可以对构建失败负责。
• 下午登记入住截止日期

或者：

• 下午5点之后没人办理登机手续

或

• 没有人在下午5点之后办理登机手续，除非他们准备继续工作，直到他们的建筑成为绿色 - 即使这意味着继续工作，提交修复并等待重建。

执行和遵守第一种形式要容易得多，所以这就是我要遵循的内容。

我的一个前团队的成员实际上被打电话告诉他们重新开始工作以修复构建......他们确实这样做了。

Answer 6

我很想建议用以下两种方式分拆：

• 时间分割 - 假设测试每晚运行两次，为什么不在两个不同的时间点对代码进行测试，即。所有办理登机手续的时间截至下午10点。然后是其余的，这样可以帮助缩小问题的范围。

• 团队拆分 - 可以将代码拆分成更小的部分，以便测试可以在不同的机器上运行，以帮助缩小哪些组应该深入挖掘内容吗？

这假设您可以多次运行测试并以这样的方式进行划分，因此这是一个粗略的想法。

Answer 7

我们每天早上都有一个站立会议，然后开始工作。清单上的一件事是每晚构建的状态。我们的构建系统在运行后会发送一封电子邮件，报告状态，因此很容易找到 - 因为它发生在一个人身上，但实际上它应该发给每个人，或者发布到项目维基上。 / p>

如果构建被破坏，那么修复它将成为一项优先级高的任务，可以像任何其他任务一样处理，这意味着我们将决定在哪个团队中开展工作，然后他们会去这样做。我们配对编程，通常将其视为配对任务。如果我们人手不足，我们可能会指派一个人来调查破损情况，然后再与他人配对以便稍后解决。

我们没有正式的任务分配机制：我们是一个小团队（通常是六个人），拥有集体代码所有权，所以我们只是在自己之间解决。如果我们认为一对特定的签到打破了构建，通常是他们修复它。如果没有，它可能是任何人;通常是通过看出谁目前还处于其他任务的中间来决定。