DevOps与持续交付，一个硬币的两面

easthomeRT

    DevOps相对于传统运维最鲜明的特点是强调持续交付。有时我们基本可以认为持续交付是DevOps的“明星替身”，两者基本可以认为是一个硬币的两面！

       持续交付是一种以安全、快速、可持续的方式向生产环境或用户手中交付所有类型变更的能力，这些变更包括引入新的特性(Feature)、改变配置项(CI)、修复Bug和功能实现等。

       持续交付强调软件全生命周期（ALM）的部署流水线，即一个应用程序从需求分析（Requirement Analysis）、架构设计（Architect Design）、构建（Build）、测试(Test)、部署（Deployment）到交付(Delivery)整个过程的自动化实现。在国内目前BAT都拥有自己的自动化部署平台，在国外谷歌在这方面表现的尤为突出。

        我们来具体谈一下持续交付可能做到的内容，其实就是所谓持续交付的目标有哪些？持续交付的具体目标有如下三点：

        首先，让软件构建、部署、测试和交付的过程对所有人可见，促进团队彼此的合作。其次，大大改善过程反馈，以便在整个过程中更早发现并解决问题。最后，团队能够通过一个完全自动化的平台在任意环境上部署和发布软件的任意版本，并实现用户流量在不同环境间动态的切换。

       与DevOps的理念相一致的，组织要实现持续交付也需要对其现有的IT部门的组织架构进行必要调整。最好是把现有的开发、测试和运营三个独立的团队进行整合，在团队内部提倡知识的分享和能力的培养。最好使团队的所有人都可以胜任软件开发生命周期的所有工作，即强调“全栈式工程师”的理念。这种跨职能和自组织的团队建设思想与敏捷开发方法论（Scrum和XP）不谋而合。

       目前DevOps的实践主要来自互联网公司，比如谷歌和百度等。他们针对软件发布的特点就是能够保证在自动化发布中兼顾业务的连续性。为了达到这个目的，互联网公司也总结很好的软件持续交付的实践办法，比如蓝绿发布、金丝雀和灰度发布等。

       蓝绿发布强调生产环境同时有两套系统，一次只发布新的版本到一个系统，通过网络的路由设置来动态切换用户流量到指定的系统。金丝雀和灰度发布的机理是一致的，即把应用程序的某个新版本部署到生产环境的部分服务器或部分用户群体中，从而得到快速反馈并降低可能的发布风险。 在确定新版本风险可控的情况下，再逐步把新版本部署到全部的服务器上，从而支持所有用户的新功能体验。

本文出自东方瑞通祝文彬老师，转载请注明！

更多行业干货、技术文章，请关注公众号：东方瑞通终身学习~

Rockyw

感谢楼主分享！