一种持续集成流水线的执行方法和装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种持续集成流水线的执行方法和装置。

背景技术

目前，持续集成(Continuous Integration，CI)是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建来验证，从而尽早地发现集成错误。整个持续集成包含三步：编译、发布、自动化测试。现有持续集成流水线执行失败后，只能从头执行，效率低，用户体验较差。

在实现本申请过程中，发明人发现现有技术中至少存在如下问题：

现有持续集成流水线执行失败后，只能从头执行，效率低，用户体验较差。

发明内容

有鉴于此，本申请实施例提供一种持续集成流水线的执行方法和装置，能够解决现有的持续集成流水线执行失败后，只能从头执行，效率低，用户体验较差的问题。

为实现上述目的，根据本申请实施例的一个方面，提供了一种持续集成流水线的执行方法，包括：

执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点；

确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表；

基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。

可选地，在执行流水线之前，方法还包括：

获取执行成功节点的源代码，分析源代码得到类信息；

以类信息为顶点，生成有向图。

可选地，确定失败节点，包括：

基于有向图确定共用节点；

响应于确定对共用节点执行失败或未执行，将所有共用共用节点的树节点均确定为失败节点。

可选地，确定失败节点，包括：

确定流水线中各节点所对应的类信息；

响应于确定流水线中的多个节点共同调用同一个类信息，当一个节点执行失败时，确定多个节点为失败节点。

可选地，确定未执行节点，包括：

获取执行流水线中的各节点后的执行日志信息；

解析执行日志信息，进而基于有向图，确定未执行节点。

可选地，解析执行日志信息，进而基于有向图，确定未执行节点，包括：

解析执行日志信息，以确定对应代码中的类信息与行信息；

基于有向图和类信息与行信息，确定执行过的有向图节点；

基于执行过的有向图节点和有向图的所有节点，确定未执行节点。

可选地，在基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点之前，方法还包括：

对更新的测试入口标识列表中的各入口标识对应的各流水线节点进行重试审批，响应于确定重试审批通过，基于测试入口标识列表，执行对应的重新组装的执行节点信息。

可选地，对更新的测试入口标识列表中的各入口标识对应的各流水线节点进行重试审批，包括：

确定测试入口标识列表中各测试入口标识对应的工作流；

将测试入口标识列表、执行配置信息和对应的工作流发送至预设审批节点进行重试审批。

可选地，在更新测试入口标识列表之前，方法还包括：

修改未执行节点的配置信息。

可选地，在流水线中的各节点全部执行成功之后，方法还包括：

聚合执行成功后的流水线中的各节点信息，生成新的流水线执行节点。

另外，本申请还提供了一种持续集成流水线的执行装置，包括：

失败节点确定单元，被配置成执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点；

更新单元，被配置成确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表；

执行单元，被配置成基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。

可选地，持续集成流水线的执行装置，还包括有向图生成单元，被配置成：

获取执行成功节点的源代码，分析源代码得到类信息；

以类信息为顶点，生成有向图。

可选地，失败节点确定单元进一步被配置成：

基于有向图确定共用节点；

响应于确定对共用节点执行失败或未执行，将所有共用共用节点的树节点均确定为失败节点。

可选地，失败节点确定单元进一步被配置成：

确定流水线中各节点所对应的类信息；

响应于确定流水线中的多个节点共同调用同一个类信息，当一个节点执行失败时，确定多个节点为失败节点。

可选地，更新单元进一步被配置成：

获取执行流水线中的各节点后的执行日志信息；

解析执行日志信息，进而基于有向图，确定未执行节点。

可选地，更新单元进一步被配置成：

解析执行日志信息，以确定对应代码中的类信息与行信息；

基于有向图和类信息与行信息，确定执行过的有向图节点；

基于执行过的有向图节点和有向图的所有节点，确定未执行节点。

可选地，持续集成流水线的执行装置还包括审批单元，被配置成：

对更新的测试入口标识列表中的各入口标识对应的各流水线节点进行重试审批，响应于确定重试审批通过，基于测试入口标识列表，执行对应的重新组装的执行节点信息。

可选地，审批单元进一步被配置成：

确定测试入口标识列表中各测试入口标识对应的工作流；

将测试入口标识列表、执行配置信息和对应的工作流发送至预设审批节点进行重试审批。

可选地，更新单元进一步被配置成：

