BT

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

持续部署:说起来容易做起来难

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 金毅 关注 0 他的粉丝 发布于 2011年5月16日. 估计阅读时间: 3 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

持续部署通常被看做是一种敏捷或精益技术,这项技术要求把编写好的所有应用程序代码直接部署到产品线上。这看上去好处很多,节省了开发各个环节的时间,还减少了缺陷修复和新功能投放到市场的时间。然而,真能像说的那么容易吗?

Jim Bird指出,人们在谈到持续部署时,说得最多的是一些琐碎的修改,例如小的调整、表面改动或小缺陷的修复。任何大于这些的修改都需要遵循相应细致、严谨的方法。

Jim认为,

数据库模式(Schema)不能一直在变。较大的功能不能、也不应该一直改变,即使是在进行摸黑启动(dark launching)。以Etsy的做法为例(Etsy是典型的应用持续部署的公司),它不会持续部署一些较大的公共模块。和任何聪明的公司一样,他们会与运维、客服及产品管理部门一起花时间做规划、设计、原型、测试、评审,并最终部署。

Jo Liss提出,持续部署的真正挑战是回滚修改的代价。Jo认为,限制持续集成的频率的因素更多是技术上的,但对于回滚修改成本巨大的持续部署而言,它的限制则完全不同。

但是一旦部署到生产环境,就会影响用户和实际数据,回滚将很昂贵,因为你可能必须:
  • 将数据库回滚到之前的模式和规范。
  • 考虑当前正在使用你站点的用户所受的影响,以及如何在他们的眼皮子底下修改应用程序(可能会导致链接中断,Ajax请求失败)。
  • 如果出了问题(回滚不是你想进行就能进行的),你甚至可能不得不发邮件知会所有受影响的用户,或者处理各种支持请求。

同样地,Eric Ries认为持续部署的最大挑战是必须时刻准备交付。

一方面,这是对客户响应的终极目标。另一方面,这简直是不可能完成的任务。阶段性交付给我们编织了一张(有些虚幻的)安全网。和其他人(测试团队)分担测试责任也让人神清气爽。

那么,一个团队如何确保他们认识到持续部署的价值呢?

Eric建议如下:

  • 不要强推功能,而是根据客户反馈信号做部署
  • 分批小规模修改代码
  • 相对于单元测试,更倾向于尽可能多的进行功能测试
  • 在系统和应用程序层都实现警告(alerts)和监控功能
  • 只容忍意外错误发生一次,并立即修复

Jo认为大家应该减少提交代码到服务器的次数。他指出,正常的部署延迟是在完成代码后的5小时到2天之间。

那么如果你能静下心来,而不是向诱惑屈服,刚愎自用地立即部署,那么你可能可以避免大部分令人追悔莫及的修改,这些错误的修改大概占总数的5%,但真的一定是你不希望提交到产品服务器的。而你等待的这些时间,可能只是错过了为数不多的早期的用户反馈。

这一切并不是说持续部署不可能实现。很多公司,比如EtsyHeyoIMVUAtlassian都在做持续部署,而且很可能做得很不错。

Jim总结了一下,

从持续部署确实可以学到很多,像如何使交付及部署更流畅、更简单,如何降低风险,把工作分解得更小块,然后再把它们串联起来,设定节点监控、度量。但它不是或起码不应该是“开发者的圣杯”。

查看英文原文:Continuous Deployment: Easier Said Than Done

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

讲的不错 by Gu Star

讲的不错

允许的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通知我

1 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT