运维与持续交付
在互联网的产品开发时代，产品迭代越来越频繁，“从功能开发完成直到成功部署”这一阶段被称为软件开发“***一公里”。
一个团队工程技术水平高低，直接反映在部署代码上。我碰到其他公司的人，都喜欢问你们怎么部署代码的，非常大开眼界。你很难相信，很多(有一定规模的)公司仍然是人肉 SSH 到十几、二十台机器上 git pull、手动重启服务器，部署一次代码几个小时 -- 这么原始，活该加班：)
持续部署(continuous deployment)是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity ***化。
持续部署成功的要点
一个持续集成 & 持续部署的自动化系统并不是那么简单的事，如果不选用其他 CI 服务，其开发工作量和一个标准的大型互联网业务系统没什么两样。如果没有持续部署的经验，要想成功地进行持续部署要注意这些:
充分而广泛的自动化测试覆盖;
尽可能短的测试反馈时间;
部署过程自动化;
部署过程要保证数据安全;
在稳定的前提下，尽早部署;
完善的风险缓解措施;
将同样的产物部署到不同的环境中
持续交付能力成熟度模型
持续交付的运维观
1、持续接收到持续交付，运维的核心转变
2、运维掌握了***的持续交付切入点：CMDB和持续交付
3、交付的最终评价：质量、效率、成本
4、持续交付是打破部门墙的核心实践
5、持续交付的本质：标准化+平台化+服务及面向用户的价值
6、基于交付链(Dev/Test/Ops)的全局优化，而非局部(Ops)优化
7、运维的问题不是仅仅运维侧的问题，是一个IT问题
8、运维离用户最近，你代表用户，就有***的驱动力
9、跨界由此而生
