BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Ben Hughes 关注 0 他的粉丝 ,译者 李剑 关注 1 他的粉丝 发布于 2008年2月15日. 估计阅读时间: 2 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。
针对最近旨于将持续集成扩展到持续生产的一系列活动,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?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT