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
0 0 标签： 部署