修复破碎夜间构建的政策

Question

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

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

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

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

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

Answer 1

一个关于破坏夜间构建的着名政策,归功于微软,是那个提交破坏了构建的人,负责维护夜间构建,直到其他人破坏它为止.

这是有道理的,因为

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

Answer 2

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

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

这意味着团队中至少有一名成员必须对整个应用程序有深入的了解——但这并不是一件坏事：它将有助于在应用程序在生产中使用并出现故障时诊断问题。

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

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

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

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