修改未执行节点的配置信息。

可选地，持续集成流水线的执行装置还包括聚合单元，被配置成：

聚合执行成功后的流水线中的各节点信息，生成新的流水线执行节点。

另外，本申请还提供了一种持续集成流水线的执行电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上述的持续集成流水线的执行方法。

另外，本申请还提供了一种计算机可读介质，其上存储有计算机程序，程序被处理器执行时实现如上述的持续集成流水线的执行方法。

上述发明中的一个实施例具有如下优点或有益效果：本申请通过执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点；确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表；基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。从而，本申请通过在持续集成流水线节点失败后的每次重试时只执行失败与未执行的节点，减少了流水线的整体执行时间，提高了流水线执行效率，提升客户体验。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本申请，不构成对本申请的不当限定。其中：

图1是根据本申请第一实施例的持续集成流水线的执行方法的主要流程的示意图；

图2是根据本申请第二实施例的持续集成流水线的执行方法的主要流程的示意图；

图3是根据本申请第三实施例的持续集成流水线的执行方法的应用场景示意图；

图4是根据本申请实施例的持续集成流水线的执行装置的主要模块的示意图；

图5是本申请实施例可以应用于其中的示例性系统架构图；

图6是适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本申请第一实施例的持续集成流水线的执行方法的主要流程的示意图，如图1所示，持续集成流水线的执行方法包括：

步骤S101，执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点。

本实施例中，持续集成流水线的执行方法的执行主体(例如，可以是服务器)可以通过有线连接或无线连接的方式，监测到用户触发执行流水线，进而执行主体可以执行流水线。当执行主体执行完流水线中各节点并监测到流水线中存在执行失败的节点时(例如，执行主体在流水线各节点的执行日志中查询到存在Fail标识的节点，即为失败节点)，接收流水线节点执行失败信息。在流水线节点执行失败信息中，包含有节点标识，该节点标识可以是对应流水线节点的标识，例如可以是Fail(即失败)或Pass(即成功)。执行主体可以通过定位Fail节点标识来定位对应的失败节点。

在本实施例的一些可选的实现方式中，确定失败节点，还包括：确定流水线中各节点所对应的类信息。具体地，执行主体可以通过确定流水线中各节点所需要调用的方法类信息。响应于确定流水线中的多个节点共同调用同一个类信息，当一个节点执行失败时，确定多个节点为失败节点。

本实现方式中，类信息可以包括方法类。当存在流水线中的多个节点需要共同调用同一个方法类的情形时，则这些多个节点中只要有一个节点在调用该同一个方法类时执行失败，则该多个节点均会被确定为失败节点。也就是说即使该多个节点中有一个或几个节点在调用该同一个方法类时执行成功，当存在节点在调用该同一个方法类时执行失败，则该多个节点均会被确定为失败。从而实现尽可能地让失败节点重试，避免遗漏重试失败节点，从而提高持续集成流水线整体的执行效率和成功率。

步骤S102，确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表。

本实施例中，确定未执行节点，包括：

获取执行流水线中的各节点后的执行日志信息。

具体地，执行主体在执行完一遍流水线中所有节点后，可以获取所有执行过的节点的日志信息。执行成功和执行失败的节点会存在执行日志信息，未执行的节点不会存在执行日志信息。执行日志中可以包含执行调用的方法类。

解析执行日志信息，进而基于有向图，确定未执行节点。

具体地，有向图的各顶点是基于类信息建立的。执行主体可以解析执行日志信息，得到本次流水线中执行成功的节点对应的类信息，然后执行主体可以基于包含所有历史执行成功节点对应的类信息的有向图以及基于得到的本次执行成功的节点对应的类信息，进而确定未执行节点。即将在该有向图中存在的类信息，但是在本次流水线执行成功的节点所对应的类信息中没有(或不存在)的类信息所对应的节点确定为未执行节点。在有向图中，节点与类信息一一对应。通过有向图中的类信息，可以确定对应的节点。从而，最终可以准确地确定出本次流水线的未执行节点。

在本实施例的一些可选的实现方式中，解析执行日志信息，进而基于有向图，确定未执行节点，还包括：

解析执行日志信息，以确定对应代码中的类信息与行信息。

具体地，类信息可以包括执行流水线中的节点需要调用的方法类。行信息，可以包括执行流水线中的节点需要调用的代码行。

