蚂蚁金服 30 万级测试用例的核心应用如何分钟级运行？

治理效果：

一个核心应用之前是 1 万用例运行需要 90 分钟，优化后 30 万用例只需要 30 分钟。这不是一个特例，我们将这一套机制在内部推广，平均提速达到 30% 以上，对用例数多的应用提效尤其明显。

解决问题三：用例生成

大家可能会有一个疑问，30 万级用例是可以分钟级执行了，通过率也稳定了。可是这么多的用例是怎么生成的呢？用例的编写是开发人员一个很大的挑战，面对枯燥重复的工作，需要耗费很长的时间。

于是我们想有没有办法根据线上的流量自动生成呢？通过中间件插件的方式将线上的流量数据采集下来发送到数据总线，数据总线对线上流量做数据分析和特征提取，落库到线上特征库。通过线上特征库与存量用例特征库的对比得出特征差异库，对特征差异库再进行筛选、提取和脱敏生成新的用例再补充道用例库中。通过这种方式循环，不断生成新的用例，最终达到了 30 万级用例的规模。

应对又稳又快——CI 架构演进

在对执行用例这一环节不断优化改进的同时，我们的 CI 架构也进行了演进。主要是为了应对之前说的研发模式变更带来的任务量激增的冲击，以及满足对 CI 平台本身稳定性的要求。

架构 0.1 – 1.0

在初始的时候，任务量较小，用例也不多。CI 可以说是没有架构的，可以称为架构 0.1，我们只是简单的搭建了一个 Jenkins 的集群。后来由于研发模式的变化，搭建了多套 Jenkins 集群，并将多个 Jenkins 集群抽象为 CI 的执行层 ACI-Executor。多套 Jenkins 集群一方面提升了 CI 平台的任务吞吐量，使其具备了大量任务并行的能力，另一方面也保障了 CI 平台的稳定性，不再依赖单个 jenkins 集群的健康度。

有了执行层的集群，就需要对任务进行调度和编排，以及对集群本身的管理、监控等。于是在执行层之上又增加了调度层 ACI-Core。最后在调度层之上建设业务层，对 API 进行封装，暴露给外围的 DevOps 平台 LinkE、代码托管平台 AntCode 等系统使用，同时响应定时、PR、Push 等事件，转换任务模板，展示执行完成后的报告等，整个架构演进到 1.0。

这个架构看起来是比较完整了，在实际使用中，我们发现两个新问题：1、CI 任务高峰期排队，低谷期 CI 机器闲置。2、新语言、新的技术栈、中间件版本要求环境多样化。

架构 2.0

为了解决这两个问题，对执行层和调度层做了进一步的演进，也就是架构 2.0。在执行层引入 Kubernetes 和 Docker，一方面借助 Kubernetes 的容器编排能力削峰填谷，另一方面通过 Docker img 定义不同的环境，应对多语言、多技术栈版本的要求。在调度层引入 Tekton 对接 Kubernets，编排 Pipeline。

总结——未来 CI 的关键词

蚂蚁金服将持续对 CI 进行探索和实践，未来的发展将围绕以下四个关键词：效率、云原生、中台能力、智能化。

1. 效率，对我们的软件生产活动有最直接的提速效果，或许能够使用更精细的调度、编排，目前还没有做到用例级别，还只是测试方法级别，如果未来能够做到用例级别，可能会有更多的调度玩法。另外在 CI 中集成测试和编译打包两个环境都有编译的动作，能不能让集成测试复用编译的结果，在编译结果的基础上执行测试用例呢？这样又可以省掉一次编译的消耗。

2. 云原生，主要围绕对测试执行环境的支持，测试资源的动态扩缩容、以及测试环境的快速准备。甚至还包含了开发同学能够在本地运行测试时，能够快速的拉起一个与 CI 一样的测试环境，进行验证。避免由于本地与 CI 环境的差别造成的测试结果、覆盖率等的不一致。

3. 中台能力，为什么要讲中台能力？因为我们发现，业务团队自己也常会做一些针对自己业务系统的提速或优化工具。这些工具应该能够非常便捷的集成到 CI 平台上，能够复用 CI 平台的任务编排、执行、输入输出、日志、产物等公共能力。更进一步能够与 CI 平台本身所做的优化形成合力，更有效的提升生产效率。

4. 智能化，可以用在用例自动生成、用例推荐上。通过建立业务模型，对它进行训练，从而得到更全面、有效的用例，从而进一步节省我们生成用例的时间。

期望从这四个点发力，使 CI 能够更快、更灵活、更开放、更智能，解放开发同学的生产力！

 作者介绍 

杨超（空弦） ，先后在华为、蚂蚁金服担任过系统工程师、技术专家等岗位。曾多次主导和参与大型分布式CI系统的设计和开发，分别应用于传统运营商软件、Android系统、金融服务等场景，擅长CI提效及稳定性提升，在DevOps、CI/CD 领域经验丰富。目前在蚂蚁金服-研发效能部担任技术专家，负责CI、Pipeline中台建设。

长按识别二维码关注我们