运维与持续交付

在互联网的产品开发时代，产品迭代越来越频繁，“从功能开发完成直到成功部署”这一阶段被称为软件开发“最后一公里”。

@湾区日报对于持续部署， 这样评论：

一个团队工程技术水平高低，直接反映在部署代码上。我碰到其他公司的人，都喜欢问你们怎么部署代码的，非常大开眼界。你很难相信，很多（有一定规模的）公司仍然是人肉 SSH 到十几、二十台机器上 git pull、手动重启服务器，部署一次代码几个小时 -- 这么原始，活该加班：）

持续部署（continuous deployment）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。

持续部署成功的要点

一个持续集成 & 持续部署的自动化系统并不是那么简单的事，如果不选用其他 CI 服务，其开发工作量和一个标准的大型互联网业务系统没什么两样。如果没有持续部署的经验，要想成功地进行持续部署要注意这些:

●充分而广泛的自动化测试覆盖；

●尽可能短的测试反馈时间；

●部署过程自动化；

●部署过程要保证数据安全；

●在稳定的前提下，尽早部署；

●完善的风险缓解措施；

●将同样的产物部署到不同的环境中

持续交付的运维观

1、持续接收到持续交付，运维的核心转变

2、运维掌握了最好的持续交付切入点：CMDB和持续交付

3、交付的最终评价：质量、效率、成本

4、持续交付是打破部门墙的核心实践

5、持续交付的本质：标准化+平台化+服务及面向用户的价值

6、基于交付链(Dev/Test/Ops)的全局优化，而非局部(Ops)优化

7、运维的问题不是仅仅运维侧的问题，是一个IT问题

8、运维离用户最近，你代表用户，就有最强的驱动力

9、跨界由此而生

持续交付能力成熟度模型