基于有向图和类信息与行信息，确定执行过的有向图节点。

具体地，本实现方式中的有向图是通过历史执行成功节点所对应的类信息建立的。执行主体可以将根据历史执行成功节点对应的类信息建立的有向图(该有向图中还可以包含历史执行成功节点对应的代码行信息)以及根据执行日志信息确定出的本次流水线执行成功节点对应的类信息和行信息进行比对，以确定出本次流水线执行过的有向图节点。

基于执行过的有向图节点和有向图的所有节点，确定未执行节点。

具体地，执行主体在确定出本次流水线执行过的有向图节点后，通过与有向图中所有节点进行比对，进而可以确定出有向图中未执行过的节点，即本次流水线对应的未执行过的节点。

执行主体在确定未执行节点后，可以查询该未执行节点对应的执行配置信息。并基于历史执行成功节点的配置信息修改对应的失败节点的配置信息。本实施例中，在执行流水线之前需要配置流水线任务需要执行的相关节点，比如，拉取代码、编译、单元测试、代码扫描、部署、自动化测试等节点，以及应用相关的元数据信息，比如，代码库地址、分支信息、分组信息、节点命令、自动化测试任务父节点等信息。然后通过人工或设定自动触发执行流水线任务。其中，本实施例中的修改对应的失败节点的配置信息，示例的，比如，本次持续集成流水线的失败节点是单元测试节点，则执行主体可以调用历史执行成功的单元测试节点的配置信息，并将该历史执行成功的单元测试节点的配置信息更新至所述失败节点中。然后，执行主体可以将获取到的未执行节点的配置信息和修改后的失败节点的配置信息拆分为多个执行入口的集合，例如针对单元测试节点而言，将该单元测试节点拆分为每个测试类，该测试类即为森林中每一棵树的根节点，将所有执行的测试类作为执行入口，对于自动化测试节点而言，执行主体可以查询自动化测试计划中的子计划，直至获取所有子计划的叶子节点的测试任务，将叶子节点的测试任务作为执行入口。执行入口与入口节点不一样，是指触发自动化测试执行开始的入口。一个自动化测试计划中会有多个测试任务，每一个测试任务都是一个自动化测试触发应用执行的一个入口，对于一些数据驱动类的自动化测试任务而言，每一个测试场景仍是一个触发应用执行的一个入口。

其中，上述的森林中的每一棵树的根节点和子节点可以是通过以下步骤得到：执行主体可以根据执行代码的入口节点(该入口节点在有向图上，可以是历史执行成功节点对应的类信息的成员方法对应的节点)将有向图执行节点拆分为多个森林的数据结构，森林中的每一棵树的根节点即为执行代码的入口节点，每棵树的子节点为执行的过程中调用的相应代码节点。

本实施例中，对于执行代码的入口节点，示例的，例如一个应用的控制层的方法A是一个入口节点，该节点是由外部的http请求来触发执行的，即自动化测试用例的web请求来触发执行的。方法B会调用服务层的方法C，来处理一些业务逻辑，方法C会调用服务器其他的方法D1，D2来执行不同的查询、修改与删除逻辑。则该方法A和方法B即为执行代码的入口节点，方法C、方法D1、方法D2即为子节点。执行主体可以将基于获取到的未执行节点的配置信息和修改后的失败节点的配置信息拆分得到的多个执行入口的集合转化为未执行与执行失败的测试入口标识列表，并更新测试入口标识列表。更新的测试入口标识列表用于表征流水线需要重试的节点。

步骤S103，基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。

本实施例中，在重试执行节点开始前，执行主体可以从云存储上获取已编译完成的二进制文件夹，根据亚节点信息重新组装执行节点信息，该亚节点信息只包括未执行与执行失败的亚节点。

执行主体可以基于更新的测试入口标识列表，执行对应的未执行节点和修改配置信息后的更新的失败节点，如果执行主体仍然检测到存在执行失败的节点，则执行主体可以再次将失败节点与未执行节点进行重试，直至所有亚节点(即未执行与执行失败节点)都执行通过为止。

本实施例通过执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点；确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表；基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。从而，本申请通过在持续集成流水线节点失败后的每次重试时只执行失败与未执行的节点，减少了流水线的整体执行时间，提高了流水线执行效率，提升客户体验。

图2是根据本申请第二实施例的持续集成流水线的执行方法的主要流程示意图，如图2所示，持续集成流水线的执行方法包括：

