持续生产可以将敏捷化推至极限吗？

作者 Ben Hughes 译者 李剑 发布于 2008年2月14日

领域

运维 & 基础架构,

过程 & 实践

主题

配置管理 ,

持续集成 ,

敏捷技术 ,

自动化操作 ,

企业级敏捷 ,

敏捷 ,

编程 ,

企业架构 ,

测试

针对最近旨于将持续集成扩展到持续生产的一系列活动，Stelligent的Paul Duvall发表了一篇文章。“持续生产”是指不断部署软件——而非将其定量做成发行版——的实践。

该文描述了一些从持续集成实践（构建、集成、测试）常见任务延伸到“持续生产”使用的常用实践：

• 持续数据库集成/迁移。
• 通过开发、QA、上线前筹划，以及上线等过程，完成开发过程产出物的自动化演进。
• （使用SmartFrog和Capistrano类似框架）进行远程部署

这些实践是如何影响实际运行系统/产品的生命周期，又如何反过来为组织带来更高的敏捷度呢？Chris May在博客中说：

只要能做到‘早发布，常发布（Release early, Release often）’，发布的间隔长短对项目的成效不会有影响。发布越小越快，推倒重来的可能性就越小，用户就会越快得到功能，团队就会越快得到反馈。基本上， 他们[Flickr]是每完成一个特性或是bug修复就会发布一次——他们不会像我们一样费心进行“定量式”发布。

Tim O'Rielly 在他2005年的文章“何谓Web 2.0”中说到：

[续 上]……“早发布，常发布”这条开源软件社区的格言已经被推广演化到了一个前所未有的高度。“永远的Beta版”则意味着产品在开放的状态下开发，新的特 性会源源不断的在每月、每周甚至每天注入进来。Gmail、Google Maps、Flickr和del.icio.us这些服务的出现绝非偶然，而类似产品也将有可能烙上“Beta”标签长达数年之久。

所以这种思想看上去正是一个真正敏捷过程的根本性做法。ZDNet2005年发表的文章《为何微软无法超越Google》提到：

微软的业务模型依赖于每个人每二至三年更新一次他们的计算环境。Google则依赖于每个人每天对计算环境中发生的变化进行探索。

这正说明：组织如何发布产品，可以对他们响应客户变化需求的方式造成约束。

InfoQ的读者们，你们是否有过持续生产的经验呢？它真的可以给普通项目团队（以致团队所属组织）带来额外的敏捷度么？除了最成功的一些特例以外，对于这种类型的其他组织来说，这种做法的成本与收益是否难以评判？

查看英文原文：Does Continuous Production Lead To Extreme Agility?

译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。