Continuous integration 修复损坏的夜间构建的策略

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

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

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

如何指定诊断缺陷的人员？理想情况下，有人会自愿（哈哈）。恐怕这种情况不会经常发生。我听说过其他选择——无论谁先到办公室，都应该检查夜间构建的结果。如果整个团队都同意，这是可以的。然而，这会奖励那些迟到的人。我认为这个角色应该在团队中轮换。“我对构建不太了解”的借口不应该被接受。故障源的诊断应该相当简单。如果不是，那么在代码中添加更多诊断日志应该可以提高集成测试失败的可视性

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

我通常做的（我为一个8到10人的团队做的）是两人一人检查构建，就像他早上做的第一件事一样——我想有些人会说他负责QA

如果有问题，他负责找出什么/如何解决——当然，如果需要，他可以向团队其他成员寻求帮助

这意味着团队中至少有一名成员必须对整个应用程序有很好的了解——但无论如何，这不是一件坏事：在应用程序在生产中使用并出现故障的那一天，它将帮助诊断问题

而不是让一个男人来做，我喜欢有两个：一个是一周，另一个是第二周——例如；这样，即使有人在度假，也更有可能总是有人能诊断出问题

作为旁注：在构建过程中记录的内容越有用，就越容易找出哪里出了问题以及原因

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

• 首先，并不是每个人都想这样做——如果做这件事的人喜欢他所做的，那会做得更好
• 你不希望10个人每天花半小时在这上面^^

---

在你的情况下，我建议由谁负责CM。如果经理或技术负责人的职责太多，为什么不将其交给初级开发人员？我希望在我职业生涯的早期有人强迫我更彻底地了解源代码管理。不仅如此，查看其他人的代码以追踪错误源是一项真正的技能培养或知识学习活动。他们说你从查看别人的代码中获益最多，我对此坚信不移。
微软有一项著名的关于夜间构建中断的政策，即，谁的提交破坏了构建，谁就负责维护夜间构建，直到其他人破坏它
这是有道理的，因为
• 每个人都会犯错误，因此需要进行必要的轮换（在不明确的情况下使用最近最少使用的选择模式）
• 它鼓励人们编写更好的代码

---

我很想建议用以下两种方式中的任何一种进行拆分：
• 时间分割-假设测试可以每晚运行两次，为什么不在两个不同的时间点对代码运行测试，也就是说，所有的签入直到下午X点，然后是剩余的，这样可以帮助缩小问题的范围

• 团队拆分-代码可以拆分成更小的部分，以便测试可以在不同的机器上运行，以帮助缩小应该深入研究的小组

---

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

您可能想考虑让开发人员诊断损坏的构建。我很幸运。尤其是当您将对构建系统不太熟悉的团队成员与非常熟悉的团队成员配对时。这可能会减少团队成员说“我对构建不太了解”作为试图逃避职责的一种方式的可能性，并且会减少和增加您的任务


让团队选择您指定的解决方案或他们自己制定的解决方案
您可以将问题提交给您的团队，并要求他们提供解决方案。告诉他们，如果他们没有提出可行的解决方案，你将制定每周计划，每天分配一对，并确保每个人都有机会参与。
• 练习持续集成，这样您就不需要不频繁的大型构建 **你可以