DevOps
在一个较成熟的软件和服务交付的团队里，就技术层面来说主要分为三个组成部分：开发、测试和运维。开发测试团队比较关注的是代码能否运行，而运维比较关注的是系统能否在上线后稳定运行，于是隔阂就产生了。DevOps的出现就是为了解决这一问题。DevOps的作用就是将这三个部分紧密的连接起来，提供一条从软件开发到质量保障到技术运营的自动化流水线，加强不同角色之间的沟通和协作，从而减少资源浪费、提高质量，并将产品快速推向市场，快速有效的把一个想法变成价值交付到客户手中。
CD
怎样实现DevOps？我们定义了CD（持续集成），CD是一个方法。CD有三个重要的点：自动化、持续和有效的反馈。图中从左到右是代码到交付的过程。
CD过程中可能遇到几个问题，概括有三方面：环境一致性问题，开发人员之间环境也会产生不一致；版本管理问题；快速响应（发布、回滚）问题。
那么，问题的根源是什么呢？是因为Developer交付的只有代码，以及代码的依赖，而keep site running需要除了代码之外的运行环境，以及运行环境之间的依赖。
Docker
如何打破传统CD壁垒？
Docker是实现DevOps最合适的工具之一，甚至变革了软件交付方式，可以有效解决持续交付过程中遇到的问题。
阿里云容器服务
阿里云容器服务在资源层面有集群、节点，在内容层面有Compose模板、镜像，在应用层面有应用、服务和容器。
完整的容器化持续交付流程
传统的开发过程开发者的代码里有逻辑、应用以及代码依赖包，而我们的代码中会更多的加入Docker File、Docker Compose，用来制作集装箱和搬运集装箱，代码提交成功后代码服务器会通知CI server，CI server会拉取代码进行代码打包，打包后进行单元测试，如果单元测试没有通过，有效的反馈就会马上告诉开发者。如果通过，认为应用包括有应用，我们会根据代码给予的Docker file制作镜像，server会有配置的使用权限，会把镜像推送到阿里云容器，代码可交付的东西已经产生。
部署阶段，如果进行集成测试或回归测试，走测试环境，部署时Compose模板就是用来描述如何部署的，通过Jenkins来丰富功能，通过各种插件将镜像拉取下来部署在应用环境上，从而实现代码提交变更到整个部署过程。
Jenkins2.0
Jenkins 2.0版本中包含了一个新的管道（pipline）构建交付系统，管道的设计理念是基于Groovy DSL，实现一套灵活、可扩展的持续发布（CD）工作流，将原本独立运行于单个或多个节点的任务连接起来，实现复杂发布流程。并且，Jenkins支持从代码库直接读取脚本。
从零开始搭建一个持续交付系统
Stage是对整个持续交付流程的清晰定义，是由自己写出来，单元测试结果也可以完美的展示，每一个阶段的耗时等可以直接读取日志查看，也可以在本地存储软件打包的结果。
持续交付流程设计
通过插件实现动态生成slave，执行job最后销毁的过程，我们也支持共享存储OSS，上传war包，用镜像的方式存储要交付的东西，部署是由阿里云自主开发的插件，调用容器服务的API。
Jenkins Master and Agent
Docker in docker方式是指，Agent会用到Docker进行镜像打包，如果有十个项目在Jenkins上执行时，就会涉及到在所有项目中安装agent非常消耗资源，所以我们采用父子结构，通过透传的方式，可以使用宿主机上Docker的agent服务器执行镜像构建和打包，做到自动化流程内的隔离。
发布策略
容器服务现在支持两种发布方式：
一是rolling update，依次停止老容器，启动新容器，整个过程自动化，无需用户手动操作，适合测试场景，适合于多副本的应用发布；一是蓝绿发布（热部署）：不会停止老容器，为新服务启动新容器，需要用户设置路由权重，实现不同版本应用的上线、下线，适合于版本的快速发布，不会停机影响用户。
未来还会支持金丝雀发布（灰度）：不会停止老容器，为新服务启动新容器，需要用户设置路由权重，实现不同版本应用的共存，支持A/B测试，适合多方案选择。