步骤S201，获取执行成功节点的源代码，分析源代码得到类信息。

执行主体在生成有向图之前，可以根据历史的持续集成流水线中所有执行成功节点在执行成功时的代码库版本与代码库地址拉取对应的源代码。源代码(也称源程序)是指未编译的按照一定的程序设计语言规范书写的文本文件，是一系列人类可读的计算机语言指令。在现代程序语言中，源代码可以是以书籍或者磁带的形式出现，但最为常用的格式是文本文件，这种典型格式的目的是为了编译出计算机程序。计算机源代码的最终目的是将人类可读的文本翻译成为计算机可以执行的二进制指令，这种过程叫做编译，通过编译器完成。源代码是相对目标代码和可执行代码而言的。源代码就是用汇编语言和高级语言写出来的代码。目标代码是指源代码经过编译程序产生的能被cpu直接识别的二进制代码。可执行代码就是将目标代码连接后形成的可执行文件，当然也是二进制的。执行主体在拉取对应的源代码后，可以分析该源代码得到调用的方法类信息。

步骤S202，以类信息为顶点，生成有向图。

执行主体在拉取源代码后，可以解析所有的源代码，根据源代码得到所有的类信息，将类信息在有向图中建立顶点，进一步解析类中的成员方法与成员变量，每个成员建立一个顶点，同时建立与类顶点的边，进一步解析类的成员方法，逐行解析代码，如果代码行中调用的方法已在有向图中已存在，则建立该成员方法与调用方法顶点的边，该边具有属性信息，属性为代码行号与代码行中的实际参数列表，对于有些代码方法来说，会存在一个方法中的不同代码行调用一个方法的情形，因此加上属性加以区分，直到所有的类中成员方法与成员变量均被解析完为止，进而生成有向图。对于源代码的解析是一个相对静态的分析过程。

步骤S203，执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点。

步骤S203的原理与步骤S101的原理类似，此处不再赘述。

具体地，步骤S203还可以通过步骤S2031～步骤S2032来实现：

步骤S2031，基于有向图确定共用节点。

执行主体可以根据执行代码的入口节点(该入口节点在有向图上，可以是历史执行成功节点对应的类信息的成员方法对应的节点)将有向图执行节点拆分为多个森林的数据结构，森林中的每一棵树的根节点即为执行代码的入口节点，每棵树的子节点为执行的过程中调用的相应代码节点。执行主体根据对有向图拆分得到的多个森林的数据结构，可以确定出该多个森林的数据结构中共用的节点。例如，多个森林的数据结构中，第一棵树涉及到a1-b1-c-d-e五个节点，第二棵树涉及a2-b2-c-d-e五个节点，其中c，d，e在有向图中显示即是三个重合的共用的节点，如果第一颗树中d执行失败了，因为d是两棵树的共用节点，第二颗树不会视为成功，只有当两个树中的c，d，e均执行成功后才会认为该树的根节点是执行成功的。

步骤S2032，响应于确定对共用节点执行失败或未执行，将所有共用共用节点的树节点均确定为失败节点。

本实施例中，如果共用节点在一棵树中执行失败或未执行，则所有共用该节点的树均会标识为失败，只有当一棵树中所有节点均执行成功且其他树与该树节点共用节点均执行成功才会认为该树的根节点是执行成功的，进而可以尽可能的让失败的节点重试，避免出现遗漏可应用于跨应用间的用例调用情况。

步骤S204，确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表。

在更新测试入口标识列表之前，方法还包括：

修改未执行节点的配置信息。执行主体可以根据历史流水线执行成功节点的配置信息对应修改并更新未执行节点的配置信息，以使得执行节点重试的结果更准确，从而提高流水线执行效率，提升客户体验。

步骤S204的原理与步骤S102的原理类似，此处不再赘述。

步骤S205，对更新的测试入口标识列表中的各入口标识对应的各流水线节点进行重试审批，响应于确定重试审批通过，基于测试入口标识列表，执行对应的重新组装的执行节点信息。

具体地，对更新的测试入口标识列表中的各入口标识对应的各流水线节点进行重试审批，包括：

确定测试入口标识列表中各测试入口标识对应的工作流；

将测试入口标识列表、执行配置信息和对应的工作流发送至预设审批节点进行重试审批。

