产品迭代发布如何更快速？阿里持续集成与持续交付实践之路全解析
摘要：2017年5月9日，云效平台资深研发工程师向禹通过直播分享了《持续集成与持续交付实践之路》。他从云效背景、云效方案、云效价值三个方面进行了分享。他主要分享了持续集成持续交付的解决方案和案例，并且对大型系统如何实现持续集成、持续交付、进行产品迭代发布进行了详细介绍。
以下内容根据直播视频整理而成。>>直播回顾
云效背景——阿里巴巴《持续交付》之路
大应用下的交付
在七八年之前，阿里巴巴的B2B一直沿用瀑布的模式来进行项目管理，当时已经感觉到瀑布模式对应用持续快速的发展产生了很大的影响。并且当时很多的应用都是以大应用的方式来开发的，一个应用可能有几十万行、上百万行代码量，如果此时进行小的功能点的修改会比较麻烦。改了几行代码，花费几个小时进行编译打包，发布到测试环境上去，运行全网的自动化回归（积累了两千多个自动化脚本，总共几万行）也非常耗时，降低了开发效率。所以，当时开始准备把大应用进行服务化的拆分，将大应用的逻辑拆分成了会员中心、产品中心、订单中心、交易中心等服务化模块，每个模块下面又有微服务来支撑。
做完第一步改造之后，又遇到一些问题，最明显的是环境上的问题。每一家公司环境管理的方式是类似的，都会划分为开发环境、测试环境、集成环境以及线上的生产环境。微服务化之后，在开发环境下，由于应用变多，调用链路变得更加复杂，很难保证整个环境中所有应用的稳定性。问题难以排查，修改程序之后，很难判断是应用出现问题还是链路出现问题。在集成环境，为了保证稳定性，规定了每周的交付窗口时间，将所有项目代码合成到集成分支上，编译打包部署到集成环境中，运行全网自动化回归脚本。如果出现问题，排查比较麻烦，首先判断是哪一个应用引起的问题，然后再细分到项目组进行排查，修改后重新交付测试。
既然现在已经是微服务了，是否可以跳过集成环境，在开发测试环境将应用完善测试好？经过尝试发现，即使在开发测试环境将某个要发布应用的所有功能测得再详细，也很难保证应用上面的链路和下面的链路的业务逻辑都是正常的。
自动化
如果仅仅通过开发方式的转变是没有办法很好的完成持续集成、持续交付的理念。我们应该创造一个持续集成、持续交付的自动化平台来保证在每个环节里面效率的提升，以及整个链路的打通。
上图是我们在平台上解决的核心问题：并发项目配管方案，在并发项目很多的时候需要进行代码分支的管理；持续部署方案也是需要解决的核心问题；持续验证方案，在持续部署之后要快速进行验证，如果用手工的方式是不现实的；通过持续部署和持续验证达到持续交付的目标；为了让各个团队更好的适应角色的变化、使用平台来提高效率，提出了落地使用推广方案。
持续交付的组成部分
针对需要解决的问题，我们所建设平台核心的原则是核心化、流程化、自动化，希望能够建立持续部署的流程、代码管理的流程，通过自动化的方式实现出来。这成为行业的一个主流趋势。我们在可视化呈现这个架构时，也发现DevOps架构师张乐老师已经有过非常经典的描绘，清晰的说明了这一类型问题的解决方案。我们在制图时做了参考，在此一并感谢张乐老师。（图见北京DevOps day中张乐分享的《大型互联网公司百人团队持续交付变革之路》）
在上述基础上，云效平台建立了配置管理、持续集成、持续交付等相关子系统。通过这些子系统，创造了可靠、可重复的交付流水线。此外，与项目管理进行结合，开发的效率很好的沉淀到了平台上，在平台上建了与项目管理相关的一些子系统，将其数据打通就能达到业务和产品的相互促进。多个角色的团队都会在平台上用相关的系统来进行相互工作上的协作，所以对组织和团队的协作也产生了促进作用。云效平台在内部是部署在专有云平台上，对于托管的应用支持EDAS/Dubbo分布式服务化架构、SpringBoot微服务架构、Docker容器化架构。
云效方案
并发项目配管方案-SCM管理
并发项目配管方案即项目分支管理方案。很多公司在开发一个项目的时候会首先由相关的PM或者运维人员拉出来一个分支交给开发人员。为了简化上述过程，在平台上提供了开发人员直接拉取分支的功能。如上图所示，项目1和项目2同时进行开发，分别拉取了V1.0的分支。如果项目1提前开发完成，就会触发提交集成的操作，会把项目1最新的分支代码重新拉出来一个集成分支，把主干代码合成到集成分支中，针对集成分支进行编译打包，自动部署到集成的测试环境中。在集成环境运行云效的测试用例，如果没有问题就合并回主干。
持续部署方案-环境管理
每个公司都有相同的环境建设方式，包括开发环境、测试环境、集成环境。为了规避开发环境不稳定的情况，摒弃了各种环境的概念，在云效平台上划分为了公共环境和功能环境。公共环境可以认为和线上服务的环境一致，是由线上同步回来的，不需要人为手工参与部署。测试时，如上图需求1，每个项目组根据项目开发的应用在云效平台上申请一台服务器，通过云效一键部署的功能把应用部署到服务器上去，如果需要调用其他服务器，则通过服务化路由的方式路由到其他服务器上。针对每个项目组来说，他们都可以认为自己有一个独立的、供他们使用的测试环境，互相之间没有相互的干扰。对于服务化自动路由，各个系统间相互调用的方式有HTTP、RPC、HSF、Dubbo框架等，使用HTTP的话可以利用本机host绑定达到路由效果，可以使用云效平台自动托管；如果使用Dubbo和HSF，则有一些注册中心和路由规则，可以在本地部署服务器上直接生成HSF的路由文件，动态改变服务的路由。
分层自动化
在测试环节，倾向于认为没有某一种的测试方式能从效率、质量达到一个很好的平衡，涵盖所有测试的业务逻辑。如果把所有的功能都通过UI自动化实现的话，UI自动化的创建、维护成本很高，稳定性也有一定问题。建议在不同的业务层次使用不同的、适合的测试环境。在方法层面，检测方法是否有问题，可以利用单元测试来进行。接口则可以通过服务化接口测试来涵盖，再往上更长流程的业务逻辑可以通过界面自动化测试来实现。很少一部分的测试场景通过自动化的方式是没法实现的，只能通过手工的方式来实现。
单元测试
在分支上进行提交的时候，每一次后台都会及时检测到触发提交后针对最新代码的编译、单元测试、代码扫描。平台扫描的结果会及时通过邮件反馈到开发人员，相关的数据也会沉淀到系统上。在云效平台上，阻塞问题是最严重的问题，通过提示信息可以方便开发人员及时进行相关排查。
服务化接口测试
在云效平台上，所有的自动化测试都希望不写代码，直接在页面上配置，通过最直观的方式进行。接口测试方面，如果是HTTP接口，则会直接在页面上输入需要测试接口的地址、入参、出参的校验规则；如果是Dubbo或者HSF接口，则需要写单元测试用例启动一个容器才能进行相关的测试。为了减轻写单元测试的工作，在云效平台上，可以解析到某一个jar包里的接口，只需要指定针对Dubbo接口往哪一个IP服务上发送相关请求，平台会自动生成相关的一些测试用例，把入参进行传递，把出参进行校验。
云效价值——实际效果与客户案例
在阿里巴巴内部，云效平台是从2012年开始建设，当初开发测试的配比大约是3:1，到2015年提高到了6:1，目前已经接近8:1。由于业务在持续快速的发展，在平台的保障下，历年故障数有明显的下降，集成验证发布耗时也有显著缩减。有了平台上自动化工具的保证，50%的小需求不需要进行测试。也没有了发布窗口的限制，随时可以发布。
对于外部客户来说，现在使用云效的客户也有不少，比如众安保险、五矿电商、红岭创投等，主要使用的是环境部署、自动化集成、自动化用例的建设，大大提升了企业研发效率。
展开
收起
1
条回答
写回答
写回答
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
相关问答
