修复损坏的夜间构建的政策[关闭]答案

【问题标题】：Policy for fixing broken nightly builds [closed]修复损坏的夜间构建的政策[关闭]
【发布时间】：2009-12-22 15:02:00
【问题描述】：

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

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

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

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

在这方面有什么经验或对上述方法的改进建议吗？

【问题讨论】：

即使集成测试需要一个多小时，也值得在白天和晚上运行它 - 例行程序是每次签入都会启动构建，除非已经运行（它通常会是）。这可以为您提供更快、更准确的反馈。如果你真的很热衷，你可以将 CI 系统设置为在每次构建失败后开始一分为二，它会回溯以准确找到哪个签入破坏了构建。事实上，这对于只在夜间进行的例行程序也很有用。

标签： continuous-integration diagnostics

【解决方案1】：

归因于 Microsoft 的关于破坏夜间构建的著名政策是，提交破坏构建的人将负责维护夜间构建，直到其他人破坏它为止。

这是有道理的，因为

每个人都会犯错，因此会发生必要的轮换（使用最近最少使用的选择模式来处理模棱两可的情况）
它鼓励人们编写更好的代码

【讨论】：

【解决方案2】：

我通常做的（我已经为一个 8 到 10 人的团队做过） 是两个有一个人检查构建，作为他早上做的第一件事 - - 有人会说他负责质量检查，我想。

如果出现问题，他负责找出问题所在/如何进行 - 当然，如果需要，他可以向团队的其他成员寻求帮助。

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

而不是让一个人来做这件事，我喜欢有两个人：一个人一个星期，另一个人第二周——例如；这样一来，即使其中一个人在假期，也更有可能始终有人可以诊断问题。

作为旁注：您在构建过程中记录的有用内容越多，就越容易找出问题所在——以及原因。

为什么不让团队中的每个人每天早上检查构建？

嗯，首先，不是每个人都想这样做 - 如果这样做的人喜欢他所做的事情，那将会做得更好
而且你不希望 10 个人每天花半小时在那上面 ^^

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

有经验与无经验的配对

您可能需要考虑让对位开发人员诊断损坏的构建。我很幸运。特别是如果您将对构建系统不太熟悉的团队成员与非常熟悉的团队成员配对。这可能会减少团队成员说“我对构建不太了解”作为试图摆脱职责的一种方式的可能性，它会减少您的 bus number 并增加 collective ownership。

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

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

【讨论】：

【解决方案5】：

练习持续集成，这样您就不需要频繁的大型构建 ** 如果对一台机器来说速度太慢，您可以在机器之间分发构建
使用构建状态监控器，这样任何签入的人都可以对构建失败负责。
有一个下午入住截止日期

要么：

下午 5 点后无人签到

或

没有人在下午 5 点之后签到，除非他们准备好继续工作直到他们的构建通过绿色 - 即使这意味着工作、提交修复并等待重建。

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

我的一个前团队的成员实际上接到了电话，并被告知要回去工作以修复构建......他们确实做到了。

【讨论】：

【解决方案6】：

我很想建议以两种方式中的任何一种来拆分：

时间分割 - 假设测试可以每晚运行两次，为什么不在 2 个不同的时间点针对代码运行测试，即下午 X 点之前的所有签到。然后是其余部分，这样可以帮助缩小问题所在。
团队拆分 - 能否将代码拆分成更小的部分，以便可以在不同的机器上运行测试，以帮助缩小应由哪个团队进行研究？

这假设您可以多次运行测试并以这种方式划分事物，所以这是一个粗略的想法。

【讨论】：

【解决方案7】：

我们每天早上在开始工作之前都会举行一次站立会议。清单上的一件事是每晚构建的状态。我们的构建系统在运行后会发送一封电子邮件，报告状态，因此很容易找到 - 碰巧，它会发给一个人，但实际上应该发给每个人，或者发布到项目 wiki 上。

如果构建被破坏，那么修复它就成为最优先的任务，像任何其他任务一样处理，这意味着我们将在站立会议上决定谁来处理它，然后他们去这样做。我们进行结对编程，通常会将其视为结对任务。如果我们人手不足，我们可能会指派一个人来调查破损，然后再与他配对，稍后再修复它。

我们没有分配任务的正式机制：我们是一个小团队（通常是六个人），并且拥有集体代码所有权，所以我们只是在自己之间解决。如果我们认为某一对的签入破坏了构建，通常是他们来修复它。如果不是，那可能是任何人；这通常是通过查看谁目前没有在执行其他任务来决定的。

【讨论】：