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

简介: 欢迎使用老司机平台,共同推进高效业务测试体验,地址:http://drivers.alibaba.net/背景老司机项目集成任务原计划为每一个项目老司机创建一个实验室,当项目环境部署时,会拉起这个实验室,然后触发老司机的项目集成任务。项目集成任务本身配置可触发的项目标,通过与实验室传递的项目标匹配以判断是否真正执行此集成任务。这里存在几个问题:如果每个项目都创建一个实验室,那么最终同一个应用上存在

欢迎使用老司机平台,共同推进高效业务测试体验,地址: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实验室,对多个项目集成任务的调用。

触发规则总结

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

变更情况

项目环境配置

触发结果

X应用+A变更+aaa项目标

X应用+aaa项目标

A变更可以触发

X应用+A变更+aaa项目标 与 X应用+B变更+bbb项目标

X应用+aaa项目标

A变更可以触发,

B变更环境标不满足,不能触发

X应用+A变更+aaa项目标 与

Y应用+B变更+aaa项目标

X应用+aaa项目标

A变更可以触发,

B变更应用名不满足,不能触发

X应用+A变更+aaa项目标 与

Y应用+B变更+aaa项目标

X&Y应用+aaa项目标

AB变更均可触发,但不可重入 如:同时触发时,首个实验室可以正常执行,后续实验室直接返回失败

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

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

#

类型

参数名称

说明

1

实验室属性

tone_job_id

实验室id,即每个实验室的唯一id 每个应用可以有多个实验室

2

实验室配置

tone_app_name

实验室配置的“被测应用/二方库”字段中填写的应用

3

tone_app_id

被测应用/二方库”的应用id

4

tone_related_app_names

实验室配置中触发策略的“关联应用”字段中填写的应用

5

tone_related_app_ids

关联应用”的应用id

6

yml_path

实验室配置的“配置文件”字段中的脚本地址

7

代码属性

repo

被测应用代码仓库地址

8

branch

代码分支

9

commit_id

提交id

10

流水线&变更属性

emp_id

触发人员工id

  • 工号(手工触发或流水线触发)
  • AK-ADMIN(系统定时触发)

11

pipeline_id

发布流水线id

12

pipeline_app_name

发布流水线应用名称

13

envType

触发执行的发布流水线的环境类型,枚举值

  • daily(日常环境)
  • project(项目环境)
  • auto-test(测试流程触发,如跨应用,预发触发自动化环境等)
  • prepub(预发环境)

14

crId

变更id

15

运行时信息

trigger_from

触发来源,枚举值

  • testone(手工触发或流水线触发)
  • internal(系统定时触发)

16

trigger_mode

触发模式,枚举值

  • 1(系统定时触发)
  • 5(触发应用非被测应用)
  • 6(触发应用为被测应用)

17

build_id

一次执行的唯一id

通过拼接tone_job_id和build_id,可以获取当次实验室执行的URL。如:https://test.aone.alibaba-inc.com/jobs/1954527?buildId=172785148

其中tone_job_id为1954527

相关文章
|
5天前
|
前端开发 JavaScript 测试技术
前端测试技术中,如何提高集成测试的效率?
前端测试技术中,如何提高集成测试的效率?
|
28天前
|
缓存 Devops jenkins
专家视角:构建可维护的测试架构与持续集成
【10月更文挑战第14天】在现代软件开发过程中,构建一个可维护且易于扩展的测试架构对于确保产品质量至关重要。本文将探讨如何设计这样的测试架构,并将单元测试无缝地融入持续集成(CI)流程之中。我们将讨论最佳实践、自动化测试部署、性能优化技巧以及如何管理和扩展日益增长的测试套件规模。
43 3
|
17天前
|
安全 测试技术 数据安全/隐私保护
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
|
28天前
|
存储 JavaScript 数据库
ToB项目身份认证AD集成(一):基于目录的用户管理、LDAP和Active Directory简述
本文介绍了基于目录的用户管理及其在企业中的应用,重点解析了LDAP协议和Active Directory服务的概念、关系及差异。通过具体的账号密码认证时序图,展示了利用LDAP协议与AD域进行用户认证的过程。总结了目录服务在现代网络环境中的重要性,并预告了后续的深入文章。
|
28天前
|
人工智能 JavaScript 网络安全
ToB项目身份认证AD集成(三完):利用ldap.js实现与windows AD对接实现用户搜索、认证、密码修改等功能 - 以及针对中文转义问题的补丁方法
本文详细介绍了如何使用 `ldapjs` 库在 Node.js 中实现与 Windows AD 的交互,包括用户搜索、身份验证、密码修改和重置等功能。通过创建 `LdapService` 类,提供了与 AD 服务器通信的完整解决方案,同时解决了中文字段在 LDAP 操作中被转义的问题。
|
9天前
|
XML 存储 Java
SpringBoot集成Flowable:构建强大的工作流引擎
在企业级应用开发中,工作流管理是核心功能之一。Flowable是一个开源的工作流引擎,它提供了BPMN 2.0规范的实现,并且与SpringBoot框架完美集成。本文将探讨如何使用SpringBoot和Flowable构建一个强大的工作流引擎,并分享一些实践技巧。
26 0
|
1月前
|
数据采集 DataWorks 数据管理
DataWorks不是Excel,它是一个数据集成和数据管理平台
【10月更文挑战第10天】随着大数据技术的发展,企业对数据处理的需求日益增长。阿里云推出的DataWorks是一款强大的数据集成和管理平台,提供从数据采集、清洗、加工到应用的一站式解决方案。本文通过电商平台案例,详细介绍了DataWorks的核心功能和优势,展示了如何高效处理大规模数据,帮助企业挖掘数据价值。
83 1
|
1月前
|
数据采集 SQL DataWorks
DataWorks不是Excel,它是一个数据集成和数据管理平台
【10月更文挑战第5天】本文通过一家电商平台的案例,详细介绍了阿里云DataWorks在数据处理全流程中的应用。从多源数据采集、清洗加工到分析可视化,DataWorks提供了强大的一站式解决方案,显著提升了数据分析效率和质量。通过具体SQL示例,展示了如何构建高效的数据处理流程,突显了DataWorks相较于传统工具如Excel的优势,为企业决策提供了有力支持。
88 3
|
28天前
|
安全 Java 测试技术
ToB项目身份认证AD集成(二):快速搞定window server 2003部署AD域服务并支持ssl
本文详细介绍了如何搭建本地AD域控测试环境,包括安装AD域服务、测试LDAP接口及配置LDAPS的过程。通过运行自签名证书生成脚本和手动部署证书,实现安全的SSL连接,适用于ToB项目的身份认证集成。文中还提供了相关系列文章链接,便于读者深入了解AD和LDAP的基础知识。
|
4月前
|
监控 druid Java
spring boot 集成配置阿里 Druid监控配置
spring boot 集成配置阿里 Druid监控配置
287 6