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

简介: 欢迎使用老司机平台,共同推进高效业务测试体验,地址: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

相关文章
|
2月前
|
机器学习/深度学习 Python
堆叠集成策略的原理、实现方法及Python应用。堆叠通过多层模型组合,先用不同基础模型生成预测,再用元学习器整合这些预测,提升模型性能
本文深入探讨了堆叠集成策略的原理、实现方法及Python应用。堆叠通过多层模型组合,先用不同基础模型生成预测,再用元学习器整合这些预测,提升模型性能。文章详细介绍了堆叠的实现步骤,包括数据准备、基础模型训练、新训练集构建及元学习器训练,并讨论了其优缺点。
81 3
|
5天前
|
人工智能 数据挖掘 API
R2R:开源的 RAG 集成系统,支持多模态处理、混合搜索、知识图谱构建等增强检索技术
R2R 是一款先进的 AI 检索增强生成平台,支持多模态内容处理、混合搜索和知识图谱构建,适用于复杂数据处理和分析的生产环境。
52 3
R2R:开源的 RAG 集成系统,支持多模态处理、混合搜索、知识图谱构建等增强检索技术
|
20天前
|
人工智能 数据可视化 JavaScript
NodeTool:AI 工作流可视化构建器,通过拖放节点设计复杂的工作流,集成 OpenAI 等多个平台
NodeTool 是一个开源的 AI 工作流可视化构建器,通过拖放节点的方式设计复杂的工作流,无需编码即可快速原型设计和测试。它支持本地 GPU 运行 AI 模型,并与 Hugging Face、OpenAI 等平台集成,提供模型访问能力。
96 14
NodeTool:AI 工作流可视化构建器,通过拖放节点设计复杂的工作流,集成 OpenAI 等多个平台
|
6天前
|
运维 监控 Cloud Native
构建深度可观测、可集成的网络智能运维平台
本文介绍了构建深度可观测、可集成的网络智能运维平台(简称NIS),旨在解决云上网络运维面临的复杂挑战。内容涵盖云网络运维的三大难题、打造云原生AIOps工具集的解决思路、可观测性对业务稳定的重要性,以及产品发布的亮点,包括流量分析NPM、网络架构巡检和自动化运维OpenAPI,助力客户实现自助运维与优化。
|
27天前
|
DataWorks 数据挖掘 大数据
方案实践测评 | DataWorks集成Hologres构建一站式高性能的OLAP数据分析
DataWorks在任务开发便捷性、任务运行速度、产品使用门槛等方面都表现出色。在数据处理场景方面仍有改进和扩展的空间,通过引入更多的智能技术、扩展数据源支持、优化任务调度和可视化功能以及提升团队协作效率,DataWorks将能够为企业提供更全面、更高效的数据处理解决方案。
|
1月前
|
机器学习/深度学习 自然语言处理 监控
智能客服系统集成技术解析和价值点梳理
在 2024 年的智能客服系统领域,合力亿捷等服务商凭借其卓越的技术实力引领潮流,它们均积极应用最新的大模型技术,推动智能客服的进步。
80 7
|
2月前
|
消息中间件 Java Kafka
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
Spring Boot 与 Apache Kafka 集成详解:构建高效消息驱动应用
59 1
|
3月前
|
Java Maven Docker
gitlab-ci 集成 k3s 部署spring boot 应用
gitlab-ci 集成 k3s 部署spring boot 应用
|
2月前
|
消息中间件 监控 Java
您是否已集成 Spring Boot 与 ActiveMQ?
您是否已集成 Spring Boot 与 ActiveMQ?
61 0
|
6月前
|
监控 druid Java
spring boot 集成配置阿里 Druid监控配置
spring boot 集成配置阿里 Druid监控配置
330 6

热门文章

最新文章