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

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

  Jim认为,

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

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

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

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

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

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

  Eric建议如下:

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

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

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

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

  Jim总结了一下,

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

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

你可能感兴趣的:(部署)