摘要
距离云栖大会只有57天了，接下来保障君会提前曝光一些展台亮点来回馈粉丝们。这不，我们请来辉子同学和大家聊一聊阿里巴巴持续交付平台。阿里巴巴线上有上万个应用，上亿的用户即时在线，每天有几百个应用在线上更新，而保护业务平稳运行的产品体系就是阿里巴巴持续交付平台。
正文
N年前，当我还在TW，一个很多人说是神，也有人骂是渣的公司。神渣都不重要，重要的是这个以技术为本的公司的男女老少都在聊技术，hr都恨不得给你写段ruby代码。于是，那些年风花雪月的咨询生涯里，带着持续集成，重构，看板，TDD，结对编程等等武器，我横行于唾沫横飞的江湖，感慨于口水＋鼠标也可以将世界变得更美好。直到有天，一股互联网大军浩浩荡荡路过，顺便就把我给收编了。
阿里巴巴，如今已经是巨人公司，西溪园区的三尊巨人雕像可以带给游人无限的遐想。巨人已经瞩目到一个大动作就要被人说成吃了兴奋剂，打个盹要被人认为得了脑膜炎。在这个充分言论自由的自媒体时代（至少对阿里巴巴是这样的），一个代码的错误就能引起惊天动地的一场地震。这让多年身为屌丝的我深刻感受到做名人真难。
阿里巴巴在线上运行着上万的应用，上亿的用户分分秒秒在阿里平台上享受稳定，便利，快速的服务。阿里巴巴每天都有几百个应用在线上升级更新，就像在时速200公里的高速公路上让我横穿马路去维修一个栏杆，每一刻都是胆战心惊。记得我在实习线上PE岗位时，比我小10岁的PE老师让我升级线上某些机器的tomcat，顿时手脚发抖，浑身冒汗。
阿里巴巴需要一个体系，去承载这上万个应用的安全发布。多年来阿里技术保障部的同学们在一次次故障中吸取教训，总结在一次应用发布中哪些关键因素可能影响到发布的质量：
- code review：很多重大故障来源于一行愚蠢的代码
- 测试：没有测试就没有发布
- 灰度：只要还有一部分对的，就意味着服务还是可用的
- 正式发布：发布变更要记录，没记下来就意味着失控
———此处若发生故障———
- 故障应用定位：一旦错了，先要知道哪个应用发布错了
- 应用回滚：别管错误原因啦，赶紧回到没错的时候
- 故障定位：这时再来找错误
- 修复：错误修复了再发布
阿里巴巴的强分支模式注定了，在这1-8的发布流程中，都是once effort，也就是在一次发布中1-8每个活动最多执行一次。我隐隐约约的看到了持续发布的影子，那伴随我多年的灵感此时知识如泉涌。懂行的看客们，让我们另类解释一下持续交付的样子。
集成
在一起就是集成。代码commit是集成（代码在一起），编译是集成（逻辑在一起），部署是集成（部署包跟环境在一起），测试是集成（功能在一起），灰度是集成（系统在一起）
持续
只有不停的集成才是持续集成。越少持续，每次反馈代价越大。
部署
部署是保持集成独立性的关键要素
交付
若干次集成产生一次交付
不好的持续交付线
好的持续交付线
好的持续发布线的特点
- 包含>=1次集成的活动叫集成活动，比如上图代码嵌入活动包含了编译，单元测试两次集成
- 最好有n－1个集成活动中有部署任务（部署活动）（n是集成活动总数量）［一次编译，多次部署］
- 最后一个活动是发布上线（发布活动），同时一定是个部署活动
- 每个集成活动必须是原子级：每个集成活动有足够的反馈，活动间相互独立
- 反馈的覆盖面越来越大：后面的集成活动比前面的集成活动验证得多一些
- 反馈的代价越来越大：后面的集成活动比前面的集成活动付出的代价更大
- 活动执行的频度越来越低：后面活动的执行频度低于前面活动的执行频度
- 持续发布中主线发布是王道，火车模型很酷炫（当然分支开发也是支持的：）
- 每次发布都可以快速回滚
10.可定制的智能表单：变更要有记录，发布可以审批
欢迎参加2019云栖大会做进一步了解
在阿里式持续发布理论的带动下，阿里巴巴正在加速万级应用上线系统化，白屏化的过程。阿里巴巴工程效率正在帮助阿里集团将开发模式全面转入主线开发模式，在这个趋势下，阿里持续发布平台从项目维度（而不是个人维度）整合包括进度管理、优先级管理、范围管理、风险管理、需求管理、缺陷管理、测试管理、代码管理、构件管理、持续集成、智能表单、插件管理、环境管理等所有开发领域的各个环节，形成统一化与白屏化的集成平台。
当前开发领域的平台及工具产品更多是割裂的系统，而在阿里的持续交付平台中我们把一切都统合到了一起，让研发人员轻松简单的把需求交付到客户手中。我们希望能与广大研发人员不断的在理论和实践中获得提高，并共同进步。
作者： 张群辉（辉子），持续交付线性理论提出者，原ThoughtWorks首席架构师。是技术保障、过程改进和持续交付领域资深专家。目前带领工程效率团队为阿里巴巴及全球软件企业提供从需求发起到软件交付全环节的支持与服务。
