CN108399082B - 一种持续集成流水线的生成方法和系统 - Google Patents

一种持续集成流水线的生成方法和系统 Download PDF

Info

Publication number
CN108399082B
CN108399082B CN201710069500.4A CN201710069500A CN108399082B CN 108399082 B CN108399082 B CN 108399082B CN 201710069500 A CN201710069500 A CN 201710069500A CN 108399082 B CN108399082 B CN 108399082B
Authority
CN
China
Prior art keywords
test
pipeline
link
testing
current
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710069500.4A
Other languages
English (en)
Other versions
CN108399082A (zh
Inventor
李广旭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201710069500.4A priority Critical patent/CN108399082B/zh
Priority to PCT/CN2018/072830 priority patent/WO2018145559A1/zh
Publication of CN108399082A publication Critical patent/CN108399082A/zh
Application granted granted Critical
Publication of CN108399082B publication Critical patent/CN108399082B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3867—Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Educational Administration (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开一种持续集成流水线的生成方法和系统，获取蓝图文件和当前测试环节的配置文件，测试环节包括与蓝图文件中的服务实现对应的单元测试、与微服务对应的功能测试、以及与服务对应的系统测试和MergeCI；配置文件包括当前测试环节对应的单元测试的描述信息，根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；对至少一个单元测试的描述信息与所有流水线的流水线标识进行匹配；根据匹配结果，基于至少一个单元测试的描述信息以及流水线得到包含当前测试环节节点的新流水线。本发明解决人工生成流水线的问题。通过蓝图文件描述各测试环节间的依赖关系，各测试环节不再固定与一个流水线对应，能更好的适应微服务的使用场景。

Description

一种持续集成流水线的生成方法和系统
技术领域
本发明涉及微服务软件架构中持续集成CI(Continuous Integration)领域，具体涉及一种持续集成流水线的生成方法和系统。
背景技术
在软件持续集成领域，软件自动化测试与部署已经得到广泛的应用。持续集成起源于极限编程开发，是一种软件开发实践。它要求开发小组的每个成员频繁的集成他们的工作成果。在软件工程领域，软件的自动化持续集成技术对于提高软件质量与缩短交付周期都发挥了重要的作用。这种整合不是简单的组装软件，每次的集成通过一个包含测试的构建尽快的探测潜在的错误。保证软件现有的功能完整性，并发布相关的报告。通过快速持续集成反馈，开发人员可以了解软件集成的情况。对于不成功的集成进行快速的修改，极大的提高软件开发的效率和质量。
对于现有的CI(Continuous integration)流水线(pipeline)的生成主要采用人工方式来配置各个测试环节，然后根据测试流水线执行流程依次配置每个测试环节的执行顺序。这样的CI流水线一旦配置完成后不会进行改变，每次触发的CI过程都要按照这个流水线严格执行。如图1所示。
现有技术的主要有以下的缺陷：
如图1描述，流水线的生成是用户手动进行配置。在传统软件开发领域这种CI流水线的配置与生成技术基本可以满足软件持续集成的需求。但是如果要对项目进行有效的CI流程，用户必须对测试的各个环节功能很明确，知道每个环节执行什么功能，如何运行下一个环节，必须清楚每个环节的输入输出，从而提高了配置CI的难度。因为CI系统可能服务于很多不同的子项目，普通的用户很难确定各个子项目的测试依赖。
这样手动配置的流水线一旦配置完成，在测试过程中就不会进行改变，在微服务软件开发领域这种CI配置方法具有一定的局限性，因为在微服务软件架构中每个服务能够独立的编译、测试与发布，同时伴随着系统功能的增加与扩展，会有新的微服务加入到系统中，整个软件系统的依赖关系是可能变化的，这就导致了CI系统的流水线是需要不断的变化。传统的手动配置的CI方法很难适应这一场景的。
发明内容
本发明实施例要解决的主要技术问题是，提供一种持续集成流水线的生成方法和系统，解决现有技术中持续集成的流水线需手动配置生成，以及现有技术难以适应微服务的不断增加与扩展的问题。
为解决上述技术问题，本发明实施例提供一种持续集成流水线的生成方法，包括：
获取蓝图文件和当前测试环节的配置文件，蓝图文件的组成单元的层次从高到获取低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、MergeCI，单元测试与服务实现对应，功能测试与微服务对应，系统测试和MergeCI与服务对应；配置文件包括当前测试环节对应的单元测试的描述信息，描述信息包括代码仓库地址和目录列表标识；
根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；
对至少一个单元测试的描述信息与当前系统中所有流水线的流水线标识进行匹配；流水线标识信息包括代码仓库地址和目录列表标识；
根据匹配结果，基于至少一个单元测试的描述信息以及流水线得到包含当前测试环节节点的新流水线。
为解决上述技术问题，本发明实施例提供了一种持续集成流水线的生成系统，包括：
获取模块，用于获取蓝图文件和当前测试环节的配置文件，蓝图文件的组成单元的层次从高到获取低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、MergeCI，单元测试与服务实现对应，功能测试与微服务对应，系统测试和MergeCI与服务对应；配置文件包括当前测试环节对应的单元测试的描述信息，描述信息包括代码仓库地址和目录列表标识；
确定模块，用于根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；
匹配模块，用于根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；
处理模块，用于根据匹配结果，基于至少一个单元测试的描述信息以及流水线得到包含当前测试环节节点的新流水线。
本发明实施例公开了一种持续集成流水线的生成方法和系统，可以获取蓝图文件和当前测试环节的配置文件，蓝图文件的组成单元的层次从高到获取低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、MergeCI，单元测试与服务实现对应，功能测试与微服务对应，系统测试和MergeCI与服务对应；配置文件包括当前测试环节对应的单元测试的描述信息，描述信息包括代码仓库地址和目录列表标识；根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；对至少一个单元测试的描述信息与当前系统中所有流水线的流水线标识进行匹配；流水线标识信息包括代码仓库地址和目录列表标识；根据匹配结果，基于至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线。采用本发明可以自动根据当前测试环节的信息生成对应的流水线，避免人工生成流水线造成的效率低，耗时间等缺点。本发明中本实施例中通过用来描述CI测试环节的蓝图文件来描述各个测试环节之间的依赖关系，有了各个CI测试环节的蓝图结构，每个CI测试环节不再固定与某一个CI流水线对应，能更好的适应微服务不断扩展增加的使用场景。
附图说明
图1为现有技术中手动配置流水线的示意图；
图2为本发明实施例一提供的一种持续集成流水线的生成方法的流程图；
图3为本发明实施例一提供的蓝图文件的示意图；
图4为本发明实施例一提供的蓝图文件组成单元与测试环节类型的对应关系示意图；
图5为本发明实施例一提供的流水线的示意图；
图6为本发明实施例一提供的流水线的归并过程的示意图；
图7为本发明实施例一提供的流水线的更新过程的示意图；
图8为本发明实施例一提供的流水线的生成过程的示意图；
图9为本发明实施例一中CI流水线生成与执行过程的示意图；
图10为本发明实施例二提供的一种持续集成流水线的生成系统的示意图；
图11为本发明实施例二提供的另一种持续集成流水线的生成系统的示意图。
具体实施方式
下面通过具体实施方式结合附图对本发明作进一步详细说明。
实施例一：
参见图2，本实施例示出一种持续集成流水线的生成方法，包括：
S201、获取蓝图文件和当前测试环节的配置文件，蓝图文件的组成单元的层次从高到获取低依次包括：服务Service(S)、微服务MicroService(MS)、服务实现Servicelet(SL)，测试环节的类型包括单元测试Unit Test(UT)、功能测试Functional Test(FT)、系统测试System Test(ST)和MergeCI，UT与SL对应，FT与MS对应，ST和MergeCI与S对应；配置文件包括当前测试环节对应的单元测试的描述信息，描述信息包括代码仓库地址和目录列表标识；
S202、根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；
S203、对至少一个单元测试的描述信息与当前系统中所有流水线的流水线标识进行匹配；流水线标识信息包括代码仓库地址和目录列表标识；
S204、根据匹配结果，基于至少一个单元测试的描述信息以及流水线得到包含当前测试环节节点的新流水线。
在本实施例中，蓝图文件是现有技术中的蓝图文件，其基本组成单元与现有技术中的相同，组成单元从高层次到低层次依次包括服务S(Service)，微服务MS(MicroService)和服务实现SL(Servicelet)，其中，S和MS属于逻辑概念，真正的组成单元是SL。S、MS和SL的结构层次可参见图3，一个S下可以包含多个MS，同理，一个MS下可以包含多个SL。
进一步的，在本实施例中，为了实现流水线的自动生成，将传统的测试环节和蓝图文件中各层次的组成单元进行了对应关系的设置，使得传统的各个测试环节都配置了蓝图文件。本实施例中的测试环节包括但不限于UT(Unit Test)单元测试、FT(FunctionalTest)功能测试、ST(System Test)系统测试、MergeCI(Merge Continuous integration)，传统测试环节与蓝图文件中组成单元的对应关系如图4所示。其中，UT对应蓝图文件中的SL，FT对应蓝图文件中的MS，ST和MergeCI对应蓝图文件中的S。在本实施例中，上述的对应关系的设定是根据测试环节的数量、层次以及蓝图文件的组成单元的结构设置的，可以理解的是，若蓝图文件出现变化，如组成单元增多等或者测试环节发生变化，如测试环节的层次增多等，上述的对应关系可以随实际的需求进行变化。
在S201中，除了获取蓝图文件，还获取了当前测试环节的配置文件，可以理解的是，当前测试环节是UT、FT、ST、MergeCI等中的一种。其中，FT、ST、MergeCI都是以至少一个UT构成的。根据上述的对应关系以及图4，ST和MergeCI中包含至少一个FT，而FT中包含了至少一个UT。当前测试环节的配置文件中包含了当前测试环节对应的单元测试的描述信。该描述信息包括代码仓库地址和目录列表标识，即Repo+ContextDirs。而系统中的流水线的标识信息使用代码仓库地址+目录列表标识组合，即Repo+ContextDirs表示。可以理解的是，在蓝图文件中，UT对应的是SL，所以该UT的Repo+ContextDirs唯一标识对应的SL。在本实施例中，配置文件可以是用户预先配置好后输入系统中的。
可以预见，根据蓝图文件和配置文件中的信息，可以知道当前测试环节具体对应的蓝图文件的组成单元的层次，以及当前测试环节包含的层次以及每一层次的测试环节的信息，具体的，就可以得到当前测试环节对应的至少一个UT的信息。例如，若配置文件中，当前测试环节是ST，则根据蓝图文件可知，ST对应S，通过S查询到MS，再通过MS查询到SL，SL与UT对应，所以需要查询两次才可以查到ST对应的UT的信息。对于不同层次的测试环节，查询得到UT和SL的次数不同。
因为流水线标识由代码仓库地址和目录列表标识两部分组成。所以在S203中，对当前测试环节中的至少一个UT的描述信息与CI系统中所有的流水线的流水线标识进行匹配，实际上是对当前测试环节对应的每一个UT的代码仓库地址和目录列表标识与系统中流水线的代码仓库地址和目录列表标识分别匹配。即该匹配过程包括两部分的匹配，对代码仓库地址的匹配，以及对目录列表标识的匹配。对于不同的匹配结果，得到流水线的方法可能不同，但是都是基于该至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线。
在本实施例中，为了便于流水线自动生成的描述，做出如下的约定，流水线用pipeline表示。在本实施例中，参见图5，pipeline结构分别由pipeline header、UT测试环节层、FT测试环节层、ST测试环节层，MergeCI测试环节层组成。其中，每种类型的测试环节层次均由不同数量的测试环节组成。
下面对于不同匹配结果以及不同匹配结果下得到新流水线的方法进行说明。
对于代码仓库地址的匹配结果，包括相同和不同两种，对于目录列表的匹配结果，包括相同、包含，被包含、无交集。在不同的匹配结果下，得到新流水线的方法包括但不限于以下的几种：
归并法：若存在至少一个流水线的代码仓库地址和单元测试的代码仓库地址相同，且至少一个流水线的目录列表标识为单元测试的目录列表标识的子集，则以单元测试的代码仓库地址和目录列表标识为流水线头信息创建包含当前测试环节节点的新流水线，将至少一个流水线归并到新流水线中。
可以理解的是，上述的单元测试指的是当前测试环节中的单元测试。
进一步的，以以单元测试的代码仓库地址和目录列表标识为流水线头信息创建包含当前测试环节节点的新流水线，将至少一个流水线归并到新流水线中包括：
创建新流水线头，将单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建新流水线的节点列表，提取至少一个流水线中各测试环节的测试节点加入新流水线中对应的节点列表，为当前测试环节以及当前测试环节层次以下的测试环节新建测试节点，并加入新流水线对应的节点列表中。
下面结合图6，以当前测试环节为UT单元测试环节为例，对上述的归并过程进行解释说明。
假设当前的测试环节是单元测试环节，其单元测试为UT-x，对应的描述信息为RePo1+[A/B/C],根据UT-x的RePo1+[A/B/C]对当前系统中的pipeline进行匹配，如果有pipeline的代码仓库地址与UT-x的Repo1相同，且该pipeline的ContextDirs被[A/B/C]包含，例如图6中示出的流水线，Pipeline Repo1+[A/B]，[A/B]为[A/B/C]的子集，则创建新的pipeline header。
使用当前UT-x的标识信息(Repo+ContextDirs)作为新pipeline的Header标识信息，将与当前UT-x成为子集关系的Pipeline Repo1+[A/B]的流水线全部并入新建的流水线中，为当前的UT-x创建节点，加入新建的流水线中。具体的，创建新pipeline的UT列表信息，在最初新建时，当前该UT列表中没有任何UT节点。首先提取成为子集关系Pipeline Repo1+[A/B]中的UT节点列表中的每个UT节点，加入到新的UT节点列表中。这样新的UT节点列表就创建成功了，可以采用上述同样的方式，创建其他类型节点的节点列表，如FT节点列表等。对于当前的UT-x，也创建UT-x节点，加入UT节点列表中，最后得到的就是以UT-x的描述信息为流水线标识的，包含了成为子集的流水线PipelineRepo1+[A/B]以及UT-x节点的新流水线。
进一步的，为了避免新旧流水线的重复，在新的pipeline结构生成时，删除当前CI系统中已被归并的pipeline。进一步的，为了避免新建的流水线中的节点重复，浪费测试资源和时间，在归并时要保证节点不能重复。具体的，排除重复节点的过程可以在归并过程中进行，如与UT-x成为子集关系的流水线有两条，则在归并过程中判断两条流水线中是否具有重复节点，有就删除冗余节点。另外，排除重复节点的过程也可以在归并过程完成后进行，即在新流水线创建完成后，再判断流水线中是否有重复节点，有，则删除冗余节点。
更新法：若存在至少一个流水线的代码仓库地址和单元测试的代码仓库地址相同，且单元测试的目录列表标识为至少一个流水线的目录列表标识的子集，或单元测试的目录列表标识与至少一个流水线的目录列表标相同；则根据测试单元的代码仓库地址和目录列表标识更新至少一个流水线。
在更新法中，是以测试单元的信息更新现有的流水线得到新流水线的方法，在该更新过程中，现有流水线头信息不变，只会根据当前的测试环节增加新的节点。具体的，根据测试单元的代码仓库地址和目录列表标识更新至少一个流水线包括：创建当前测试环节以及当前测试环节层次以下的测试环节的测试节点，加入到至少一个流水线对应的节点列表中；若至少一个流水线中某流水线没有当前测试环节对应的节点列表，则在某流水线中创建当前测试环节的节点列表，创建当前测试环节以及当前测试环节层次以下的测试环节的测试节点加入对应的节点列表。
在上述的过程中，可以预见的是，如果当前测试环节的某个UT的目录列表标识与系统中多个pipeline的目录列表标识相同，或为系统中多个pipeline的目录列表标识的子集，则在更新时，需要对这多个pipeline都进行更新，即都在这多个pipeline中加入当前测试环节的节点。
下面结合图7，对更新流水线的过程进行解释说明。
假设当前的测试环节是单元测试环节，对应的单元测试为UT-x，其描述信息为Repo1+[A]，在系统中存在一流水线为pipeline，其流水线标识为Repo1+[A/B],由于UT-x与pipeline的Repo相同，UT-x的ContextDirs为pipeline的ContextDirs的子集，所以以UT-x更新pipeline。具体的，创建当前测试环节的节点，即创建UT-x的节点，将该节点加入到pipeline中对应的节点列表中，即将UT-x节点加入到pipeline的UT节点列表中。
另外，若当前测试环节的层次较高，为FT、ST或MergeCI，在某些需要更新的流水线中，没有当前测试环节的节点列表。例如当前测试环节为ST测试环节，流水线的最高层次测试环节是FT，则需要在该pipeline中创建当前测试环节的节点列表，再创建当前测试环节的节点，加入对应的节点列表中。如果执行成功，CI系统中与该UT测试环节相关的pipelineUT节点列表中都会包含该UT节点。其中，其他类型的测试环节如FT、ST、MergeCI与UT的执行过程一样，不再进行单独描述。但是可以理解的是，若需要更新的流水线中只有UT节点列表，而当前测试环节为ST，则需要创建的节点列表包括ST和FT节点列表，更新的过程中流水线增加的分支包括UT-FT-ST三个层次的节点。
进一步的，在更新过程中，需要保证每一个pipeline的节点列表中每个节点信息不同，即没有重复节点。所以在本实施例中，在流水线的更新过程中或更新完成后，还包括：判断更新的流水线中是否有重复的节点，若有，则删除冗余节点。
生成法：若单元测试的代码仓库地址与所有流水线的代码仓库地址不同，或单元测试的目录列表标识与所有流水线的目录列表标识无交集，则根据单元测试的代码仓库地址和目录列表标识生成包含当前测试环节节点的新流水线。
该生成法中，完全是以当前测试环节的信息生成一个全新的流水线，在生成新流水线的过程中。可以预见，需要创建新流水线的header，并且该header信息是当前测试环节中满足使用生成法的条件的单元测试的描述信息。进一步的，根据单元测试的代码仓库地址和目录列表标识生成包含当前测试环节节点的新流水线包括：创建新流水线头，将单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建当前测试环节以及当前测试环节层次以下的测试环节的节点列表以及测试节点，在节点列表中加入对应的测试节点。
可以预见的是，如果该单元测试(或SL)的数据来自UT测试环节，那么创建的就是UT测试配置对象层。如果该单元测试(或SL)的数据来自FT测试环节，那么创建的就是FT测试配置对象层。可以预见的是，在第三种方法中，若单元测试的数据来自的是FT、ST或者MergeCI测试环节层，那么在新建流水线的过程中，创建的节点列表和生成的测试节点包括了当前测试环节层以及其以下层次的节点列表和测试节点，例如，当前的测试环节是ST，则生成的流水线中包括ST节点，也包括FT节点和UT节点。
下面结合图8，对本实施例中的生成流水线的过程进行解释说明。
假设当前测试环节是UT测试环节，具体的为UT-x，其代码仓库地址和目录列表标识为Repo1+[D/E],假设系统中只有流水线的pipeline的流水线标识为Repo1+[A/B]，由于UT-x和流水线pipeline的Repo相同，但是目录列表标识无交集，所以需要以UT-x创建新流水线。在创建新流水线的过程中，首先创建流水线header，将UT-x的Repo1+[D/E]填入流水线头信息，创建UT测试环节节点列表，将UT-x节点加入该节点列表中。可以预见，若该测试环节是FT测试环节，UT-x是FT下的测试环节，则创建的节点列表包括FT节点列表，UT节点列表，在流水线中的测试环节包括FT测试环节和UT测试环节。
在上述的例子中，均以UT作为例子说明了流水线的自动生成方法，对于FT测试环节而言。由FT蓝图描述信息可知，FT对应蓝图结构中的MS，而MS可能包含多个SL信息。所以FT测试环节生成Pipeline的流程与UT测试环节生成Pipeline的流程是有一些区别的。主要区别为查找SL的过程，首先提取FT测试环节对应蓝图文件描述中每一个SL标识信息，即Repo与ContextDirs，然后与当前CI系统的每个pipeline的Repo与ContextDirs进行比较匹配，具体单个SL的匹配处理过程与UT处理过程一致，可以参考UT测试环节的处理过程。
ST与MergeCI测试环节的处理过程与FT测试环节基本一致，区别同样是查找SL的过程。如图4描述，FT对应蓝图文件可以由MS查找到SL的信息，而ST与MergeCI则需要查询两次，首先由Service的信息查询到所有的MS信息，然后在有所有的MS信息查找到所有的SL信息，然后比较每个SL的信息与CI系统中的pipeline标识信息是否匹配。单个SL的比较处理流程，仍然与UT测试环节的处理过程一致。
在流水线生成系统中，主要接收用户的测试环节的配置文件与蓝图配置做为输入。而蓝图配置在本发明系统中主要做为基础配置存在，测试环节的配置文件主要作为普通配置。普通配置与基础配置的区别主要在变化的频度上。基础配置(蓝图配置)相对与普通配置(测试环节配置文件)参数项更稳定。
参见图9，图9示出了CI流水线生成与执行过程，在本实施例中，在接收到用户的配置文件以及获取蓝图文件后，根据我们上述描述的自动化生成算法(归并、更新、生成)进行流水线的生成，最终的输出结果为流水线集合(一条或多条流水线)。然后由本发明描述的执行子系统会把流水线集合中的每个流水线模板做为一个标准输入进行执行对应CI系统的启动。每个CI系统启动后都会对代码仓库进行监控，当接收到代码仓库的变化事件(另一个输入)通知后，进行对应的CI系统执行过程。进而由每个CI流水线生成本次执行CI的测试报告。
采用本实施例的持续集成流水线的生成方法，用户不再需要了解各个子项目的依赖关系，只需要知道当前项目的相关测试项即可。我们通过一种蓝图方法与结构来解决各个子项目的依赖关系。每个子项目的开发与测试人员只需要预先定义好本子项目的各个测试环节的蓝图结构即可。利用流水线的归并、更新、生成技术，使得用户不再需要关注整个流水线的组成，只需要关注自己的测试领域，通过隔离关注域大大提高了测试效率。本实施例中通过用来描述CI测试环节的蓝图文件来描述各个测试环节之间的依赖关系，有了各个CI测试环节的蓝图结构，每个CI测试环节不再固定与某一个CI流水线对应，而是根据蓝图描述关系自动化的分离与扩展。更好的适应微服务的使用场景。增强了本实施例方法的适应性。
进一步的，在流水线的自动化生成的过程中，会比较所有的CI流水线的各个测试环节，通过流水线的自动化筛选的方法来实现冗余测试环节的删除。避免宝贵测试资源浪费。
实施例二：
参见图10，本实施例示出一种持续集成流水线的生成系统，包括：
获取模块11，用于获取蓝图文件和当前测试环节的配置文件，蓝图文件的组成单元的层次从高到获取低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、MergeCI，单元测试与服务实现对应，功能测试与微服务对应，系统测试和MergeCI与服务对应；配置文件包括当前测试环节对应的单元测试的描述信息，描述信息包括代码仓库地址和目录列表标识；
确定模块12，用于根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；
匹配模块13，用于根据蓝图文件与配置文件，确定当前测试环节的层次和对应的至少一个单元测试；
处理模块14，用于根据匹配结果，基于至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线。
在本实施例中，蓝图文件是现有技术中的蓝图文件，其基本组成单元与现有技术中的相同，组成单元从高层次到低层次依次包括服务S(Service)，微服务MS(MicroService)和服务实现SL(Servicelet)，其中，S和MS属于逻辑概念，真正的组成单元是SL。S、MS和SL的结构层次可参见实施例一中的图3，一个S下可以包含多个MS，同理，一个MS下可以包含多个SL。
进一步的，在本实施例中，为了实现流水线的自动生成，将传统的测试环节和蓝图文件中各层次的组成单元进行了对应关系的设置，使得传统的各个测试环节都配置了蓝图文件。本实施例中的测试环节包括但不限于UT(Unit Test)单元测试、FT(FunctionalTest)功能测试、ST(System Test)系统测试、MergeCI合并持续集成，传统测试环节与蓝图文件中组成单元的对应关系如实施例一中的图4所示。其中，UT对应蓝图文件中的SL，FT对应蓝图文件中的MS，ST和MergeCI对应蓝图文件中的S。在本实施例中，上述的对应关系的设定是根据测试环节的数量、层次以及蓝图文件的组成单元的结构设置的，可以理解的是，若蓝图文件出现变化，如组成单元增多等或者测试环节发生变化，如测试环节的层次增多等，上述的对应关系可以随实际的需求进行变化。
可以理解的是，当前测试环节是UT、FT、ST、MergeCI等中的一种。其中，FT、ST、MergeCI都是以至少一个UT构成的。根据上述的对应关系以及图4，ST和MergeCI中包含至少一个FT，而FT中包含了至少一个UT。当前测试环节的配置文件中包含了当前测试环节对应的单元测试的描述信。该描述信息包括代码仓库地址和目录列表标识，即Repo+ContextDirs。而系统中的流水线的标识信息使用代码仓库地址+目录列表标识组合，即Repo+ContextDirs表示。可以理解的是，在蓝图文件中，UT对应的是SL，所以该UT的Repo+ContextDirs唯一标识对应的SL。在本实施例中，获取模块11获取的配置文件可以是用户预先配置好后输入系统中的。
本实施例中，确定模块12根据蓝图文件和配置文件中的信息，可以确定当前测试环节具体对应的蓝图文件的组成单元的层次，以及当前测试环节包含的层次以及每一层次的测试环节的信息，具体的，确定模块12可以得到当前测试环节对应的至少一个UT的信息。例如，若配置文件中，当前测试环节是ST，则确定模块12根据蓝图文件可知，ST对应S，通过S查询到MS，再通过MS查询到SL，SL与UT对应，所以确定模块12需要查询两次才可以查到ST对应的UT的信息。对于不同层次的测试环节，查询得到UT和SL的次数不同。
因为流水线标识由代码仓库地址和目录列表标识两部分组成。所以匹配模块13对当前测试环节中的至少一个UT的描述信息与CI系统中所有的流水线的流水线标识进行匹配，实际上是对当前测试环节对应的每一个UT的代码仓库地址和目录列表标识与系统中流水线的代码仓库地址和目录列表标识分别匹配。即该匹配过程包括两部分的匹配，对代码仓库地址的匹配，以及对目录列表标识的匹配。对于不同的匹配结果，得到流水线的方法可能不同，但是都是基于该至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线。
在本实施例中，为了便于流水线自动生成的描述，做出如下的约定，流水线用pipeline表示。在本实施例中，pipeline结构分别由pipeline header、UT测试环节层、FT测试环节层、ST测试环节层，MergeCI测试环节层组成。其中，每种类型的测试环节层次均由不同数量的测试环节组成。
对于代码仓库地址的匹配结果，包括相同和不同两种，对于目录列表的匹配结果，包括相同、包含，被包含、无交集。在不同的匹配结果下，处理模块14得到新流水线的方法不同。
进一步的，处理模块14包括第一处理模块141，用于若存在至少一个流水线的代码仓库地址和单元测试的代码仓库地址相同，且至少一个流水线的目录列表标识为单元测试的目录列表标识的子集，则以单元测试的代码仓库地址和目录列表标识为流水线头信息创建包含当前测试环节节点的新流水线，将至少一个流水线归并到新流水线中。
可以理解的是，上述的单元测试指的是当前测试环节中的单元测试。
进一步的，第一处理模块141，用于创建新流水线头，将单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建新流水线的节点列表，提取至少一个流水线中各测试环节的测试节点加入新流水线中对应的节点列表，为当前测试环节以及当前测试环节层次以下的测试环节新建测试节点，并加入新流水线对应的节点列表中。
为了避免新旧流水线的重复，在新的pipeline结构生成时，需要删除当前CI系统中已被归并的pipeline。进一步的，为了避免新建的流水线中的节点重复，浪费测试资源和时间，在归并时要保证节点不能重复。参见图11，持续集成流水线的生成系统还包括第二去重模块16，用于在流水线的归并过程中或归并过程完成后，删除当前系统中已被归并的流水线；判断新流水线中是否有重复的节点，若有，则删除冗余的节点。
在另一实施例中，处理模块14包括第二处理模块142，用于若存在至少一个流水线的代码仓库地址和单元测试的代码仓库地址相同，且单元测试的目录列表标识为至少一个流水线的目录列表标识的子集，或单元测试的目录列表标识与至少一个流水线的目录列表标相同；则根据测试单元的代码仓库地址和目录列表标识更新至少一个流水线。
第二处理模块142是以测试单元的信息更新现有的流水线得到新流水线。在该更新过程中，现有流水线头信息不变，只会根据当前的测试环节增加新的节点。具体的，第二处理模块142用于创建当前测试环节以及当前测试环节层次以下的测试环节的测试节点，加入到至少一个流水线对应的节点列表中；若至少一个流水线中某流水线没有当前测试环节对应的节点列表，则在某流水线中创建当前测试环节的节点列表，创建当前测试环节以及当前测试环节层次以下的测试环节的测试节点加入对应的节点列表。
可以预见的是，在第二处理模块142更新流水线的过程中，如果当前测试环节的某个UT的目录列表标识与系统中多个pipeline的目录列表标识相同，或为系统中多个pipeline的目录列表标识的子集，则在更新时，需要对这多个pipeline都进行更新，即都在这多个pipeline中加入当前测试环节的节点。
进一步的，在更新过程中，需要保证每一个pipeline的节点列表中每个节点信息不同，即没有重复节点。所以参见图11，本实施例中的持续集成流水线的生成系统还包括第一去重模块15，用于在更新流水线的过程中或更新流水线之后，判断流水线中是否有重复的节点，若有，则删除冗余节点。
在另一实施例中，处理模块14包括第三处理模块143，用于若单元测试的代码仓库地址与所有流水线的代码仓库地址不同，或单元测试的目录列表标识与所有流水线的目录列表标识无交集，则根据单元测试的代码仓库地址和目录列表标识生成包含当前测试环节节点的新流水线。
第三处理模块143完全是以当前测试环节的信息生成一个全新的流水线，在生成新流水线的过程中。可以预见，需要创建新流水线的header，并且该header信息是当前测试环节中满足使用生成法的条件的单元测试的描述信息。进一步的，第三处理模块143用于创建新流水线头，将单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建当前测试环节以及当前测试环节层次以下的测试环节的节点列表以及测试节点，在节点列表中加入对应的测试节点。
可以预见的是，如果该单元测试(或SL)的数据来自UT测试环节，那么创建的就是UT测试配置对象层。如果该单元测试(或SL)的数据来自FT测试环节，那么创建的就是FT测试配置对象层。并且若单元测试的数据来自的是FT、ST或者MergeCI测试环节层，那么第三处理模块143在新建流水线的过程中，创建的节点列表和生成的测试节点包括了当前测试环节层以及其以下层次的节点列表和测试节点，例如，当前的测试环节是ST，则生成的流水线中包括ST节点，也包括FT节点和UT节点。
对于当前测试环节是UT时，流水线的自动生成方法可以参见实施例一的相关说明，在此不进行赘述。对于FT测试环节而言。由FT蓝图描述信息可知，FT对应蓝图结构中的MS，而MS可能包含多个SL信息。所以FT测试环节生成Pipeline的流程与UT测试环节生成Pipeline的流程是有一些区别的。主要区别为查找SL的过程，首先提取FT测试环节对应蓝图文件描述中每一个SL标识信息，即Repo与ContextDirs，然后与当前CI系统的每个pipeline的Repo与ContextDirs进行比较匹配，具体单个SL的匹配处理过程与UT处理过程一致，可以参考UT测试环节的处理过程。
ST与MergeCI测试环节的处理过程与FT测试环节基本一致，区别同样是查找SL的过程。如图4描述，FT对应蓝图文件可以由MS查找到SL的信息，而ST与MergeCI则需要查询两次，首先由Service的信息查询到所有的MS信息，然后在有所有的MS信息查找到所有的SL信息，然后比较每个SL的信息与CI系统中的pipeline标识信息是否匹配。单个SL的比较处理流程，仍然与UT测试环节的处理过程一致。
在持续集成流水线的生成系统中，获取模块11主要接收用户的测试环节的配置文件与蓝图配置做为输入。而蓝图配置在本发明系统中主要做为基础配置存在，测试环节的配置文件主要作为普通配置。普通配置与基础配置的区别主要在变化的频度上。基础配置(蓝图配置)相对与普通配置(测试环节配置文件)参数项更稳定。
在本实施例中，持续集成流水线的生成系统在接收到用户的配置文件后，处理模块14根据上述描述的自动化生成算法(归并、更新、生成)进行流水线的生成，最终的输出结果为流水线集合(一条或多条流水线)。然后由本发明描述的执行子系统会把流水线集合中的每个流水线模板做为一个标准输入进行执行对应CI系统的启动。每个CI系统启动后都会对代码仓库进行监控，当接收到代码仓库的变化事件(另一个输入)通知后，进行对应的CI系统执行过程。进而由每个CI流水线生成本次执行CI的测试报告。
采用本实施例的持续集成流水线的生成系统，通过一种蓝图方法与结构来解决各个子项目的依赖关系，每个子项目的开发与测试人员只需要预先定义好本子项目的各个测试环节的蓝图结构即可。系统利用流水线的归并、更新、生成技术，使得用户不再需要关注整个流水线的组成，只需要关注自己的测试领域，通过隔离关注域大大提高了测试效率。本实施例中通过用来描述CI测试环节的蓝图文件来描述各个测试环节之间的依赖关系，有了各个CI测试环节的蓝图结构，每个CI测试环节不再固定与某一个CI流水线对应，而是根据蓝图描述关系自动化的分离与扩展。更好的适应微服务的使用场景。增强了本实施例方法的适应性。
显然，本领域的技术人员应该明白，上述本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (10)

1.一种持续集成流水线的生成方法，包括：
获取蓝图文件和当前测试环节的配置文件，所述蓝图文件的组成单元的层次从高到低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、MergeCI，所述单元测试与服务实现对应，所述功能测试与微服务对应，所述系统测试和MergeCI与服务对应；所述配置文件包括当前测试环节对应的单元测试的描述信息，所述描述信息包括代码仓库地址和目录列表标识；
根据所述蓝图文件与所述配置文件，确定所述当前测试环节的层次和对应的至少一个单元测试；
对所述至少一个单元测试的描述信息与当前系统中所有流水线的流水线标识进行匹配；所述流水线标识包括代码仓库地址和目录列表标识；
根据匹配结果，基于所述至少一个单元测试的描述信息以及所述流水线得到包含当前测试环节节点的新流水线。
2.如权利要求1所述的持续集成流水线的生成方法，其特征在于，所述根据匹配结果，基于所述至少一个单元测试的描述信息以及流水线得到包含当前测试环节节点的新流水线包括：
若存在至少一个流水线的代码仓库地址和所述单元测试的代码仓库地址相同，且所述至少一个流水线的目录列表标识为所述单元测试的目录列表标识的子集，则以所述单元测试的代码仓库地址和目录列表标识为流水线头信息创建包含当前测试环节节点的新流水线，将所述至少一个流水线归并到所述新流水线中；
若存在至少一个流水线的代码仓库地址和所述单元测试的代码仓库地址相同，且所述单元测试的目录列表标识为所述至少一个流水线的目录列表标识的子集，或所述单元测试的目录列表标识与所述至少一个流水线的目录列表标相同；则根据所述单元测试的代码仓库地址和目录列表标识更新所述至少一个流水线；
若所述单元测试的代码仓库地址与所有流水线的代码仓库地址不同，或所述单元测试的目录列表标识与所有流水线的目录列表标识无交集，则根据所述单元测试的代码仓库地址和目录列表标识生成包含当前测试环节节点的新流水线。
3.如权利要求2所述的持续集成流水线的生成方法，其特征在于，所述以所述单元测试的代码仓库地址和目录列表标识为流水线头信息创建包含当前测试环节节点的新流水线，将所述至少一个流水线归并到所述新流水线中包括：创建新流水线头，将所述单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建新流水线的节点列表，提取所述至少一个流水线中各测试环节的测试节点加入所述新流水线中对应的节点列表，为所述当前测试环节以及当前测试环节层次以下的测试环节新建测试节点，并加入新流水线对应的节点列表中;
所述根据所述单元测试的代码仓库地址和目录列表标识更新所述至少一个流水线包括：创建所述当前测试环节以及当前测试环节层次以下的测试环节的测试节点，加入到所述至少一个流水线对应的节点列表中；若所述至少一个流水线中某流水线没有所述当前测试环节对应的节点列表，则在所述某流水线中创建当前测试环节的节点列表，创建所述当前测试环节以及当前测试环节层次以下的测试环节的测试节点加入对应的节点列表；
所述根据所述单元测试的代码仓库地址和目录列表标识生成包含当前测试环节节点的新流水线包括：创建新流水线头，将所述单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建所述当前测试环节以及当前测试环节层次以下的测试环节的节点列表以及测试节点，在所述节点列表中加入对应的测试节点。
4.如权利要求2或3所述的持续集成流水线的生成方法，其特征在于，还包括，在更新流水线的过程中或更新流水线之后，判断所述流水线中是否有重复的节点，若有，则删除冗余节点。
5.如权利要求2或3所述的持续集成流水线的生成方法，其特征在于，还包括，在流水线的归并过程中或归并过程完成后，删除当前系统中已被归并的流水线；判断所述新流水线中是否有重复的节点，若有，则删除冗余的节点。
6.一种持续集成流水线的生成系统，其特征在于，包括：
获取模块，用于获取蓝图文件和当前测试环节的配置文件，所述蓝图文件的组成单元的层次从高到低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、MergeCI，所述单元测试与服务实现对应，所述功能测试与微服务对应，所述系统测试和MergeCI与服务对应；所述配置文件包括当前测试环节对应的单元测试的描述信息，所述描述信息包括代码仓库地址和目录列表标识；
确定模块，用于根据所述蓝图文件与所述配置文件，确定所述当前测试环节的层次和对应的至少一个单元测试；
匹配模块，用于根据所述蓝图文件与所述配置文件，确定所述当前测试环节的层次和对应的至少一个单元测试；
处理模块，用于根据匹配结果，基于所述至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线，其中，所述流水线标识包括代码仓库地址和目录列表标识。
7.如权利要求6所述的持续集成流水线的生成系统，其特征在于，所述处理模块包括第一处理模块，第二处理模块，第三处理模块；
所述第一处理模块，用于若存在至少一个流水线的代码仓库地址和所述单元测试的代码仓库地址相同，且所述至少一个流水线的目录列表标识为所述单元测试的目录列表标识的子集，则以所述单元测试的代码仓库地址和目录列表标识为流水线头信息创建包含当前测试环节节点的新流水线，将所述至少一个流水线归并到所述新流水线中；
所述第二处理模块，用于若存在至少一个流水线的代码仓库地址和所述单元测试的代码仓库地址相同，且所述单元测试的目录列表标识为所述至少一个流水线的目录列表标识的子集，或所述单元测试的目录列表标识与所述至少一个流水线的目录列表标相同；则根据所述单元测试的代码仓库地址和目录列表标识更新所述至少一个流水线；
所述第三处理模块，用于若所述单元测试的代码仓库地址与所有流水线的代码仓库地址不同，或所述单元测试的目录列表标识与所有流水线的目录列表标识无交集，则根据所述单元测试的代码仓库地址和目录列表标识生成包含当前测试环节节点的新流水线。
8.如权利要求7所述的持续集成流水线的生成系统，其特征在于，所述第一处理模块，用于创建新流水线头，将所述单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建新流水线的节点列表，提取所述至少一个流水线中各测试环节的测试节点加入所述新流水线中对应的节点列表，为所述当前测试环节以及当前测试环节层次以下的测试环节新建测试节点，并加入新流水线对应的节点列表中;
所述第二处理模块，用于创建所述当前测试环节以及当前测试环节层次以下的测试环节的测试节点，加入到所述至少一个流水线对应的节点列表中；若所述至少一个流水线中某流水线没有所述当前测试环节对应的节点列表，则在所述某流水线中创建当前测试环节的节点列表，创建所述当前测试环节以及当前测试环节层次以下的测试环节的测试节点加入对应的节点列表；
所述第三处理模块，用于创建新流水线头，将所述单元测试的代码仓库地址和目录列表标识作为新流水线信息，创建所述当前测试环节以及当前测试环节层次以下的测试环节的节点列表以及测试节点，在所述节点列表中加入对应的测试节点。
9.如权利要求7或8所述的持续集成流水线的生成系统，其特征在于，还包括第一去重模块，用于在更新流水线的过程中或更新流水线之后，判断所述流水线中是否有重复的节点，若有，则删除冗余节点。
10.如权利要求7或8所述的持续集成流水线的生成系统，其特征在于，还包括第二去重模块，用于在流水线的归并过程中或归并过程完成后，删除当前系统中已被归并的流水线；判断所述新流水线中是否有重复的节点，若有，则删除冗余的节点。
CN201710069500.4A 2017-02-08 2017-02-08 一种持续集成流水线的生成方法和系统 Active CN108399082B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201710069500.4A CN108399082B (zh) 2017-02-08 2017-02-08 一种持续集成流水线的生成方法和系统
PCT/CN2018/072830 WO2018145559A1 (zh) 2017-02-08 2018-01-16 持续集成流水线的生成方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710069500.4A CN108399082B (zh) 2017-02-08 2017-02-08 一种持续集成流水线的生成方法和系统

Publications (2)

Publication Number Publication Date
CN108399082A CN108399082A (zh) 2018-08-14
CN108399082B true CN108399082B (zh) 2022-11-15

Family

ID=63094364

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710069500.4A Active CN108399082B (zh) 2017-02-08 2017-02-08 一种持续集成流水线的生成方法和系统

Country Status (2)

Country Link
CN (1) CN108399082B (zh)
WO (1) WO2018145559A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110895460A (zh) * 2018-09-13 2020-03-20 深圳市优必选科技有限公司 基于Jenkins的机器人系统集成方法、装置及终端设备
US10872028B2 (en) 2019-03-01 2020-12-22 Red Hat Israel, Ltd. Methods and systems for identifying duplicate jobs in a continuous integration environment
CN110018964A (zh) * 2019-04-12 2019-07-16 广东电网有限责任公司信息中心 一种面向电力行业研发测试流水线构建方法
CN110780885B (zh) * 2019-10-15 2022-08-23 卡斯柯信号有限公司 Cbtc中ats和联锁软件数据自动部署和环境启动装置及方法
CN110837373A (zh) * 2019-10-17 2020-02-25 深圳市基石协作科技有限公司 持续集成与持续交付方法、装置、计算机设备和存储介质
CN111242445B (zh) * 2020-01-06 2023-08-04 广州熔科机电技术有限公司 基于配置生产线测试产品的方法、设备及可读存储介质
CN112148271B (zh) * 2020-09-09 2021-09-24 中国科学院沈阳自动化研究所 一种装配工艺代码自动生成与注入的方法
CN112905486B (zh) * 2021-03-26 2022-07-08 建信金融科技有限责任公司 一种服务集成测试方法、装置和系统
EP4137948A1 (en) * 2021-08-16 2023-02-22 Amadeus S.A.S. Method and device for testing microservice-based computing platforms

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101334753A (zh) * 2007-06-26 2008-12-31 中兴通讯股份有限公司 一种单元测试方法及其装置
CN201607519U (zh) * 2010-01-29 2010-10-13 深圳市兆驰股份有限公司 生产流水线上的线路板功能测试设备
CN104185840A (zh) * 2012-04-30 2014-12-03 惠普发展公司，有限责任合伙企业 持续部署流水线测试的优先化
CN104407971A (zh) * 2014-11-18 2015-03-11 中国电子科技集团公司第十研究所 自动化测试嵌入式软件的方法
CN104778032A (zh) * 2014-01-09 2015-07-15 阿尔卡特朗讯 一种用于进行持续集成的方法和设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104298588B (zh) * 2013-07-16 2017-09-08 阿里巴巴集团控股有限公司 一种持续集成的实现方法及装置
US9632919B2 (en) * 2013-09-30 2017-04-25 Linkedin Corporation Request change tracker
WO2015112170A1 (en) * 2014-01-27 2015-07-30 Hewlett-Packard Development Company, L.P. Continuous integration with reusable context aware jobs

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101334753A (zh) * 2007-06-26 2008-12-31 中兴通讯股份有限公司 一种单元测试方法及其装置
CN201607519U (zh) * 2010-01-29 2010-10-13 深圳市兆驰股份有限公司 生产流水线上的线路板功能测试设备
CN104185840A (zh) * 2012-04-30 2014-12-03 惠普发展公司，有限责任合伙企业 持续部署流水线测试的优先化
CN104778032A (zh) * 2014-01-09 2015-07-15 阿尔卡特朗讯 一种用于进行持续集成的方法和设备
CN104407971A (zh) * 2014-11-18 2015-03-11 中国电子科技集团公司第十研究所 自动化测试嵌入式软件的方法

Also Published As

Publication number Publication date
CN108399082A (zh) 2018-08-14
WO2018145559A1 (zh) 2018-08-16

Similar Documents

Publication Publication Date Title
CN108399082B (zh) 一种持续集成流水线的生成方法和系统
US6363524B1 (en) System and method for assessing the need for installing software patches in a computer system
CN106033436B (zh) 一种数据库的合并方法
US9038029B2 (en) Three-dimensional GUI object stores in automation test tools
US11481440B2 (en) System and method for processing metadata to determine an object sequence
CN104423960A (zh) 一种项目持续集成的方法及系统
CN105302533A (zh) 代码同步方法和装置
CN107315689A (zh) 基于Git代码文件检索粒度的自动化回归测试方法
CN108776643B (zh) 一种基于版本控制流程的目标代码合并控制方法及系统
CN109725926B (zh) 管理基线的方法和装置以及数据处理方法
CN106708891A (zh) 一种网管数据同步方法及装置
CN112130891B (zh) 一种数据库持续部署的方法和设备
CN109828886B (zh) 一种容器云环境下的ci/cd监控方法和系统
CN106371881A (zh) 一种用于服务器内程序版本更新的方法和系统
CN112256318B (zh) 一种用于依赖产品的构建方法及设备
CN115712623B (zh) 一种基于捕获元数据变更的批量数据容错采集方法
CN114780138A (zh) 流场模拟软件代码版本管理方法、装置和存储介质
CN109361553B (zh) 配置回滚方法及装置
CN114020840A (zh) 一种数据处理方法、装置、服务器、存储介质及产品
CN110795332A (zh) 一种自动化测试方法和装置
CN110991983B (zh) 一种任务处理方法、装置、介质和设备
CN115757172A (zh) 测试执行方法、装置、存储介质及计算机设备
Karnok et al. Determination of routings and process time information from event logs
CN111080250B (zh) 流程回退补偿方法、装置、存储介质及电子设备
CN111898165A (zh) Pdm系统中技术参数变更溯源方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant