【老司机平台技术】构建应用级项目集成任务通用实验室

欢迎使用老司机平台，共同推进高效业务测试体验，地址：http://drivers.alibaba.net/

背景

老司机项目集成任务原计划为每一个项目老司机创建一个实验室，当项目环境部署时，会拉起这个实验室，然后触发老司机的项目集成任务。项目集成任务本身配置可触发的项目标，通过与实验室传递的项目标匹配以判断是否真正执行此集成任务。

这里存在几个问题：如果每个项目都创建一个实验室，那么最终同一个应用上存在的实验室数量非常多，进一步导致每次项目环境部署时拉起多个实验室，需要请求老司机后，由老司机判断不执行任务再关闭实验室，不仅消耗实验室、老司机的机器成本，也非常耗时。

除了上述的设计路线与成本问题外，我们在实施过程中又发现了一个真正的阻断性的问题，目前AONE已经不支持通过API等方式自动创建实验室（成本问题），实验室仅支持用户手工创建。所以上述方案肯定是无法实现的。

回到原始的需求重新分析，我们核心的需求点是AONE项目环境触发实验室后，拉起对应的老司机项目集成任务。AONE流水线触发行为，可以通过为每个我们关注的应用手工创建一个实验室来解决，接下来拉起对应的项目集成任务，是完全可以由老司机后台路由的。这里的核心要点就是通过AONE实验室传递的项目标与集成任务指定的项目标进行匹配，只拉起真正需要的项目集成任务，而无需拉起其他任务。

设计

基本流程与匹配触发条件

AONE实验室配置为项目环境触发后，应用的项目环境部署时会触发这个实验室，同时会将本次变更的信息，如变更id(crId)、项目标(aoneEnv)、实验室应用(tone_app_name)、代码分支(branch)、提交id(commit_id)等信息带到老司机的集成任务拉起接口中，由老司机对具体拉起的任务做决策路由。

具体来说，我们使用三个字段，来做实验室与不特定项目集成任务的匹配。

应用匹配：AONE实验室可配置一个被测应用和多个关联应用，老司机项目任务可以配置多个触发应用。基于上述方案描述，我们认为这类实验室是应用级的，仅应当服务于同一个应用，因此在AONE实验室配置中，我们仅考虑配置一个被测应用的情形。当aone实验室传入的被测应用在任务配置的应用列表之内时，认为匹配成功。

环境标匹配：老司机项目任务可以配置多个环境标，当aone实验室传入的环境标在任务配置的环境标列表之内，认为匹配成功。

变更crid匹配：老司机项目任务可以配置多个crid，aone实验室也可以传入多个crid。当aone实验室传入一个crid时，只要这个crid在任务配置的crid列表之内，认为匹配成功；当aone实验室传入多个crid时，需要这一组crid均在任务配置的crid列表之内，才认为匹配成功

仅当应用匹配且环境标匹配，或应用匹配且变更crid匹配时，才会由实验室拉起项目集成任务。

当有多个项目集成任务匹配时，我们仅拉起第一个项目集成任务，这是因为一个实验室只能映射到一个集成任务，关联这一个集成任务的执行状态与执行结果。

需要注意的是，这里的匹配条件不再包含实验室关联主干任务时使用的taskId，因为一个应用会有多个变更，A变更需要关联到a项目任务中，B变更需要关联到b项目任务中，使用固定的taskId则会绑定到固定的项目任务中，是不符合预期的。

基于此，设计使用这个字段作为通用实验室触发项目集成任务匹配的标识字段：当taskId填0时，则在对应的环境组(线上或线下)中按照上述匹配规则，找到可触发的项目集成任务。

多个变更部署触发同一个项目集成任务

按照上述规则，我们为项目集成任务配置多个应用或多个项目标签时，就可以由多个变更在部署项目环境时触发本集成任务。但是如果有多个变更同时调用同一个项目集成任务时，集成任务应当允许重入吗？

这里我们可以先分析项目集成任务在同时接到多个拉起请求时，可以做的响应有哪些：

• 允许自由重入：后请求的实验室，完全不感知前一次执行的影响，直接继续执行。这样的好处是各个项目都可以无感使用老司机的项目集成任务，但问题是两个项目AONE实验室拉起同一个项目集成任务是，就说明他们在共用同一个项目标，这样就会访问到同一台项目机器上。这样难免就会产生预期外的影响，影响测试件执行的正确性和有效性。
• 排队等待：后请求的实验室，排队等待前边的请求完成后再执行。这样可以完全保障两个项目实验室串行执行，项目机器与集成任务不会同时被多个实验室请求占用。但问题是老司机目前没有给集成任务请求做排队的能力，需要对集成任务调度做完全的重构，技术成本较高。
• 完全拒绝重入：后请求的实验室，直接返回执行失败。这个方案初看比较粗暴，但首先可以保障项目机器和集成任务不会被同时请求，其次如果结合AONE实验室的失败自动重跑的能力，那么则可以间接的实现排队等待方案的效果，且老司机侧的集成任务调度完全无需改动。

综合上述分析，我们最终采用直接拒绝同一个项目集成任务被多个AONE实验室拉起，但同时也需要AONE实验室做出相应的重试配置。

一个应用内的多个变更部署触发多个项目集成任务

接前述规则，如果同一个应用内的多个变更分别使用不同的项目环境标，来拉起多个老司机项目集成任务，理论上应当是完全不受影响的。这种情况下，我们发现即使每个应用仅使用同一个AONE实验室，也是能满足的。举例来说，两个变更在部署后分别拉起AONE实验室，由于传入的项目标不一致，那么每次AONE实验室执行时，都会请求到不同的项目集成任务，这样就实现了一个AONE实验室，对多个项目集成任务的调用。

触发规则总结

综合上述分析，我们列出了各种变更情况与项目环境配置情况的组合下，对项目环境的触发结果。

附录：AONE实验室提供的部分参数

基于AONE实验室开发插件时，我们可以通过实验室的各类参数感知触发实验室时的各种环境信息，如流水线信息、应用信息、触发者信息等。通过这些信息，插件或后端均可以对实际的触发执行进行过滤与判断。