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

尽管持续集成（Continuous Integration，CI）可以非常有效地减少项目的风险，但是它对与编程相关的日常活动提出了很高的要求。在这一期 让开发自动化 中，自动化专家和 Continuous Integration: Improving Software Quality and Reducing Risk 的作者之一 Paul Duvall 列举了一系列 CI 反模式并解释了如何避免它们。

在我的职业生涯中经常发现，通过了解在特定情况下不应该 做什么，可以学到更多知识。例如，在我职业生涯的早期，由于需要快速发布软件，我省略了单元测试，因为我认为不值得做这些工作。幸运的是，我已经学到绝不应该 将未经测试的代码投入生产；因此开始坚持编写单元测试。

整个 IT 行业似乎都主要采用这种学习方式；实际上，我们甚至专门创建了反模式（anti-pattern）这个词，表示在特定环境中不应该采用的做法。反模式是看起来似乎有好处，但是最终可能产生严重影响的解决方案。

看似真实的假象

遗憾的是，我发现当缺少经验的团队试图采用 CI 时，他们很可能错误地采用许多反模式，这最终导致他们不但没有获得预期的好处，反而遇到一大堆麻烦。不幸的是，在这种情况下，团队常常将麻烦归罪于 CI 本身。因此，我常常听到 “CI 不适合大项目” 或 “我们的项目太特殊，不适合采用 CI” 这样的说法，实际上 CI 根本不是问题的原因 — 是某些做法的不恰当应用或者缺少某些方法导致了这些麻烦。

在本文中，我要描述与 CI 相关的六个反模式：

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

如果您采用 CI 的时间足够长，那么几乎肯定体验过这些反模式的效果。这没关系，但是如果它们发生得太频繁，就会大大限制 CI 的好处。因此，如果您希望避免这些反模式并控制它们的负面影响，那么本文正适合您。

本文转自：IBM developerWorks 中国

请点击此处查看全文