| 编辑推荐: |
本文介绍持续集成与持续交付的背景，以及阿里自己对持续集成与持续交付的理解。分享阿里持续交付解决方案的演变过程，和阿里巴巴B2B做持续交付的实践。还有持续集成与持续交付中的自动化，希望对您的学习有所帮助。
本文来自于搜狐，由火龙果软件Delores编辑推荐。 |
|
一、持续集成与持续交付的背景
首先来看什么是持续集成。大师Martin Fowler，敏捷开发方法的创始人之一，提出的敏捷开发方法是一种思想，可以为软件的研发提供指导性的建议。而持续集成则是敏捷开发具体实践的一个建议环节，通过这个环节可以在研发过程中快速得到代码质量的反馈。Fowler对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，部署，自动化测试)来验证，从而尽快地发现集成错误。自动化构建验证可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
从下图我们可以更好的理解持续集成的工作模式，就是开发人员将代码check in到source repository代码仓库以后，CI Server，也就是持续集成服务器，会对代码工程进行工程编译，静态扫描，单元测试，组件接口测试以及安全扫描等等一些列构建工作，最终产生一份报告反馈给开发人员。可以看到如果针对每次check in做集成，这个集成的频率会非常高，特别是对于有一定研发团队规模的公司，至少我们自己团队以前在业务压力比较大，涉及模块比较多的时候，可能提交得比较频繁，甚至在未正式进行提交测试之前，连编译不通过的代码也可以提交。可以根据集成的耗时来设置不同的集成频率，比如说工程编译、静态扫描、单元测试都会比较快等，对他们设置集成的频率可能就会比较高，而对于需要部署并执行更多的自动化，耗时就会更多些，集成频率就会更低一些，注意这里的部署都会是在集成服务器上来完成的，是比较轻量级的启动，并没有进行真实环境的部署。无论以哪种频率集成，其实都希望它能够快速、准确并且稳定地完成。快速反馈就是敏捷所提倡的，而真正大规模的持续集成，如果不够准确稳定，开发人员就会疲于处理报告中的问题，而集成服务器压力也会非常大。
再来看一下持续交付的背景，持续交付(Continuous Delivery)是一系列的开发实践方法，用来确保让代码能够快速、安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，来确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，开发者只需要按一次按钮就能将应用安全的部署到产品环境中。
从下图大家也能看到持续交付和持续集成的区别，其实持续交付包含了持续集成的过程，额外还需要将程序的包真正部署到模拟产品环境的服务器上，进行更为严格的自动化测试，可能有UI交互级别的自动化，有远程服务接口级别的自动化等。持续交付并不是指软件每一个改动都要尽快的部署到产品环境中。它指的是任何的修改都已证明可以在任何时候实施部署。
既然持续交付包含了持续集成，后面就针对持续交付做进一步的分享。
本次分享对持续集成与持续交付的定义：在24小时系统中任何应用（一个应用就是一个可部署的包）随时提交发布并在较短时间内(1-2小时)完成独立验证并发布上线，而没有发布窗口限制。
从图中可以看到，从应用代码变更到测试环境部署验证，再到集成环境或者准生产环境部署验证最后再到生产环境，我们期望通过自动化进行快速进行发布。这其中的两个方案非常的重要，一个是集成环境自动化部署的解决方案，无论面对多大规模的系统，如果想要单独快速的发布一个应用，并且对这个应用进行有效的验证，集成测试环境的自动化部署方案就非常重要，现在的系统往往都会涉及到几十个应用，如果每次集成都需要全部部署，验证所有功能，1到2小时肯定是无法完成的。另外对于分层自动化测试的解决方案，同样的要求就是需要分层自动化能快速有效的对要发布的应用进行验证，并且需要非常高效。自动化的天敌就是变更或者变化，一旦有变化就需要对自动化进行维护，如果采用传统编写脚本的自动化方案，开发人员往往要维护大量的脚本，另外要做持续交付迭代就会非常的快，并且变化也大，自动化解决方案需要跟得上快速迭代变化的节奏。
二、持续交付解决方案的演变
在大致了解背景后，来看一下阿里巴巴持续交付解决方案的演变过程以及阿里B2B的一些实践经验。
相比传统工业的工程，软件工程诞生得比较晚，所以当软件工程规模化之后，也会参考传统行业的工程流程，通过瀑布式的流程及相关变形的研发模式，来协同软件工程项目中各个角色。这样的流程有一个非常明显的缺点就是一次项目发布周期非常长，存在非常多的环节，并且每一个环节都会有严谨的评审来保障这一环节的质量。
企业研发模式的变迁
自从互联网诞生起，特别是B/S的模式通过浏览器统一了客户端之后，软件的发布只需要发布服务端就可以快速提供服务，传统瀑布研发模式逐渐无法支撑互联网所需要快速发布，所以软件研发模式逐步演进到了敏捷研发模式。敏捷研发模式弱化了流程，强调了沟通与反馈，在实践的时候我们发现在小规模团队中敏捷研发运作还可以提升效率，但是在较大规模团队中仿佛就失去了它应有的一些光彩，如果一个100-200人研发团队的公司在全体实施敏捷而没有相关工具支撑的话，相互的协同、沟通以及研发测试工作反而会更耗时，同时也无法召开100到200人的敏捷会议。所以基于此我们演进到了持续交付的模式，持续交付强调用户的反馈和体验，开发者希望能将产品尽可能快地交付到客户手中。
瀑布式研发模式
大家在刚加入工作时，主管会让你背一张图，也就是项目工程图，这张图包含了软件瀑布式研发模式的各个环节。从需求分析到用例建模再到需求评审，之后软件开发工程师会介入进行概要设计，测试同学也会介入进行测试分析，将用例模型转化成测试模型，之后就可以进入开发的编码阶段，编码完成之后就会交给测试人员进行测试，测试完成之后会进行发布评审之后还进行预发布，发布之后还要进行发布的跟踪。所有的这些工作都是通过邮件和文档以及各个工具的平台支撑的，因为每个过程都要依靠文档，当某些地方发生变化的时候，需要文档迭代发布非常迅速，因为业务也需要小步快跑，所以文档也会在各个人员之间传来传去，项目流程进度、人力资源把控、项目质量保证等所有活动全靠人肉（通讯基本靠吼）。
敏捷研发模式
在2010年以后，我们开始尝试敏捷研发模式。敏捷研发模式，就是某一个小团队针对客户市场会调研出一些需求，之后会对这些需求进行快速的迭代跟进，产品负责人会根据产品的创意、功能以及需求做成一个产品功能列表，小团队会针对这样的一个功能表进行迭代任务的拆分和研发实施。实施的过程基本上就是通过小团队进行每日例会以及其他方式的沟通进行协作，提交代码之后也会进行一些集成，集成完成之后，代码就会形成一个可部署的包，之后就可以发布到线上，这样小团队就可以敏捷地实现小块的业务。
我们在探索敏捷研发过程时也遇到了一些问题，将一个小团队的最佳实践推广到其他团队的时候往往就会遇到非常多的阻碍。比方说一个需求可能涉及到许多团队进行协同开发，这个项目的规模可能涉及到上百人，但是对于几百人想要实现敏捷开发中的每日例会将是不可能的事情。另外一个问题就是敏捷部署，对于小团队而言，程序可以非常容易地在自己团队的机器上进行部署，但是对于大型项目而言，往往在联调的时候需要很多团队进行协作，需要保证参与各方的环境都是稳定的，这种场景下敏捷研发模式往往不能发挥出其优势。
持续交付的演变-阶段1
虽然敏捷研发在较大规模情况下难以实施，但还是可以依靠平台进行持续交付的。下图是大多数公司采取的大型的集成方案，在这个方案中会设定一个固定时间的窗口，代码会从开发环境到集成测试环境，通过一整套集成测试的验证之后将程序发布到生产环境。但是会因为发布周期比较长，导致研发速度比较慢。可以看到，图的左边是一个个研发的代码分支，每天都会有新代码进行集成合并，合并完成之后会约定时间手工部署到集成测试环境上去，之后对于整套环境进行手工测试验证。当然，在这其中还会有许多的自动化测试脚本去进行验证。图中集成测试环境下的各个代码分支之间的连线代表需要这几个分支共同提供服务才能进行自动化的验证。所以这样的集成测试方案必然会对于发布时间进行限制，需要将全部的内容都验证通过之后才能进行统一的发布。
这样就出现了一些问题：
研发迭代速度慢，业务发布周期长。
集成测试环境不稳定，每天都会有新代码合并进来，并且还会有紧急需求代码的穿插，难以得到有效验证。
测试效率低，负责需求的测试随时可能被冲掉，因此每次更新都需要全部测试一遍。
自动化测试脚本的误报率高，由于执行全网回归脚本多，回归时间长，排查问题难。
持续交付的演变-阶段2
因为集成环境还是不稳定，所以可以在其上增加多套测试环境。在持续交付的演变的第二阶段，就在集成测试之前加上了项目需求测试环境。只有在通过了项目需求测试之后才能够进入到集成测试环境，而后面的整体流程不变，如此可以保证集成测试环境的稳定性。但是与此同时测试环境就更加复杂，不仅要不断验证集成测试环境中代码的质量，还需要保证项目需求的质量，所以说在第二阶段也只是保障了集成测试环境的稳定性，并没有解决发布窗口的时间限制，可能还是需要进行全网回归测试。
持续集成与持续交付的关键点-自动化测试的解耦
持续集成与持续交付的关键点就是自动化测试的解耦。测试某个场景确实需要一些环境都部署好的时候，如果想要快速迭代发布就需要运行全网的回归测试。但是通过自动化测试的解耦方式就会好很多，比方说需要将全网的场景都耦合起来进行测试，为了保证环境的稳定，可以从应用的维度去解耦自动化的脚本，这样就可以将自动化测试定义成为套件。
云效-持续交付实现原理
为什么云效平台能够做到所有应用随时提测并发布，并且无发布窗口限制呢？其实是因为我们拥有预发布集成测试环境，在半个小时内就能完成自动化测试并且不需要人员进行值守。举例说明，如果自动化测试套件解耦的效果比较好的话，比方说某个测试套件只测试ABCD四个套件，这四个套件作为一个小组。如果此时某个项目改动了C，之后就会在集成环境进行自动部署，部署完成之后会锁定ABCD发布队列，当集成测试和手工验证通过之后才会将C发布到正式的生产环境，其他的分组的处理流程也是一样，不需要进行全网回归，而且只有小组内的模块变化时需要进行排队变更，这样的运行时间也会大大缩短，基本上没有任何的发布窗口的限制，可以实现随到随发。
对于自动化测试环境的核心点，比方说在部署ABCD四个测试套件的环境的时候，如何保证测试环境和生产环境是一样的呢？首先对于环境类型管理，测试环境可以人工一键自动部署，核心部分存在公共环境，这个公共环境的部署包是与生产环境的包保持一致的，并且这个公共环境没有人员进行手工部署，而是进行自动部署的。对于项目环境的部署而言，项目环境的部署是从动态服务器资源池动态地获取服务器资源，之后进行动态的一键部署，这个过程有可能会依赖公共环境，而公共环境与生产环境的包的一致能确保测试的有效性，对于分圈应用也是一样的。
这里当然也会存在一些问题需要解决，目前互联网上往往会有一些远程服务化的方案，假如ABC之间是存在依赖的，A需要调用B的服务化接口，B也要调用C的服务化接口，而对于默认部署的公共环境而言，A将会调用公共环境的B进而调用公共环境的C，当需求中改变了A，此时会向动态服务器资源池中申请一台服务器来部署A'，当需要时A'会连接公共环境的B和C，这样在发布时不改动其他只改动A就可以了。而对于另外一种场景就是同时修改了ABC，但是由于服务框架的负载均衡会导致项目环境无法进行有效的测试。在整个核心解决方案中，存在一个服务化的自动路由，这样就可以保证项目内部调用的有效测试。
三、自动化验证—创新高效的自动化支撑
在互联网时代，对于网站而言，页面的变化是非常快的，这时候就需要高效的自动化测试进行支撑。
那么自动化测试到底是不是银弹呢？在业界有一个这样的自动化测试的金字塔模型，可以看到从顶层的用户界面的测试，到API层面的验收测试再到单元测试和组件测试。在金字塔模型中越往下的成本就越低，同时的效率也就越高，并且缺陷也就越容易定位；而从下向上则越来越接近业务，越来越能反映真实的需求。如果UI自动化测试工具的成本和效率比单元测试更低的话，在测试层面可以做成倒三角模型，使得用户界面层测试既贴近用户需求和业务也能够非常的高效，所以需要创新高效的工具支持测试的自动化的实现。
接下来分享一下阿里在自动化测试产品方面的创新。对于自动化测试而言，会存在自动化成本。这个自动化成本=脚本创建成本+维护次数×维护调试成本+脚本失败次数×脚本排错成本，而自动化收益=有效迭代次数×手工测试成本。业界通常通过录制生成脚本代替手工编写脚本，但是也同时出现了一些问题，就是录制生成脚本是由机器自动产生的，不同团队之间写作和维护成本也会很高。所以我们得出一个结论，通过写脚本的方式是无法收回持续集成测试的成本的。
而通过云效-AUI录制代替写脚本的方式，就避免了团队之间的代码互相维护以及由于业务逻辑的不熟悉造成的困扰，这样可以很清楚地让团队之间看到每个案例是怎样的，可以在短短几分钟之内就完成对于脚本代码的维护。云效AUI产品解决了以往UI自动化测试成本高，难维护的核心问题，提升了效率，并且解决了一次录制，多浏览器执行的问题。
回想刚才的金字塔，如果工具能帮助我们投入较小的成本来保证更高的质量，那么就没有必要一定要构建这样的金字塔的模型。
从项目一生看持续集成的调度，当有项目需要开发，可以在云效平台上拉一个变更的分支，在平台上还可以添加项目开发成员。之后就可以对于该分支进行开发编码，以及代码的提交，在完成代码提交之后几分钟之内就会收到一封关于项目代码情况的邮件提醒，包括单元测试的构建结果以及覆盖率等代码的详细情况都会反馈给提交者，这样就减少了单元测试的成本，并且由于不依赖本地环境使得单元测试的复用成本降低，而且提供了数据采集的看板，可以很方便地看到团队自己的测试数据。
在完成质量测试之后，云效平台还提供了一键部署的环境，并且可以实时查看部署的日志。云效平台还提供了制造数据的功能，当环境部署成功之后可能需要一些数据来支撑测试，所以云效平台提供了数据银行来制造数据，并且提供了丰富的制造数据的方式。而且对于数据制造而言，不光是自动化测试需要，手工测试也需要。另一方面，云效平台的用例系统和普通的用例系统有所不同，云效平台的用例系统会区分主干用例和项目用例，这与互联网分支开发模式有些类似，存在一个稳定的主干，当有新的业务需求之后，往往会通过新的分支进行开发。对于用例系统而言，往往会有一些很核心的业务，基本上不会有太大的改动，所以对应的就会有一些主干用例，在项目中可以复用，而对于项目中新产生的用例则可以在项目发布之后可以归库以方便其他人使用。
可以看到整个持续集成调度平台Amon，日构建集成能够达到10万+，并且拥有大量的节点，可以支撑大规模的集成模块。
通过看板可以看到一个应用的整个集成自动化发布过程，这样的集成自动化给了开发人员极大的信心。
有了平台支撑之后，整个持续集成和持续交付的研发工作有了很大的转变。
下图是在阿里巴巴内部整个宙斯盾平台落地的效果，可以看到研发测试比逐年提升，目前基本上达到了1:7.5，这样更多的开发资源可以投入在产品研发上，来支撑业务快速发展。测试资源通过高效的自动化工具产品，提供分层自动化测试套件进行自动集成。目前50%的需求会由测试接手进行一些手工的测试，而另外的50%则是由开发人员进行的自测，因为平台已经提供了非常方便和快捷的研发测试方式，很多功能只需要一键部署申请，所以对于开发人员而言测试工作也是非常简单和高效的。而业务技术团队只需要判断是否需要测试人员接手人工测试。对于测试同学而言的要求是可以有不经过手工测试的需求发布上线，但是不能没有质量数据监控的需求发布上线，这些数据都将在发布前上传到云效平台上。虽然测试人员的比重并没有增加，但是线上故障逐年下降，并且质量有所保障，业务发布频率也是飞速增长。
四、云效产品架构及应用架构
宙斯盾对外输出称为云效平台。云效平台提出了一个理念就是产品需求研发闭环，其实云效平台的目标并不在于一定要去支撑敏捷开发，因为云效平台不是一个单纯支撑敏捷开发的工具，因为对于一些规模比较大的团队而言，敏捷开发方式可能比较难以实施，其实云效平台想做是持续交付。想要实现持续交付的一个理念就是实现产品需求和研发的闭环，从需求开始可以依靠平台进行快速的创建和审批，再到对于项目和任务的管理，如此形成产品的闭环。在开发阶段，云效平台会提供一些配置管理的工具去支撑，之后会有代码集成和环境管理解决方案，发布前会提供一些自动化集成工具，可以通过不编写脚本实现快速迭代，只需要填写几个数据就可实现校验，另外在测试数据方面还提供数据银行制造数据。在测试阶段，云效平台还会提供用例的管理以及缺陷的管理和一些创新的自动化测试工具。在发布阶段，平台还提供集成自动化产品实现回归测试，以及由平台支撑持续交付。在最后的总结阶段，可以通过整个平台收集的数据对商业结果以及项目进行度量，并且可以进行故障分析。
细化到产品的架构，可以看到产品架构也是形成一个闭环。在产品架构中存在一个指挥官的角色，从需求管理到立项管理再到资源和配置管理。在开发完成之后，会提供单测集成和环境管理，在手工测试方面也会提供用例管理和缺陷管理，在分层自动化方面将会提供分层自动化测试的工具，最终汇合到集成自动化，进而进行线上发布。
云效的应用架构
整个云效平台的部署结构也是解耦的比较清楚的，会分为前台业务和中台业务等，可以做到产品独立部署的服务。
云效平台不依赖于任何操作系统，只要支持docker容器就可以进行自动部署到企业的内部。
并且云效平台具有很多的核心技术，拥有的理论、技术实现细节专利达到了50余项，核心的就是持续集成的系统和方法。
五、云效解决方案及案例分析
接下来分享一下云效的解决方案和真实的案例。
其实刚才也提到了，云效方案是由许多个模块组成的，这样就可以自由组合模块形成解决方案。比方说可以从需求分析开始到最终的集成自动化形成一套完整的产品研发闭环的解决方案。如果没有很多的需求，也可以从需求池开始形成需求研发的闭环。如果觉得单测集成或者UI自动化有比较多的创新点的话，也可以形成分层自动化的完整解决方案。
接下来分享一个真实的案例，众安保险是国内首家互联网保险公司，同时也是云效平台的早期客户。
基于上图对于众安保险的集成开发的痛点和研发背景的分析，云效平台为众安保险提供的解决方案就是将众安已有的平台和云效服务之间进行打通。众安方面具有自己的配置管理平台、运维发布平台和自建的数据银行，而云效平台则通过接口提供云集成、部署和测试的服务，并且提供UI自动化和接口自动化方案，这样方案就帮助众安建设完成了持续集成的通道并且实现了核心功能。
|
