让开发自动化: 持续集成反模式

虽然持续集成（CI）在降低项目风险方面极为有效，但是它对日常编码活动有更多要求。在这份由两个部分组成的持续集成反模式文章的第二部分，自动化专家兼 Continuous Integration: Improving Software Quality and Reducing Risk 一书的合著者 Paul Duvall 继续介绍持续集成的反模式，并重点演示如何避免它们。

在这篇共两部分的文章的 第一部分，我描述了以下六种持续集成反模式：

• 签入不够频繁，这会导致集成被延迟
• 破碎的构建，这使团队无法转而执行其他任务
• 反馈太少，这使开发人员无法采取纠正措施
• 接收垃圾反馈，这使开发人员忽视反馈消息
• 所拥有的机器缓慢，这导致延迟反馈
• 依赖于膨胀的构建，这会降低反馈速度

这些反模式延迟或者阻碍了使用持续集成能够得到的好处。在第二部分中，我要介绍其他五种同样具有欺骗性的实践：

• 等到一天结束时才提交修改，造成瓶颈提交，通常造成破碎的构建，使开发人员备受挫折。
  
  
• 构建中只包含很少的自动过程，结果导致构建总是成功，造成持续忽视（Continuous Ignorance）和集成延迟问题。
  
  
• 没有频繁地通过代码修改构建软件，而倾向于定时构建，从而不利于构建修复。
  
  
• 相信代码能够在自己的机器上工作，因此只能在其他环境中发现问题。
  
  
• 没有清除旧的构建工件，造成环境混乱，引起误判和漏判错误。

再次强调，要得到持续集成的诸多好处，那就应该理解这些反模式 — 并避免它们。

避免瓶颈提交造成的阻塞

名称：瓶颈提交

反模式：开发人员在当日工作结束前提交代码修改，引起集成构建错误，妨碍团队成员正常下班。

解决方案：全天频繁地签入代码。

什么是集成构建？ 集成构建 是一种从版本控制库中签出源文件，并在单独的 机器（不只是开发人员的工作站）上运行的构建。

瓶颈提交是签入不够频繁 反模式的一种变体。它认为每天只要至少签入一次代码即可。但是，问题在于每个人都在同一时间 签入。在 CM Crossroads 的一篇文章中，Slava Imeshev 描述了为什么大多数构建失败都发生在晚上 5 点到 8 点之间（范围再小一些，还包括午餐时间）。在 “五点钟签入（Five-O'Clock Check-In）” 中，Imeshev 将这种情况的发生与开人员倾向于每天结束之前签入他们的代码修改这种习惯联系在一起（请参阅 参考资料）。

五点钟现象处处可见

如果某个团队的规定是在所有修改都提交而且运行了构建之前不能下班，那么五点钟签入 将使您很快失去很多朋友。等待代码提交是件非常无聊的事情。想想如果构建出问题会怎么样？我想会有许多人打电话回家去解释为什么又得晚回家。

图 1 演示了软件开发团队签入的典型时间线。请注意库提交放在晚餐时间前后，在下班时间之前。

当然，这个问题的解决方案就是频繁地提交修改。通过频繁提交，就会拥有更小但更频繁的集成构建，而且在出现构建错误时，错误会较少，而且更容易修复。

五点钟的言外之意很清楚，所以为了自己和团队都应该频繁地签入代码，让五点钟成为多数人的快乐时光。

原文转自：http://www.ltesting.net