在2017在线技术峰会——首届阿里巴巴研发效能嘉年华上，来自阿里云研发协同的技术专家怀虎分享了《阿里巴巴1582.73亿背后的持续交付如何玩》。他详细介绍了阿里巴巴的企业级持续交付，从研发参与者的各个角色解析阿里持续交付的流程和环节，并对RDC的理念进行了解析。

以下内容根据直播视频整理而成。

直播视频：https://yq.aliyun.com/edu/lesson/547

PDF下载：https://yq.aliyun.com/attachment/download/?id=1840

持续交付的目标

新的业务需要新的应用来承载，所以我们希望能够快速上线新的应用。有了代码之后，希望其构建过程是标准的，不需要针对每个环境、应用再去调构建过程。当应用上线之后，需要有新的功能来迭代，功能被提出来之后希望能够快速高效的完成，并且可以在各个环境中进行验证，最后可以一键发布到线上。

阿里巴巴的企业级持续交付

最开始，阿里巴巴也是使用开源套件的，比如Jenkins，但是逐渐难以满足需求：不能满足如此大的规模，资源管理、持续交付在运维的过程中使用Jenkins很难串起来，使用开源套件难以和现有的系统有机结合。所以，研发了自研平台，今年将这套体系推到阿里云上供阿里云的用户使用。RDC和内部平台的核心是一致的，不同的是内部平台有自己的机房，有自己的资源管理方式。但是上云之后，数据库、负载均衡等基础设施都会使用阿里云上的。

持续交付中有三种角色：开发人员，把需求实现，保证其可以交付上线；开发负责人，团队建设，保证团队在指定时间内完成高优先级的任务；运维人员，负责发布和运维。

开发人员：日常开发feature

开发人员开发一个新的feature需要上图所示的工作。首先需要拉分支来开发新的功能，然后为分支配置持续集成，开发测试完成之后需要合入集成分支。此时需要从主干分支拉取release分支出来，把需要合并的一个或者多个分支合并进入。解决冲突的过程中需要对集成分支上部署的版本进行测试，需要为新的分支创建集成分支的配置。测试完成后使用集成分支进行发布到预发环境、线上。最后，再将其合并回主干。实际上，开发人员需要花时间做的只有开发测试和在集成分支上测试，上图中除了这两个步骤，其他步骤都是可以自动化完成的。

这样流程的好处是能够灵活掌握开发节奏。分支模式不是真正的数据集成，因为一定要等到所有的东西都集成到一个分支之后才知道是不是可行。即使在一个fetch分支上测试好也不代表集成分支上也能工作。主干模式是指随时想做任何变动，则调用某个方法的所有地方都需要做一个改变，主干模式做这件事情比较简单，结果可以立即看出，而分支模式则需要集成之后才知道结果。RDC提供了自由模式（一种主干模式）、分支模式、Git flow模式（所有的用户都在develop分支上开发，进入之前需要code review来实现）。

自由模式和develop模式有几个环节：版本制作、日常、预发、灰度。日常和预发之间有一个按钮用于在制作好之后预发布。

开发人员：可怕的发布

首先，我们需要有充分的测试，包括单元测试、API测试、阶段检查。此外，发明了另外一种测试方法，截取线上的一部分流量进行存储，在预发环境进行回放，看结果是否一致。人工的代码review更多涉及到代码架构，所以希望每次的代码提交都能经过代码review过程。灵活的发布工具也很重要，规模小的时候怎么发布都可以，但是当规模比较大时灵活发布很重要。发布方式目前支持分批发布，分布策略可以根据分组、机房来分。

发布一定要是可靠的，一定是可重复的，一个包发100次一定是同样的结果。如果发布之后发现线上有问题，则需要回滚代码，只需要把发了的部分进行回滚即可。回滚包括发布中回滚和发布后回滚。所有的过程一定要减少人为的介入，让这些都自动化的发生，所以希望有一个流程和卡点，如果不满足此刻要求就不能继续往下走。

发布的问题总结来说：使用单元测试，功能测试，接口测试等多层保护；通过系统卡点的方式保证上述测试真的被执行，且真正有效；提供灵活，可靠的发布方案；提供灵活，可靠的回滚方案；使用和线上的环境进行测试（预发）。

开发人员：定位问题

定位问题花费的时间往往比编码还要多，问题可能出现在测试环境，也可能出现在线上。线上版本和上次发布之间有哪些变化？这些都要考虑清楚才能进一步定位问题。

平台有统一的流程将这些问题记录下来：创建分支，提交集成区，提交发布。在这样整个标准的变更流程中，会把很多信息记录下来。上图中的列表是一个发布的列表，包括发布内容、发布结果、操作人、版本详情等内容。所有信息都可以帮助追溯之前发生的事情，并且进行问题解决。

运维人员：线上变更充满危险

最初的时候采用了脚本批量执行，后来使用了声明式的基线管理，但是还是难以避免线上的基线被人手工篡改，而且不能保证基线变更失败后如何处理。2016年开始，阿里使用Docker容器镜像，问题变得迎刃而解，因为每次部署的都是新的镜像，环境保证一模一样。Docker化基础设施是在阿里内部的，而RDC在阿里云上怎么办？我们会去对接阿里云上的基础设施、已有服务，使用其整个服务来对接前面RDC的研发。

RDC发源于阿里内部，扎根于阿里云，后面所有的生态建设都会围绕阿里云已有的生态来建设。上图中，企业入驻RDC企业级研发协同平台后就可以享受整个阿里云的基础设施。EDAS也是阿里云正在做的事情，ECS、SLB等资源也可以通过RDC进行整合。

RDC是一个SaaS产品，不是私有云产品。由于没有部署到机房里，所以它可能访问不到VPC里面的机器，但是有时却有这样的需求。有时需要做预发、API测试，这些需要在公网里进行，但是公网却没有访问权限。目前的一个可行方案是，可以通过代理享受更多的服务。

上图中蓝色部分是已经发布上线的。构建和发布目前是基于关联ECS并且自定义脚本的方式来发布。EDAS和容器正在对接。

这样，开发过程的角色会有一定的转变。企业的现状是，有开发会做本地、测试环境的编码和日常测试，有专门的测试在QA环境进行功能验证，有运维去专门管理staging环境和正式环境。DevOps是开发自运维，运维人员做好了很好的平台，开发可以进行测试，可以从发布流水线收到反馈，自己去编写测试用例，做新应用的发布上线，做日常功能的开发、线上变更、扩容缩容、线上故障处理。

总结

RDC的理念是自动化一切可以自动化的事情，提供尽量多的模式，有安全、灵活的发布流程，使用工具流程来保证开发团队按照最佳实践工作，对开发过程的数据提供足够的可追溯性，依托阿里云基础设施，助力企业的Devops。