具体地，预设审批节点可以是历史成功执行的代码库版本与本次代码库版本之间所有的代码提交人员(根据代码库版本可以得出对应的代码提交人信息)。该预设审批节点对应的代码提交人员、流水线执行人员及应用负责人员可以根据推送的执行结果，确定该工作流是否重试执行，可以多人同时审批，当一个人驳回重试时，即结束本工作流。其中，确定测试入口标识列表中各测试入口标识对应的工作流可以是确定该流水线对应的工作流，该工作流可以包括代码提交人员节点、流水线执行人员节点以及应用负责人员节点。

执行主体在确定对应的工作流后，可以将测试入口标识列表、执行配置信息和对应的工作流发送至该工作流的预设审批节点(例如，代码提交人员节点、流水线执行人员节点以及应用负责人员节点)进行动态的重试审批，以将一些无需重试的流水线节点摒弃，从而达到动态释放系统资源的效果，提高流水线重试执行效率，提升客户体验。可以理解的是，该工作流上的各预设审批节点可以同时进行审批，也可以按照预设的审批顺序在一个审批节点审批通过后进入下一个审批节点的审批流程，本申请对审批的具体方式不做具体限定。重试的含义为不需要再次提交代码，可以修改失败节点和未执行节点的配置、数据等环境问题信息以进行重新执行，上述工作流中除了决定是否重试外，还可以修改工作流状态为解决中或指派解决人，当工作流状态为解决中或已指派时，其他审批节点不能再次进行重试操作，问题解决后(如数据问题、环境问题、自动化测试用例问题等)修改为已解决状态，已解决状态可以发起重试，当工作流中的一个审批节点在发起重试后，在预定阀值的时间内，其他审批节点不能再对该工作流进行操作，超过预定阀值时间后，持续集成流水线开始执行流水线重试。当所有代码提交人无驳回重试时，持续集成流水线开始执行重试操作，其中节点中的亚节点可以为多个测试的入口标识信息。

步骤S206，基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。

步骤S206的原理与步骤S103的原理类似，此处不再赘述。

在流水线中的各节点全部执行成功之后，方法还包括：

聚合执行成功后的流水线中的各节点信息，生成新的流水线执行节点。

具体地，当所有亚节点都执行成功后，即无执行失败与未执行节点时，持续集成流水线会将每次重试执行成功后的亚节点数据聚合，生成一份最终的完整流水线执行节点，推送给工作流中的代码提交人员节点、流水线执行人员节点以及应用负责人员节点，正常结束此版本执行的工作流。

本申请的最初的触发条件是用户手动执行流水线，当流水线所有节点的均执行成功后，开始进行源代码与执行日志的分析。当后续发生流水线执行失败时，触发工作流重新执行的审批流程。当审批通过后，执行失败与未运行的节点，大大提高了重新执行效率。

本申请的持续集成流水线的执行方法可以缩短因持续集成流水线节点失败后重新执行的时间，提高运行效率，减少重复执行，提高流水线的整体运行能力。执行失败触发工作流审批，可以大大减少不必要的流水线执行。除了适用于流水线减量重试外，还可以用于度量自动化测试与单元测试的覆盖率，还可以结合工作流的审批信息，追溯日常流水线执行失败的根本原因，可以减少后续的流水线的重试次数，更进一步提高团队整体的执行效率与成功率。

图3是根据本申请第三实施例的持续集成流水线的执行方法的应用场景示意图。持续集成流水线的执行方法，应用于软件质量度量领域的场景。如图3所示，服务器303执行流水线，接收流水线节点执行失败信息301，获取对应的节点标识302，进而确定失败节点304。服务器303确定未执行节点305，获取对应的配置信息306，修改失败节点304的配置信息，得到修改后的失败节点的配置信息307，进而更新测试入口标识列表，得到更新的测试入口标识列表308。服务器303基于更新的测试入口标识列表308，执行未执行节点和修改配置信息后的更新的失败节点309，直至流水线中的各节点全部执行成功。综上，本申请的持续集成流水线的执行方法，可以通过以下几个步骤来实现：配置流水线节点信息、执行流水线、解析源代码与执行信息、部分节点执行成功，分析失败节点信息、失败后重新执行失败节点或亚节点、聚合重试成功后的节点与亚节点及执行成功节点的数据。

图4是根据本申请实施例的持续集成流水线的执行装置的主要模块的示意图。如图4所示，持续集成流水线的执行装置包括失败节点确定单元401、更新单元402和执行单元403。

