我想每个人都同意,持续构建和持续集成有利于软件产品的质量.早期发现缺陷,因此可以尽快修复.对于需要几分钟的连续构建,通常很容易找到导致缺陷的构建者.但是,对于需要很长时间才能运行的夜间集成测试,这可能是一个挑战.以下是具体情况,我正在寻找最佳解决方案:
那么如何组织团队以便尽早修复这些故障呢？在我看来,应该有人指定诊断缺陷.这应该是早上的第一项任务.如果他需要其他人的专业知识,他们应该随时可用.一旦确定了故障的源(组件,数据库,Web服务),所有者就应该开始修复它(或者应该通知另一个团队).
如何指定诊断缺陷的人？理想情况下,有人会自愿(哈哈).我担心这种情况不会经常发生.我听说过其他选择 - 无论谁先到办公室,都应该检查每晚构建的结果.如果整个团队都同意的话,这没关系.但是,这会奖励那些迟到的人.我想这个角色应该在团队中轮换.不应接受"我对构建知之甚少"的借口.故障源的诊断应该相当简单.如果不是,则向代码添加更多诊断日志记录应该可以提高对集成测试失败的可见性.
有关这方面的经验或改进上述方法的建议吗？