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

　　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总结了一下，

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

原文转自：http://www.ltesting.net