针对最近旨于将持续集成扩展到持续生产的一系列活动, 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”标签长达数年之久。
所以这种思想看上去正是一个真正敏捷过程的根本性做法。 ZDNet 2005 年发表的文章《为何微软无法超越Google》提到:> 微软的业务模型依赖于每个人每二至三年更新一次他们的计算环境。Google 则依赖于每个人每天对计算环境中发生的变化进行探索。
这正说明:组织如何发布产品,可以对他们响应客户变化需求的方式造成约束。InfoQ 的读者们,你们是否有过持续生产的经验呢?它真的可以给普通项目团队(以致团队所属组织)带来额外的敏捷度么?除了最成功的一些特例以外,对于这种类型的其他组织来说,这种做法的成本与收益是否难以评判?
评论