针对最近旨于将持续集成扩展到持续生产的一系列活动， 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 的读者们，你们是否有过持续生产的经验呢？它真的可以给普通项目团队（以致团队所属组织）带来额外的敏捷度么？除了最成功的一些特例以外，对于这种类型的其他组织来说，这种做法的成本与收益是否难以评判？
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论