阿里云持续交付实战
2016云栖大会上海峰会于2016.1.20日在上海科技馆顺利举办。本文根据阿里技术保障部产品专家张程荣在“云栖大会上海峰会”专场《“互联网+”架构及实践专场-企业级信息系统云化演进之路》中的演讲整理。张程荣在演讲中主要为大家介绍了阿里云持续交付的经验。
下面是演讲内容整理。
拥有3万多人的阿里巴巴，线上有上万个应用，上亿的用户即时在线，每天有几百个应用在线上更新，就像在时速200公里的高速公路上横穿马路维修栅栏一样，时刻保持着心惊胆战，而保护这个过程的体系就是阿里巴巴持续交付工具与实践。
现代开发企业中如何做好持续交付是一件异常重要的事情，在互联网企业中更是如此。而阿里巴巴在这么多年的研发管理基础上，对如何做好持续交付提出了一套全新的模型与实践。
本次演讲会深度分析阿里式的持续交付理论，同时分享如何通过工具提升研发管理实践效果。交互无小事，任何与客户有关的都是大事，做好了研发管理才能平安如意，如同登录在月球虹湾里那么高效安稳。
今天阿里巴巴的产品专家张程荣来给大家分享下阿里云持续交付怎么才能打造高质量的交付和高质量的软件。以下是精彩分享内容整理。
为什么会有持续交付的思考？
大家知道双11当时每秒钟十几万次的交易量，我们这时候去做软件更新时一定是要做到持续的，不会中间中断，代码更新完就马上要上线的，而不是说任何的操作要隔上几个月、几天才能去更新，这肯定是不行的。我们到底怎么去解决这些问题？我们总结出影响发布质量的关键因素，分为两大块：
持续交付是什么？
持续交付包含几个方面：集成、持续、部署、交付。
集成是什么呢？我们认为在一起就是集成，就是代码放在一块，你的逻辑放在一块就叫集成。只有不停的集成才是一个持续集成。我们有时候会产生这样的问题，一个人在部署的时候另外一个人在测试，有可能就会产生冲突，所以部署是保证集成独立性的关键要素。多次的集成产生一次的交付。如果前面不做集成的话在做交付的时候会不会很担心？所以只有在多次集成之后才会去做这次交付。
习惯养成
持续交付里面很多内容是我们的一个习惯，怎么去养成这些习惯呢？就是人在做一些事情的时候，或者是在做集体的运动当中是有心理过程的。1967年美国有一个高中老师做了一个叫做“第三次帝国”的实验，就是他为了证明集体主义养成习惯是非常快的。第一天，他做的是来上课的时候让所有的学生起立坐下，他说起立的时候就起立，他说坐下的时候就坐下，一共花了5分钟。然后让所有的学生到教室外面，他做了示意之后学生进来之后再坐下，在这个过程中鸦雀无声。就是说人类的习惯开始可能只需要5分钟，养成这个习惯只有用了3天。怎么样去养成一个习惯是非常容易、非常惯性的一个事情，我们通过一个良好的工具、一个良好的计划是可以养成我们持续交付中应该去做的事情。影响发布质量的关键因素就是我们应该要去养成的习惯。
不好的持续交付线
图1中会看到这样几个节点，第一个节点是代码提交、编译、单元测试。代码提交之后并不能在旁边坐着喝一杯咖啡，其实这个过程是不对的，你的反馈量是不够的，只有把编译和单元测试都放在一块的时候才可以。第二个节点是我们的部署环境和集成测试，部署环境和集成测试为什么单独分开是有问题的呢？部署和集成测试应该是在同一个活动中的，部署会影响集成测试。任何一个集成测试环境，在别人会随意点到你这个部署造成你的环境崩溃的情况下，整个测试是不安全的，我们希望活动间不相互影响，所以这两个环节应该并在一块。
好的持续交付线
在好的交付线基础上我们提出了一套理论，我们可以看到整个持续交付的过程里面有几个点：原子级活动，覆盖面越来越大，代价越来越高，频度越来越低。最终根据这四个原则我们一直不停的去做持续交付的话会出现一个数据，就是持续集成的次数肯定会大于等于持续部署的次数，最终会大于持续交付的次数，即图3中 M大于等于N大于等于1。如果这里面的数据是趋向于相互都相等的，就是说代码提交后直接到交付了，这个过程一般是不太正常的，很难达到这个过程，中间还是会有一些集成和测试的过程。
持续交付工具
在开发企业中会去做包括TDD、敏捷开发这些过程的一些事情，做这些事情是为了什么？肯定是为了提供一个高质量的软件马上去交付到我的线上或者是交付到我的服务器中，我们中间会应用一些工具。
敏捷宣言：个人和互动高于流程和工具；工作软件高于理解文档；客户协作高于合同协商；变化响应高于计划遵循。
我们既然要做到敏捷宣言里面敏捷开发的一些过程，就需要用到持续交付的工具，持续交付的工具需要包含几个部分：项目管理、代码托管、构建管理以及持续发布，最后形成持续交付线。
项目管理需要动态性的文档。我们在网页上有一些内容，页面上会有相应的标签提示你是什么样的内容，我们的任务墙上会产生相应的故事卡，就是敏捷开发里面我们谈所谓的故事，我要分解出最终能够实现的故事，打通它的特性。我们认为所有的人员都应该在一份文档中去观察、修改、编辑你的内容。传统的开发模式里面我们会分角色，这个事情在敏捷开发里面其实是强烈反对的，我们更多希望他是一个角色的同步，大家应该在能力和角色上是打通的。我们通过这份文档让所有人习惯于在一份文档中更新信息，造成信息的统一性，最后在人员的能力上进行一个打通。
沟通
在我们的软件开发过程中沟通是非常重要的环节。第一是我们的面对面沟通，第二是电话沟通，第三是即时消息，第四是邮件。在我们的持续交付里面我们也都提供这样的功能，包括现在在市面上有一些做项目协作的软件或者是平台，大家都是追求怎么样提高我们的开发效率，就是提高我们的沟通。
阿里巴巴现在提供了一套代码管理的服务：
阿里云构件仓库实现高速并且稳定的Maven镜像管理服务，每天与其他中央库同步，提供高速稳定的网络和服务。可以通过构件服务上传、下载插件或依赖包，这使得在构建时可以快速下载依赖包，也可以上传依赖包提供给其他开发者使用。
整个持续交付应该是一套完整的系统。我们做到的备份效果是非常好的，会达到1:9的备份，我们还提供一个构件的服务，构件也会达到1:3的备份。而且我们的上传非常简单。
建立反脆弱系统
为什么要做持续交付，还有一个非常重要的点——人肯定会产生意外的情况，整个世界都会有意外的情况，我们怎么在产生意外事件时保护你的代码和开发？我们就应该用到持续交付系统，（上图）就是我们的持续交付系统，我们会非常快速高效的让软件放到线上。而且我们现在还提供了几种服务，我们可以通过ECS的部署，我们还有容器的服务，我们可以部署到容器上，而且我们可以通过阿里云的容器非常简单快速的上传下载。同时我们还提供了一个审批的服务，现在持续集成的软件里面其实没有这一步。
云协作从这里开始
持续交付平台（CRP，Continuous Rlease Plaftorm）提供软件生命周期全环节服务，包括项目管理、需求管理、缺陷管理、代码托管、构件管理、开发环境管理、持续交付线、构件管理、依赖管理、测试管理、一键部署、监控管理、团队协作等。让您的软件简单、快捷、安全、高效的交付。
2016云栖大会上海峰会回顾专题（含演讲视频）：http://yunqi.aliyun.com/2015/shanghai/review.html
下面是演讲内容整理。
拥有3万多人的阿里巴巴，线上有上万个应用，上亿的用户即时在线，每天有几百个应用在线上更新，就像在时速200公里的高速公路上横穿马路维修栅栏一样，时刻保持着心惊胆战，而保护这个过程的体系就是阿里巴巴持续交付工具与实践。
现代开发企业中如何做好持续交付是一件异常重要的事情，在互联网企业中更是如此。而阿里巴巴在这么多年的研发管理基础上，对如何做好持续交付提出了一套全新的模型与实践。
本次演讲会深度分析阿里式的持续交付理论，同时分享如何通过工具提升研发管理实践效果。交互无小事，任何与客户有关的都是大事，做好了研发管理才能平安如意，如同登录在月球虹湾里那么高效安稳。
今天阿里巴巴的产品专家张程荣来给大家分享下阿里云持续交付怎么才能打造高质量的交付和高质量的软件。以下是精彩分享内容整理。
为什么会有持续交付的思考？
大家知道双11当时每秒钟十几万次的交易量，我们这时候去做软件更新时一定是要做到持续的，不会中间中断，代码更新完就马上要上线的，而不是说任何的操作要隔上几个月、几天才能去更新，这肯定是不行的。我们到底怎么去解决这些问题？我们总结出影响发布质量的关键因素，分为两大块：
- 未发生故障
- 发生故障
持续交付是什么？
持续交付包含几个方面：集成、持续、部署、交付。
集成是什么呢？我们认为在一起就是集成，就是代码放在一块，你的逻辑放在一块就叫集成。只有不停的集成才是一个持续集成。我们有时候会产生这样的问题，一个人在部署的时候另外一个人在测试，有可能就会产生冲突，所以部署是保证集成独立性的关键要素。多次的集成产生一次的交付。如果前面不做集成的话在做交付的时候会不会很担心？所以只有在多次集成之后才会去做这次交付。
习惯养成
持续交付里面很多内容是我们的一个习惯，怎么去养成这些习惯呢？就是人在做一些事情的时候，或者是在做集体的运动当中是有心理过程的。1967年美国有一个高中老师做了一个叫做“第三次帝国”的实验，就是他为了证明集体主义养成习惯是非常快的。第一天，他做的是来上课的时候让所有的学生起立坐下，他说起立的时候就起立，他说坐下的时候就坐下，一共花了5分钟。然后让所有的学生到教室外面，他做了示意之后学生进来之后再坐下，在这个过程中鸦雀无声。就是说人类的习惯开始可能只需要5分钟，养成这个习惯只有用了3天。怎么样去养成一个习惯是非常容易、非常惯性的一个事情，我们通过一个良好的工具、一个良好的计划是可以养成我们持续交付中应该去做的事情。影响发布质量的关键因素就是我们应该要去养成的习惯。
不好的持续交付线
图1最简单、最缩小的一个持续交付的过程
图1中会看到这样几个节点，第一个节点是代码提交、编译、单元测试。代码提交之后并不能在旁边坐着喝一杯咖啡，其实这个过程是不对的，你的反馈量是不够的，只有把编译和单元测试都放在一块的时候才可以。第二个节点是我们的部署环境和集成测试，部署环境和集成测试为什么单独分开是有问题的呢？部署和集成测试应该是在同一个活动中的，部署会影响集成测试。任何一个集成测试环境，在别人会随意点到你这个部署造成你的环境崩溃的情况下，整个测试是不安全的，我们希望活动间不相互影响，所以这两个环节应该并在一块。
好的持续交付线
图2好的交付线框架图
如何去养成一个好的交付线？其实很简单，图2中，在第一个节点我们应该把代码检出，和我们的编译、单元测试放在一块，第二个节点就是我们的部署和集成测试，第三个节点是部署冒烟环境和冒烟测试，第四个节点是部署生产环境和冒烟测试。
图3持续交付线的数据理论
在好的交付线基础上我们提出了一套理论，我们可以看到整个持续交付的过程里面有几个点：原子级活动，覆盖面越来越大，代价越来越高，频度越来越低。最终根据这四个原则我们一直不停的去做持续交付的话会出现一个数据，就是持续集成的次数肯定会大于等于持续部署的次数，最终会大于持续交付的次数，即图3中 M大于等于N大于等于1。如果这里面的数据是趋向于相互都相等的，就是说代码提交后直接到交付了，这个过程一般是不太正常的，很难达到这个过程，中间还是会有一些集成和测试的过程。
持续交付工具
在开发企业中会去做包括TDD、敏捷开发这些过程的一些事情，做这些事情是为了什么？肯定是为了提供一个高质量的软件马上去交付到我的线上或者是交付到我的服务器中，我们中间会应用一些工具。
敏捷宣言：个人和互动高于流程和工具；工作软件高于理解文档；客户协作高于合同协商；变化响应高于计划遵循。
我们既然要做到敏捷宣言里面敏捷开发的一些过程，就需要用到持续交付的工具，持续交付的工具需要包含几个部分：项目管理、代码托管、构建管理以及持续发布，最后形成持续交付线。
图4代码管理
项目管理需要动态性的文档。我们在网页上有一些内容，页面上会有相应的标签提示你是什么样的内容，我们的任务墙上会产生相应的故事卡，就是敏捷开发里面我们谈所谓的故事，我要分解出最终能够实现的故事，打通它的特性。我们认为所有的人员都应该在一份文档中去观察、修改、编辑你的内容。传统的开发模式里面我们会分角色，这个事情在敏捷开发里面其实是强烈反对的，我们更多希望他是一个角色的同步，大家应该在能力和角色上是打通的。我们通过这份文档让所有人习惯于在一份文档中更新信息，造成信息的统一性，最后在人员的能力上进行一个打通。
沟通
在我们的软件开发过程中沟通是非常重要的环节。第一是我们的面对面沟通，第二是电话沟通，第三是即时消息，第四是邮件。在我们的持续交付里面我们也都提供这样的功能，包括现在在市面上有一些做项目协作的软件或者是平台，大家都是追求怎么样提高我们的开发效率，就是提高我们的沟通。
图5代码管理系统图
图6代码库
阿里巴巴现在提供了一套代码管理的服务：
- 集合编译、测试、发布等插件；
- 支持所有Git命令，兼容所有Git工具；
- 私有Git仓库，存储任何类型的源代码及文件；
- 在线浏览和管理代码，提升研发效率。
图7构件管理系统图
图8构件管理
阿里云构件仓库实现高速并且稳定的Maven镜像管理服务，每天与其他中央库同步，提供高速稳定的网络和服务。可以通过构件服务上传、下载插件或依赖包，这使得在构建时可以快速下载依赖包，也可以上传依赖包提供给其他开发者使用。
整个持续交付应该是一套完整的系统。我们做到的备份效果是非常好的，会达到1:9的备份，我们还提供一个构件的服务，构件也会达到1:3的备份。而且我们的上传非常简单。
建立反脆弱系统
图9持续交付系统
图10持续发布线模板
为什么要做持续交付，还有一个非常重要的点——人肯定会产生意外的情况，整个世界都会有意外的情况，我们怎么在产生意外事件时保护你的代码和开发？我们就应该用到持续交付系统，（上图）就是我们的持续交付系统，我们会非常快速高效的让软件放到线上。而且我们现在还提供了几种服务，我们可以通过ECS的部署，我们还有容器的服务，我们可以部署到容器上，而且我们可以通过阿里云的容器非常简单快速的上传下载。同时我们还提供了一个审批的服务，现在持续集成的软件里面其实没有这一步。
云协作从这里开始
持续交付平台（CRP，Continuous Rlease Plaftorm）提供软件生命周期全环节服务，包括项目管理、需求管理、缺陷管理、代码托管、构件管理、开发环境管理、持续交付线、构件管理、依赖管理、测试管理、一键部署、监控管理、团队协作等。让您的软件简单、快捷、安全、高效的交付。
【推荐】阿里云持续交付平台：https://crp.aliyun.com/
2016云栖大会上海峰会回顾专题（含演讲视频）：http://yunqi.aliyun.com/2015/shanghai/review.html