失败节点确定单元401，被配置成执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点。

更新单元402，被配置成确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表。

执行单元403，被配置成基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。

在一些实施例中，持续集成流水线的执行装置，还包括有向图生成单元，被配置成：获取执行成功节点的源代码，分析源代码得到类信息；以类信息为顶点，生成有向图。

在一些实施例中，失败节点确定单元401进一步被配置成：基于有向图确定共用节点；响应于确定对共用节点执行失败或未执行，将所有共用共用节点的树节点均确定为失败节点。

在一些实施例中，失败节点确定单元401进一步被配置成：确定流水线中各节点所对应的类信息；响应于确定流水线中的多个节点共同调用同一个类信息，当一个节点执行失败时，确定多个节点为失败节点。

在一些实施例中，更新单元402进一步被配置成：获取执行流水线中的各节点后的执行日志信息；解析执行日志信息，进而基于有向图，确定未执行节点。

在一些实施例中，更新单元402进一步被配置成：解析执行日志信息，以确定对应代码中的类信息与行信息；基于有向图和类信息与行信息，确定执行过的有向图节点；基于执行过的有向图节点和有向图的所有节点，确定未执行节点。

在一些实施例中，持续集成流水线的执行装置还包括图4中未示出的审批单元，被配置成：对更新的测试入口标识列表中的各入口标识对应的各流水线节点进行重试审批，响应于确定重试审批通过，基于测试入口标识列表，执行对应的重新组装的执行节点信息。

在一些实施例中，审批单元进一步被配置成：确定测试入口标识列表中各测试入口标识对应的工作流；将测试入口标识列表、执行配置信息和对应的工作流发送至预设审批节点进行重试审批。

在一些实施例中，更新单元402进一步被配置成：修改未执行节点的配置信息。

在一些实施例中，持续集成流水线的执行装置还包括图4中未示出的聚合单元，被配置成：聚合执行成功后的流水线中的各节点信息，生成新的流水线执行节点。

需要说明的是，在本申请持续集成流水线的执行方法和持续集成流水线的执行装置在具体实施内容上具有相应关系，故重复内容不再说明。

图5示出了可以应用本申请实施例的持续集成流水线的执行方法或持续集成流水线的执行装置的示例性系统架构500。

如图5所示，系统架构500可以包括终端设备501、502、503，网络504和服务器505。网络504用以在终端设备501、502、503和服务器505之间提供通信链路的介质。网络504可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备501、502、503通过网络504与服务器505交互，以接收或发送消息等。终端设备501、502、503上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备501、502、503可以是具有持续集成流水线处理屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器505可以是提供各种服务的服务器，例如对用户利用终端设备501、502、503所提交的流水线节点执行失败信息提供支持的后台管理服务器(仅为示例)。后台管理服务器可以执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点；确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表；基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。从而，本申请通过在持续集成流水线节点失败后的每次重试时只执行失败与未执行的节点，减少了流水线的整体执行时间，提高了流水线执行效率，提升客户体验。

需要说明的是，本申请实施例所提供的持续集成流水线的执行方法一般由服务器505执行，相应地，持续集成流水线的执行装置一般设置于服务器505中。

应该理解，图5中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图6，其示出了适于用来实现本申请实施例的终端设备的计算机系统600的结构示意图。图6示出的终端设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，计算机系统600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM603中，还存储有计算机系统600操作所需的各种程序和数据。CPU601、ROM602以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶征信授权查询处理器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

特别地，根据本申请公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(CPU)601执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括失败节点确定单元、更新单元和执行单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备执行流水线，接收流水线节点执行失败信息，获取对应的节点标识，进而确定失败节点；确定未执行节点，获取对应的配置信息，修改失败节点的配置信息，进而更新测试入口标识列表；基于更新的测试入口标识列表，执行未执行节点和修改配置信息后的更新的失败节点，直至流水线中的各节点全部执行成功。从而，本申请通过在持续集成流水线节点失败后的每次重试时只执行失败与未执行的节点，减少了流水线的整体执行时间，提高了流水线执行效率，提升客户体验。

根据本申请实施例的技术方案，通过在持续集成流水线节点失败后的每次重试时只执行失败与未执行的节点，减少了流水线的整体执行时间，提高了流水线执行效率，提升客户体验。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。