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

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

Info

Publication number
WO2018145559A1
WO2018145559A1 PCT/CN2018/072830 CN2018072830W WO2018145559A1 WO 2018145559 A1 WO2018145559 A1 WO 2018145559A1 CN 2018072830 W CN2018072830 W CN 2018072830W WO 2018145559 A1 WO2018145559 A1 WO 2018145559A1
Authority
WO
WIPO (PCT)
Prior art keywords
pipeline
test
node
link
current
Prior art date
Application number
PCT/CN2018/072830
Other languages
English (en)
French (fr)
Inventor
李广旭
Original Assignee
中兴通讯股份有限公司
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 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2018145559A1 publication Critical patent/WO2018145559A1/zh

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

Definitions

  • the present disclosure relates to the field of continuous integration (CI) in a micro-service software architecture, and in particular to a method and system for generating a continuous integration pipeline, a computer readable storage medium, and a computer device.
  • CI continuous integration
  • Continuous integration originated from Extreme Programming Development and is a software development practice. It requires each member of the development team to frequently integrate their work.
  • software continuous integration technology plays an important role in improving software quality and shortening delivery cycles.
  • the traditional continuous integration pipeline is mainly configured by manually configuring each test link, and then sequentially configuring the execution sequence of each test link according to the test pipeline execution flow. Therefore, the configuration is difficult for ordinary users. Moreover, such a continuous integration pipeline will not be changed once the configuration is completed, and the continuous integration process of each trigger is strictly performed according to this pipeline. Therefore, this continuous integration configuration method is difficult to adapt to the problem of increasing and expanding microservices. , has certain limitations.
  • An embodiment of the present disclosure provides a method for generating a continuous integration pipeline, the method comprising the steps of: acquiring a blueprint file and a configuration file of a current testing session, wherein the hierarchy of the constituent elements of the blueprint file from high to low includes: Services, microservices, service implementation, types of testing include unit testing, functional testing, system testing, merge continuous integration (MergeCI), unit testing and service implementation, functional testing and microservices, system testing and
  • the MergeCI corresponds to the service
  • the configuration file includes description information of the unit test corresponding to the current test link, and the description information includes the code warehouse address and the directory list identifier. According to the blueprint file and the configuration file, the level of the current test link and the current test link are determined.
  • the description information for the at least one unit test is matched with the pipeline ID of all current pipelines, wherein the pipeline identification information includes a code warehouse address and a directory listing identifier; and a result according to the matching Based on at least one unit test description information to obtain new pipeline and a pipeline comprising a current test link node.
  • An embodiment of the present disclosure provides a system for generating a continuous integration pipeline, the system comprising: an acquisition module configured to acquire a blueprint file and a configuration file of a current test session, wherein a hierarchy of constituent elements of the blueprint file is high
  • the order of obtaining low includes: service, micro service, service implementation, and the types of test links include unit test, function test, system test, merge and continuous integration, and the unit test corresponds to service implementation, and the function test corresponds to micro service.
  • the system test and merge continuous integration corresponds to the service
  • the configuration file includes description information of the unit test corresponding to the current test link
  • the description information includes a code warehouse address and a directory list identifier
  • the determining module is configured to be configured according to the blueprint.
  • a file and the configuration file determining a level of the current test link and at least one unit test corresponding to the current test link; and a matching module configured to describe the at least one unit test information and the current continuous integration pipeline The flow of all the pipelines in the generation system Matching identifier; and a processing module configured according to the matching result to obtain a new line containing the current test session based on the at least one node unit test description information and line identification.
  • Embodiments of the present disclosure provide a computer readable storage medium storing a computer program that, when executed by a processor of a computer, implements a method of generating a continuous integration pipeline as provided by an embodiment of the present disclosure.
  • Embodiments of the present disclosure also provide a computer device including a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the program The method steps of the continuous integration pipeline provided by the disclosed embodiments.
  • Figure 1 is a schematic diagram of a manual configuration pipeline
  • FIG. 2 is a flowchart of a method for generating a continuous integration pipeline according to Embodiment 1 of the present disclosure
  • FIG. 3 is a schematic diagram of a blueprint file provided by Embodiment 1 of the present disclosure.
  • FIG. 4 is a schematic diagram of correspondence between a blueprint file component unit and a test link type according to Embodiment 1 of the present disclosure
  • FIG. 5 is a schematic diagram of a pipeline provided in Embodiment 1 of the present disclosure.
  • FIG. 6 is a schematic diagram of a merging process of a pipeline according to Embodiment 1 of the present disclosure
  • FIG. 7 is a schematic diagram of a process of updating a pipeline according to Embodiment 1 of the present disclosure.
  • FIG. 8 is a schematic diagram of a process of generating a pipeline according to Embodiment 1 of the present disclosure.
  • FIG. 9 is a schematic diagram of a CI pipeline generation and execution process according to Embodiment 1 of the present disclosure.
  • FIG. 10 is a schematic diagram of a system for generating a continuous integration pipeline according to Embodiment 2 of the present disclosure
  • FIG. 11 is a schematic diagram of another continuous integration pipeline generation system according to Embodiment 2 of the present disclosure.
  • the inventor of the present disclosure has found that when the continuous integration pipeline is manually configured by the user, if an effective continuous integration process is to be performed on the project, the user must be aware of the functions of each link of the test, clearly understand the input and output of each link, and know how to Run the next step, which increases the difficulty of configuring continuous integration. Because the continuous integration system may serve many different sub-projects, it is difficult for ordinary users to determine the test dependencies of each sub-project.
  • Embodiment 1 is a diagrammatic representation of Embodiment 1:
  • the embodiment shows a method for generating a continuous integration pipeline, the method comprising:
  • S201 Obtain a blueprint file and a configuration file of the current test link.
  • the hierarchy of the components of the blueprint file from high to low includes: Service (S), Micro Service (MS), Service Implementation (Servicelet, SL).
  • Types of testing include Unit Test (UT), Functional Test (FT), System Test (ST), and Continuous Integration (MergeCI).
  • UT corresponds to SL
  • FT corresponds to MS
  • ST and MergeCI correspond to S.
  • the configuration file includes description information of the unit test corresponding to the current test link, and the description information includes a code warehouse address and a directory list identifier.
  • S202 Determine, according to the blueprint file and the configuration file, at least one unit test corresponding to the current test link level and the current test link.
  • the description information of the at least one unit test is matched with the pipeline identifier of all the current pipelines, where the pipeline identifier information includes a code warehouse address and a directory list identifier.
  • the new pipeline including the current test link node is obtained based on the description information of the at least one unit test and the pipeline.
  • the constituent elements of the blueprint file include a service S (Service), a micro service MS (MicroService), and a service implementation SL (Servicelet) from a high level to a low level, wherein the S and the MS belong to a logical concept, and the real The constituent unit is SL.
  • S Service
  • MS MicroService
  • SL Servicelet
  • the structural hierarchy of S, MS and SL can be seen in Figure 3. As shown in the figure, the level of the hierarchy indicates the inclusion relationship.
  • An S can contain one or more MSs, and an MS can contain one or more SLs.
  • the corresponding relationship between the test link and the constituent units of each level in the blueprint file is set, so that the blueprint file is configured in each test link.
  • the testing links in this embodiment include, but are not limited to, unit testing (UT), functional testing (FT), system testing (ST), and merge continuous integration (MergeCI).
  • UT unit testing
  • FT functional testing
  • ST system testing
  • MergeCI merge continuous integration
  • the setting of the above correspondence is set according to the number of test links, the level, and the structure of the constituent units of the blueprint file. It can be understood that if the blueprint file changes, such as an increase in constituent units or a change in the test link (such as an increase in the level of the test link), the above correspondence may be changed according to actual needs.
  • step S201 in addition to acquiring the blueprint file, the configuration file of the current test session is also acquired.
  • the current test link is one of UT, FT, ST, MergeCI and the like.
  • FT, ST, and MergeCI are all composed of at least one UT.
  • ST and MergeCI include at least one FT
  • FT includes at least one UT.
  • UT, FT, ST, and MergeCI represent different levels of the test link and correspond to at least one UT (ie, the UT corresponds to itself, the FT corresponds to each UT it contains, and ST (or MergeCI) corresponds to the UT.
  • the configuration file of the current test link contains the description information of the unit test corresponding to the current test link.
  • the description information includes a code repository address (Repo) and a directory list identifier (ContextDirs), that is, the description information is "Repo+ContextDirs".
  • the identification information of the pipeline in the system is also represented by the code repository address (Repo) + directory list identifier (ContextDirs), which is represented by "Repo+ContextDirs”. It can be understood that in the blueprint file, the UT corresponds to the SL, so the Repo+ContextDirs of the UT uniquely identifies the corresponding SL.
  • the configuration file can be pre-configured by the user.
  • the level of the component unit of the blueprint file corresponding to the current test link, the level of the current test link and the information of the test link of each level can be obtained, so that the current test link can be obtained.
  • the current test link is ST in the configuration file
  • the ST corresponds to S
  • the S query is performed to the MS
  • the MS queries the SL
  • the SL corresponds to the UT, so the query needs to be queried twice. Only the information of the UT corresponding to the ST can be found. For different levels of testing, the number of times the query gets UT and SL is different.
  • step S203 the description information of at least one UT in the current test link is matched with the pipeline identifier of all the pipelines in the CI system, which is actually a code warehouse address and directory list of each UT corresponding to the current test link.
  • the identification matches the code repository address and directory listing identifier of the pipeline in the system. That is, the matching process includes a two-part match, a match to the code repository address, and a match to the directory listing identifier.
  • the method of obtaining the pipeline may be different, but based on the description information of the at least one unit test and the pipeline identifier, a new pipeline including the current test link node is obtained.
  • the pipeline structure is composed of a pipeline header, a UT test link layer, an FT test link layer, an ST test link layer, and a MergeCI test link layer.
  • each type of test link level consists of different number of test links.
  • the methods for obtaining a new pipeline include, but are not limited to, the following:
  • Merger method If there is at least one pipeline whose code warehouse address is the same as the unit test code warehouse address, and at least one pipeline's directory list is identified as a subset of the unit test's directory list identifier, then the unit test code warehouse address and directory The list identifies a new pipeline that contains the current test session node for the pipeline header information, and merges the created at least one pipeline into the new pipeline.
  • creating a new pipeline containing the current test session node for the pipeline header information with the code warehouse address and directory list identification of the unit test, and merging the created at least one pipeline into the new pipeline includes:
  • the node list is a new test node for the current test session and the test link below the current test link level, and the newly created test node is added to the node list corresponding to the new pipeline.
  • the current test link is a unit test link
  • the unit test is UT-x
  • the corresponding description information is RePo1+[A/B/C]
  • the pipeline is matched. If the pipeline's code repository address is the same as UT-x's Repo1, and the pipeline's ContextDirs is included by [A/B/C], such as the pipeline shown in Figure 6, Pipeline Repo1+[A/B] , where [A/B] is a subset of [A/B/C], a new pipeline header is created.
  • the current UT-x identification information (Repo+ContextDirs) is used as the header identification information of the new pipeline, and the pipeline of the Pipeline Repo1+[A/B] which is a subset relationship with the current UT-x is completely incorporated into the newly created pipeline.
  • the current UT-x creates a node and adds the created node to the newly created pipeline. Specifically, create a UT list information for the new pipeline. When initially created, there are currently no UT nodes in the UT list. First, each UT node in the UT node list in the subset relationship Pipeline Repo1+[A/B] is extracted and added to the new UT node list. This new list of UT nodes is created successfully.
  • a UT-x node is also created and added to the UT node list.
  • the final result is the UT-x description information for the pipeline, including the pipeline that becomes a subset Pipeline Repo1+[A/B] And a new pipeline for UT-x nodes.
  • the pipeline that has been merged in the current CI system is deleted when the new pipeline structure is generated.
  • the test resources and time are wasted, and the nodes cannot be duplicated when merging.
  • the process of excluding duplicate nodes may be performed during the merging process. For example, if there are two pipelines that have a subset relationship with UT-x, it is determined whether there are duplicate nodes in the two pipelines during the merging process, and if it is determined that there is Duplicate nodes remove redundant duplicate nodes.
  • the process of excluding duplicate nodes may also be performed after the completion of the merge process, that is, after the new pipeline is created, it is determined whether there are duplicate nodes in the pipeline, and if there are duplicate nodes, the redundant duplicate nodes are deleted.
  • Update method if there is at least one pipeline, the code warehouse address is the same as the unit test code warehouse address, and the unit test directory list is identified as a subset of at least one pipeline directory list identifier, or the unit test directory list identifier and at least one The directory list identifier of the pipeline is the same; at least one pipeline is updated according to the code warehouse address and directory list identifier of the unit test.
  • the existing pipeline is updated with the information of the unit test to obtain a new pipeline.
  • the existing pipeline header information remains unchanged, and only new nodes are added according to the current test session.
  • the step of updating at least one pipeline according to the code warehouse address and the directory list identifier of the unit test includes: creating a test node of the current test link and a test link below the current test link level, and adding the created test node to at least one pipeline In the corresponding node list; if at least one of the pipelines does not have a node list corresponding to the current test link, a node list of the current test link is created in the pipeline, and a test link of the current test link and the test link level below the current test link level is created. The node adds the created test node to the corresponding node list.
  • the directory list identifier of a certain UT of the current test link is the same as the directory list identifier of multiple pipelines in the system, or a subset of the directory list identifiers of multiple pipelines in the system, when updating,
  • the plurality of pipelines need to be updated, that is, the nodes of the current test session are added to the plurality of pipelines.
  • the current test link is a unit test link
  • the corresponding unit test is UT-x
  • the description information is Repo1+[A].
  • the pipeline is identified as Repo1+[A/B]
  • UT-x is the same as the Repo of the pipeline (both "Repo1")
  • ContextDirs([A]) of UT-x is the ContextDirs of the pipeline.
  • a subset of ([A/B]) so update the pipeline with UT-x.
  • the node that creates the current test session that is, the node that creates the UT-x
  • the current test session has a higher level, such as FT, ST or MergeCI.
  • FT high level
  • the current test session is the ST test link.
  • the highest level test link of the pipeline is FT.
  • the UT node will be included in the list of pipeline UT nodes associated with the UT test session in the CI system.
  • other types of test links are the same as those of FT, ST, MergeCI and UT, and will not be described separately.
  • the list of nodes to be created includes a list of ST and FT nodes, and the branch of the pipeline in the process of updating includes UT-FT- ST three levels of nodes.
  • each node information in the node list of each pipeline is different, that is, there is no duplicate node. Therefore, in some embodiments, during the update process of the pipeline or after the update is completed, it is judged whether there are duplicate nodes in the updated pipeline, and if it is determined that there are duplicate nodes in the updated pipeline, the redundant duplicate nodes are deleted.
  • Generating method If the code warehouse address of the unit test is different from the code warehouse address of all pipelines, or the directory list identifier of the unit test has no intersection with the directory list identifier of all the pipelines, the code warehouse address and the directory list identifier are generated according to the unit test. The new pipeline of the current test session node.
  • the step of generating a new pipeline containing the current test session node based on the code warehouse address and the directory listing identifier of the unit test includes: creating a new pipeline header, identifying the code warehouse address of the unit test and the directory listing as new pipeline information Create a node list and a test node for the current test session and the test link below the current test session level, and add the corresponding test node to the node list.
  • the UT test configuration object layer is created. If the unit test (or SL) data comes from the FT test, then the FT test configuration object layer is created.
  • the FT test configuration object layer is created.
  • the created node list and the generated test node include the current test link layer and below. The hierarchical node list and the test node. For example, if the current test link is ST, the generated pipeline includes both the ST node and the FT node and the UT node.
  • the current test link is the UT test link, specifically UT-x, whose code warehouse address and directory list are identified as Repo1+[D/E], assuming that only the pipeline of the pipeline "pipeline" in the system is identified as Repo1+[A/B], Since UT-x is the same as the Repo of the pipeline, but the directory listing identifies no intersection, a new pipeline needs to be created in UT-x.
  • UT-x is the same as the Repo of the pipeline, but the directory listing identifies no intersection, a new pipeline needs to be created in UT-x.
  • the created node list includes the FT node list and the UT node list.
  • the test link in the pipeline includes the FT test link and the UT test link. .
  • the UT is used as an example to illustrate the automatic generation method of the pipeline, for the FT test. It can be known from the FT blueprint description information that the FT corresponds to the MS in the blueprint file, and the MS may contain multiple SL information. Therefore, there are some differences between the process of generating Pipeline in the FT test session and the process of generating Pipeline in the UT test session. The main difference is the process of finding the SL. In the process of generating Pipeline in the FT test, firstly, each SL identification information corresponding to the blueprint file description of the FT test link, that is, Repo and ContextDirs, is extracted, and then compared with the Repo and ContextDirs of each pipeline of the current CI system. The matching process of a specific SL is consistent with the UT process, and the processing of the UT test link can be referred to.
  • the processing of the ST and MergeCI test links is basically the same as the FT test, and the difference is also the process of finding the SL.
  • the FT corresponding blueprint file can be found by the MS to the SL information, and the ST and MergeCI need to query twice. First, all the MS information is queried by the service information, and then all the SL information is found by all the MS information, and then the information of each SL is compared with the pipeline identification information in the CI system. The comparison process of a single SL is still consistent with the processing of the UT test.
  • the configuration file and the blueprint configuration of the test link of the user are mainly received as inputs.
  • the blueprint configuration mainly exists as a basic configuration in the system of the present disclosure.
  • the configuration file of the test link is mainly used as a common configuration.
  • the difference between the normal configuration and the basic configuration is mainly in the frequency of change.
  • the base configuration (blueprint configuration) is more stable than the normal configuration (test link configuration file) parameter.
  • FIG. 9 shows a CI pipeline generation and execution process.
  • the automatic generation algorithm (merging, updating, and generating) according to the above is performed.
  • the pipeline is generated, and the final output is a collection of pipelines (one or more pipelines).
  • the execution subsystem corresponding to the CI system is then executed by the execution subsystem described in the present disclosure as a standard input for each pipeline template in the pipeline set.
  • the code warehouse is monitored.
  • the change event (another input) of the code warehouse is received, the corresponding CI system execution process is performed. Further, a test report of the current execution CI is generated by each CI pipeline.
  • the user no longer needs to understand the dependencies of each sub-project, and only needs to know the relevant test items of the current project.
  • the dependency of each subproject is solved by a blueprint method and structure.
  • the development and test personnel of each sub-project only need to pre-define the blueprint files of each test link of this sub-project.
  • users no longer need to pay attention to the composition of the entire pipeline. They only need to pay attention to their own testing fields, and greatly improve the testing efficiency by isolating the areas of concern.
  • the blueprint file used to describe the CI test link is used to describe the dependencies between the various test links.
  • each CI test link is no longer fixed with a certain CI pipeline.
  • the relationship is automatically separated and extended according to the blueprint file description relationship. Better adapt to the use of micro-services and improve adaptability.
  • each test link of all CI pipelines is compared, and the redundant test link is deleted by an automated screening method of the pipeline. Avoid wasting valuable test resources.
  • Embodiment 2 is a diagrammatic representation of Embodiment 1:
  • this embodiment shows a system for generating a continuous integration pipeline, the system comprising:
  • the obtaining module 11 is configured to obtain a blueprint file and a configuration file of the current testing session.
  • the hierarchy of the blueprint file components from high to low includes: services, microservices, and service implementation.
  • Types of testing include unit testing, functional testing, system testing, and MergeCI.
  • Unit testing corresponds to service implementation
  • functional testing corresponds to microservices
  • system testing and MergeCI correspond to services.
  • the configuration file includes description information of the unit test corresponding to the current test link, and the description information includes a code warehouse address and a directory list identifier;
  • the determining module 12 is configured to determine, according to the blueprint file and the configuration file, at least one unit test corresponding to the current test link level and the current test link;
  • the matching module 13 is configured to match the description information of the at least one unit test with the pipeline identifier of all pipelines in the current continuous integration pipeline generation system;
  • the processing module 14 is configured to obtain a new pipeline including the current test link node based on the matching result and the description information of the at least one unit test and the pipeline identifier.
  • the blueprint file is a blueprint file in the prior art, and its basic constituent unit is the same as in the prior art, and the constituent unit includes a service (S), a micro service (MS) and a sequence from high level to low level.
  • the service implements SL (SL), where S and MS are logical concepts, and the real component is SL.
  • S may include one or more MSs.
  • MS may include one or more SLs.
  • the corresponding relationship between the test link and the constituent units of each level in the blueprint file is set, so that the blueprint file is configured in each test link.
  • the testing links in this embodiment include, but are not limited to, Unit Test (UT), Functional Test (FU), System Test (ST), MergeCI merge continuous integration, test links and blueprint files.
  • the correspondence of the units is as shown in FIG. 4 in the first embodiment.
  • the UT corresponds to the SL in the blueprint file
  • the FT corresponds to the MS in the blueprint file
  • the ST and the MergeCI correspond to the S in the blueprint file.
  • the setting of the corresponding relationship is set according to the number of test links, the level, and the structure of the constituent units of the blueprint file. It can be understood that if the blueprint file changes, such as an increase in constituent units or the like, Changes in the link, such as the increase in the level of the test link, etc., the above correspondence can be changed according to actual needs.
  • the current test link is one of UT, FT, ST, MergeCI and the like.
  • FT, ST, and MergeCI are all composed of at least one UT.
  • ST and MergeCI include at least one FT
  • FT includes at least one UT.
  • UT, FT, ST, and MergeCI represent different levels of the test link, and correspond to at least one UT (the UT corresponds to itself, the FT corresponds to each UT it contains, and the ST (or MergeCI) corresponds to each FT it contains.
  • the configuration file of the current test link contains the description information of the unit test corresponding to the current test link.
  • the description information includes the code repository address and the directory listing identifier, ie "Repo+ContextDirs".
  • the identification information of the pipeline in the system uses the code warehouse address + directory list identifier combination, which is represented by "Repo+ContextDirs". It can be understood that in the blueprint file, the UT corresponds to the SL, so the Repo+ContextDirs of the UT uniquely identifies the corresponding SL.
  • the configuration file acquired by the obtaining module 11 may be pre-configured by the user.
  • the determining module 12 can determine the level of the component unit of the blueprint file corresponding to the current test link, the level of the current test link, and the information of the test link of each level according to the information in the blueprint file and the configuration file. Therefore, the determining module 12 can obtain information of at least one UT corresponding to the current test link. For example, if the current test link is ST in the configuration file, the determining module 12 knows that the ST corresponds to the S, and the S corresponds to the S, and the S query to the MS, and then the MS queries the SL, and the SL corresponds to the UT, so the determining module 12 needs to query. The information of the UT corresponding to the ST can be found twice. For different levels of testing, the number of times the query gets UT and SL is different.
  • the matching module 13 matches the description information of at least one UT in the current testing link with the pipeline identifier of all the pipelines in the CI system, which is actually the code warehouse address and directory list identifier of each UT corresponding to the current testing link.
  • the code warehouse address and directory list identifier of the pipeline in the CI system are matched separately. That is, the matching process includes a two-part match, a match to the code repository address, and a match to the directory listing identifier.
  • the method of obtaining the pipeline may be different, but based on the description information of the at least one unit test and the pipeline identifier, a new pipeline containing the nodes of the current test session is obtained.
  • the pipeline structure is composed of a pipeline header, a UT test link layer, an FT test link layer, an ST test link layer, and a MergeCI test link layer.
  • each type of test link level consists of different number of test links.
  • the processing module 14 has a different method of obtaining a new pipeline.
  • the processing module 14 includes a first processing module 141 configured to have the same code repository address of the at least one pipeline and the code repository address of the unit test, and the directory listing of the at least one pipeline is identified as a directory listing of the unit test A subset of the identification, the code warehouse address and the directory list identifier of the unit test are used to create a new pipeline containing the current test session node for the pipeline header information, and at least one pipeline is merged into the new pipeline.
  • the first processing module 141 is configured to create a new pipeline header, identify the code warehouse address and the directory list of the unit test as new pipeline information, create a node list of the new pipeline, and extract each test link in the at least one pipeline.
  • the test node joins the corresponding node list in the new pipeline, and newly creates a test node for the current test link and the test link below the current test link level, and joins the node list corresponding to the new pipeline.
  • the system for generating a continuous integration pipeline in this embodiment further includes a second de-duplication module 16 configured to delete the pipeline that has been merged in the current system during the merge process of the pipeline or after the merge process is completed; Whether there are duplicate nodes in the pipeline, if it is determined that there are duplicate nodes in the new pipeline, the redundant nodes are deleted.
  • the processing module 14 includes a second processing module 142 configured to have the same code warehouse address as the at least one pipeline and the code warehouse address of the unit test, and the directory list of the unit test is identified as a directory of at least one pipeline.
  • the subset of the list identification, or the directory listing identifier of the unit test is the same as the directory listing identifier of the at least one pipeline; the at least one pipeline is updated according to the code warehouse address and the directory listing identifier of the unit test.
  • the second processing module 142 updates the existing pipeline with the information of the unit test to obtain a new pipeline.
  • the existing pipeline header information remains unchanged, and only new nodes are added based on the current test session.
  • the second processing module 142 is configured to create a test node of the current test link and the test link below the current test link level, and join the node list corresponding to at least one pipeline; if at least one pipeline in the pipeline has no corresponding test link corresponding to the current test link
  • the node list is used to create a node list of the current test link in a pipeline, and the test node of the current test link and the test link below the current test link level is added to the corresponding node list.
  • the directory list identifier of a certain UT of the current test link is the same as the directory list identifier of multiple pipelines in the system, or a subset of the directory list identifiers of multiple pipelines in the system.
  • you need to update the multiple pipelines that is, add the nodes of the current test link in the multiple pipelines.
  • the system for generating a continuous integration pipeline in this embodiment further includes a first de-duplication module 15 configured to determine whether there are duplicate nodes in the pipeline after updating the pipeline or updating the pipeline, if it is determined If there are duplicate nodes, the redundant nodes are deleted.
  • the processing module 14 includes a third processing module 143 configured to specify that the code warehouse address of the unit test is different from the code warehouse address of all pipelines, or the directory list identifier of the unit test and the directory list identifier of all pipelines. At the intersection, a new pipeline containing the nodes of the current test session is generated according to the code warehouse address and the directory list identifier of the unit test.
  • the third processing module 143 completely generates a completely new pipeline with the information of the current test link, in the process of generating a new pipeline. It is foreseeable that a new pipeline header needs to be created, and the header information is a description of the unit test in the current test session that satisfies the conditions for using the generation method.
  • the third processing module 143 is configured to create a new pipeline header, the code warehouse address and the directory list identifier of the unit test as the new pipeline information, and create a node list of the current test link and the test link below the current test link level. And test the node, add the corresponding test node in the node list.
  • the third processing module 143 creates a node list and the generated test node in the process of creating a new pipeline, including the current test link layer and the following layers.
  • the node list and the test node For example, if the current test link is ST, the generated pipeline includes the ST node, and also includes the FT node and the UT node.
  • the automatic generation method of the pipeline can refer to the related description of the first embodiment, and details are not described herein.
  • the FT test session It can be known from the FT blueprint description information that the FT corresponds to the MS in the blueprint file, and the MS may contain multiple SL information. Therefore, there are some differences between the process of generating Pipeline in the FT test session and the process of generating Pipeline in the UT test session. The main difference is the process of finding the SL.
  • each SL identification information corresponding to the blueprint file description of the FT test link that is, Repo and ContextDirs
  • Repo and ContextDirs is extracted, and then compared with the Repo and ContextDirs of each pipeline of the current CI system.
  • the matching process of a specific SL is consistent with the UT process, and the processing of the UT test link can be referred to.
  • the processing of the ST and MergeCI test links is basically the same as the FT test, and the difference is also the process of finding the SL.
  • the FT corresponding blueprint file can be found by the MS to the SL information, and the ST and MergeCI need to query twice. First, all the MS information is queried by the service information, and then found by all the MS information. All SL information is then compared to whether the information of each SL matches the pipeline identification information in the CI system. The comparison process of a single SL is still consistent with the processing of the UT test.
  • the acquisition module 11 mainly receives the configuration file and blueprint configuration of the user's test session as input.
  • the blueprint configuration mainly exists as a basic configuration in the system of the present disclosure, and the configuration file of the test link is mainly used as a common configuration.
  • the difference between the normal configuration and the basic configuration is mainly in the frequency of change.
  • the base configuration (blueprint configuration) is more stable than the normal configuration (test link configuration file) parameter.
  • the processing module 14 after receiving the configuration file of the user, performs the pipeline generation according to the above-mentioned automated generation algorithm (merging, updating, and generating), and the final output result is a pipeline set. (one or more pipelines).
  • the execution subsystem described by the present disclosure then performs each of the pipeline templates in the pipeline set as a standard input to perform the startup of the corresponding CI system.
  • the code warehouse is monitored.
  • the change event (another input) of the code warehouse is received, the corresponding CI system execution process is performed. Further, a test report of the current execution CI is generated by each CI pipeline.
  • the dependency relationship of each sub-project is solved by a blueprint method and structure, and each sub-project development and tester only needs to predefine the blueprint file of each test link of the sub-project. Just fine.
  • the system utilizes the process of merging, updating, and generating pipelines, so that users no longer need to pay attention to the composition of the entire pipeline. They only need to pay attention to their own testing fields, and greatly improve the testing efficiency by isolating the areas of concern.
  • the blueprint file used to describe the CI test link is used to describe the dependencies between the various test links. With the structure of the blueprint file of each CI test link, each CI test link is no longer fixed with a certain CI pipeline. Correspondingly, the relationship is automatically separated and extended according to the blueprint file description relationship. Better adapt to the use of micro-services and improve adaptability.
  • modules or steps of the present disclosure can be implemented by a general computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in a storage medium (ROM/RAM, diskette, optical disk) by a computing device, and in some cases The steps shown or described may be performed in an order different than that herein, or they may be separately fabricated into individual integrated circuit modules, or a plurality of the modules or steps may be implemented as a single integrated circuit module. Therefore, the present disclosure is not limited to any specific combination of hardware and software.
  • Embodiments of the present disclosure provide a computer readable storage medium storing a computer program that, when executed by a processor of a computer, implements a method of generating a continuous integration pipeline as provided by an embodiment of the present disclosure.
  • Embodiments of the present disclosure also provide a computer device including a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor executing the program to implement an embodiment as disclosed The method steps of the continuous integration pipeline provided.
  • the corresponding pipeline can be automatically generated according to the information of the current test link, thereby avoiding the disadvantages of low efficiency and time consuming caused by the manual generation of the pipeline.

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)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供了一种持续集成流水线的生成方法和系统。该方法包括：获取蓝图文件和当前测试环节的配置文件，测试环节包括与蓝图文件中的服务实现对应的单元测试、与微服务对应的功能测试、以及与服务对应的系统测试和归并持续集成，其中配置文件包括当前测试环节对应的单元测试的描述信息；根据蓝图文件与配置文件，确定当前测试环节的层次和当前测试环节对应的至少一个单元测试；对所述至少一个单元测试的描述信息与所有流水线的流水线标识进行匹配；根据所述匹配的结果，基于所述至少一个单元测试的描述信息以及流水线得到包含当前测试环节节点的新流水线。

Description

持续集成流水线的生成方法和系统 技术领域
本公开涉及微服务软件架构中持续集成(Continuous Integration，CI)领域，具体涉及一种持续集成流水线的生成方法及系统、计算机可读存储介质、计算机设备。
背景技术
在软件持续集成(Continuous Integration，CI)领域，软件自动化测试与部署已经得到广泛的应用。持续集成起源于极限编程开发，是一种软件开发实践。它要求开发小组的每个成员频繁的集成他们的工作成果。在软件工程领域，软件的自动化持续集成技术对于提高软件质量与缩短交付周期都发挥了重要的作用。
传统持续集成流水线(pipeline)的生成主要采用人工方式来配置各个测试环节，然后根据测试流水线执行流程依次配置每个测试环节的执行顺序，因此，对于普通用户来说配置难度高。而且，这样的持续集成流水线一旦配置完成后不会进行改变，每次触发的持续集成过程都要按照这个流水线严格执行，因此，这种持续集成配置方法难以适应微服务的不断增加与扩展的问题，具有一定的局限性。
发明内容
本公开的实施例提供一种持续集成流水线的生成方法，所述方法包括以下步骤：获取蓝图文件和当前测试环节的配置文件，其中，蓝图文件的组成单元的层次从高到获取低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、归并持续集成(Merge Continuous integration，MergeCI)，单元测试与服务实现对应，功能测试与微服务对应，系统测试和MergeCI与服务对应，配置文件包括当前测试环节对应的单元测试的描述信息，并且 描述信息包括代码仓库地址和目录列表标识；根据蓝图文件与配置文件，确定当前测试环节的层次和当前测试环节对应的至少一个单元测试；对至少一个单元测试的描述信息与当前所有流水线的流水线标识进行匹配，其中，流水线标识信息包括代码仓库地址和目录列表标识；以及根据所述匹配的结果，基于至少一个单元测试的描述信息以及流水线得到包含当前测试环节节点的新流水线。
本公开的实施例提供了一种持续集成流水线的生成系统，所述系统包括：获取模块，配置为获取蓝图文件和当前测试环节的配置文件，其中，所述蓝图文件的组成单元的层次从高到获取低依次包括：服务、微服务、服务实现，测试环节的类型包括单元测试、功能测试、系统测试、归并持续集成，所述单元测试与服务实现对应，所述功能测试与微服务对应，所述系统测试和归并持续集成与服务对应，所述配置文件包括当前测试环节对应的单元测试的描述信息，所述描述信息包括代码仓库地址和目录列表标识；确定模块，配置为根据所述蓝图文件与所述配置文件，确定所述当前测试环节的层次和所述当前测试环节对应的至少一个单元测试；匹配模块，配置为对所述至少一个单元测试的描述信息与当前所述持续集成流水线的生成系统中所有流水线的流水线标识进行匹配；以及处理模块，配置为根据所述匹配的结果，基于所述至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线。
本公开的实施例提供了一种存储有计算机程序的计算机可读存储介质，所述计算机程序在被计算机的处理器执行时实现如本公开的实施例所提供的持续集成流水线的生成方法步骤。
本公开的实施例还提供了一种计算机设备，所述计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如本公开的实施例所提供的持续集成流水线的方法步骤。
附图说明
图1为手动配置流水线的示意图；
图2为本公开实施例一提供的一种持续集成流水线的生成方法的流程图；
图3为本公开实施例一提供的蓝图文件的示意图；
图4为本公开实施例一提供的蓝图文件组成单元与测试环节类型的对应关系示意图；
图5为本公开实施例一提供的流水线的示意图；
图6为本公开实施例一提供的流水线的归并过程的示意图；
图7为本公开实施例一提供的流水线的更新过程的示意图；
图8为本公开实施例一提供的流水线的生成过程的示意图；
图9为本公开实施例一中CI流水线生成与执行过程的示意图；
图10为本公开实施例二提供的一种持续集成流水线的生成系统的示意图；
图11为本公开实施例二提供的另一种持续集成流水线的生成系统的示意图。
具体实施方式
下面通过具体实施方式结合附图对本公开作进一步详细说明，应当理解，以下所说明的示例性实施例仅用于说明和解释本公开，并不用于限定本公开。
本公开的发明人发现，当持续集成流水线是由用户手动进行配置时，如果要对项目进行有效的持续集成流程，用户必须清楚测试的各个环节的功能，清楚每个环节的输入输出，知道如何运行下一个环节，从而提高了配置持续集成的难度。因为持续集成系统可能服务于很多不同的子项目，普通的用户很难确定各个子项目的测试依赖。
这样手动配置的流水线一旦配置完成，在测试过程中就不会进行改变。这样直接导致了：可能出现重复测试的问题。如图1所示，如果CI流水线环节2与CI流水先环节3相同，那么会导致在两个不同的CI流水线模板中存在的相同的测试项。在手动配置流水线的处理中这样的问题很难被发现，直接导致测试资源的浪费。
在微服务软件开发领域这种持续集成配置方法具有一定的局限 性。这是因为在微服务软件架构中每个服务能够独立的编译、测试与发布；同时伴随着系统功能的增加与扩展，会有新的微服务加入到系统中。整个软件系统的依赖关系是可能变化的，这就导致了持续集成系统的流水线是需要不断的变化。传统的手动配置的持续集成方法很难适应这一场景。本公开的以下实施例旨在解决上述问题。
实施例一：
参见图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)、功能测试(FT)、系统测试(ST)、归并持续集成(MergeCI)。测试环节与蓝图文件中组成单元的对应关系如图4所示。其中，UT对应蓝图文件中的SL，FT对应蓝图文件中的MS，ST和MergeCI对应蓝图文件中的S。在一些实施方式中，上述的对应关系的设定是根据测试环节的数量、层次以及蓝图文件的组成单元的结构设置的。可以理解的是，若蓝图文件出现变化，如组成单元增多或者测试环节发生变化(如测试环节的层次增多等)，则上述的对应关系可以随实际的需求进行变化。
在步骤S201中，除了获取蓝图文件，还获取了当前测试环节的配置文件。可以理解的是，当前测试环节是UT、FT、ST、MergeCI等中的一种。其中，FT、ST、MergeCI都是由至少一个UT构成的。根据上述的对应关系以及图4，ST和MergeCI中包含至少一个FT，而FT中包含了至少一个UT。换言之，UT、FT、ST、MergeCI代表了测试环节的不同层次，且分别对应至少一个UT(即，UT对应其自身，FT对应其所包含的各UT，ST(或MergeCI)对应其所包含的各FT所包含的各UT)。当前测试环节的配置文件中包含了当前测试环节对应的单元测试的描述信息。该描述信息包括代码仓库地址(Repo)和目录列表标识(ContextDirs)，即描述信息为“Repo+ContextDirs”。而系统中的流水线的标识信息也使用代码仓库地址(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的代码仓库地址和目录列表标识与系统中流水线的代码仓库地址和目录列表标识分别进行匹配。即该匹配过程包括两部分的匹配，对代码仓库地址的匹配，以及对目录列表标识的匹配。对于不同的匹配结果，得到流水线的方法可能不同，但是都是基于该至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线。
参见图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的描述信息为流水线标识的，包含了成为子集的流水线Pipeline Repo1+[A/B]以及UT-x节点的新流水线。
在一些实施方式中，为了避免新旧流水线的重复，在新的pipeline结构生成时，删除当前CI系统中已被归并的pipeline。在一些实施方式中，为了避免新建的流水线中的节点重复，浪费测试资源和时间，在归并时要保证节点不能重复。具体的，排除重复节点的过程可以在归并过程中进行，如与UT-x成为子集关系的流水线有两条，则在归并 过程中判断两条流水线中是否具有重复的节点，如果判断出有重复的节点，就删除冗余的重复的节点。另外，排除重复节点的过程也可以在归并过程完成后进行，即，在新流水线创建完成后，再判断流水线中是否有重复节点，若有重复节点，则删除冗余的重复的节点。
更新法：若存在至少一个流水线的代码仓库地址和单元测试的代码仓库地址相同，且单元测试的目录列表标识为至少一个流水线的目录列表标识的子集，或单元测试的目录列表标识与至少一个流水线的目录列表标识相同；则根据单元测试的代码仓库地址和目录列表标识更新至少一个流水线。
在更新法中，是以单元测试的信息更新现有的流水线得到新流水线的方法。在该更新过程中，现有流水线头信息不变，只根据当前的测试环节增加新的节点。具体的，根据单元测试的代码仓库地址和目录列表标识更新至少一个流水线的步骤包括：创建当前测试环节以及当前测试环节层次以下的测试环节的测试节点，将所创建的测试节点加入到至少一个流水线对应的节点列表中；若至少一个流水线中某流水线没有当前测试环节对应的节点列表，则在该流水线中创建当前测试环节的节点列表，创建当前测试环节以及当前测试环节层次以下的测试环节的测试节点，将所创建的测试节点加入对应的节点列表。
在上述的过程中，如果当前测试环节的某个UT的目录列表标识与系统中多个pipeline的目录列表标识相同，或为系统中多个pipeline的目录列表标识的子集，则在更新时，需要对这多个pipeline都进行更新，即在所述多个pipeline中都加入当前测试环节的节点。
下面结合图7，对更新流水线的过程进行解释说明。
假设当前的测试环节是单元测试环节，对应的单元测试为UT-x，其描述信息为Repo1+[A]。若在系统中存在一流水线，其流水线标识为Repo1+[A/B]，由于UT-x与pipeline的Repo相同(均为“Repo1”)，UT-x的ContextDirs([A])为pipeline的ContextDirs([A/B])的子集，所以以UT-x更新pipeline。具体的，创建当前测试环节的节点，即创建UT-x的节点，将该节点加入到pipeline中对应的节点列表中，即将UT-x节点加入到pipeline的UT节点列表中。
另外，在某些情况下，当前测试环节的层次较高，如为FT、ST或MergeCI，在某些需要更新的流水线中，没有当前测试环节的节点列表。例如当前测试环节为ST测试环节，流水线的最高层次测试环节是FT，则需要在该pipeline中创建当前测试环节的节点列表，再创建当前测试环节的节点，将所创建的节点加入对应的节点列表中。如果执行成功，CI系统中与该UT测试环节相关的pipeline UT节点列表中都会包含该UT节点。其中，其他类型的测试环节与FT、ST、MergeCI与UT的执行过程一样，不再进行单独描述。但是可以理解的是，若需要更新的流水线中只有UT节点列表，而当前测试环节为ST，则需要创建的节点列表包括ST和FT节点列表，更新的过程中流水线增加的分支包括UT-FT-ST三个层次的节点。
在一些实施例中，在更新过程中，需要保证每一个pipeline的节点列表中每个节点信息不同，即没有重复节点。所以在一些实施例中，在流水线的更新过程中或更新完成后，判断更新的流水线中是否有重复的节点，若判断出更新的流水线中有重复的节点，则删除冗余的重复的节点。
生成法：若单元测试的代码仓库地址与所有流水线的代码仓库地址不同，或单元测试的目录列表标识与所有流水线的目录列表标识无交集，则根据单元测试的代码仓库地址和目录列表标识生成包含当前测试环节节点的新流水线。
该生成法中，完全是以当前测试环节的信息生成一个全新的流水线，在生成新流水线的过程中。需要创建新的流水线头(pipeline 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创建新流水线。在创建新流水线的过程中，首先创建流水线头，将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测试环节生成Pipeline的流程中，首先提取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)，微服务(MS)和服务实现SL(SL)，其中，S和MS属于逻辑概念，真正的组成单元是SL。S、MS和SL的结构层次可参见实施例一中的图3，一个S可以包含一个或多个MS，同理，一个MS可以包含一个或多个SL。
在本实施例中，为了实现流水线的自动生成，将测试环节和蓝图文件中各层次的组成单元进行了对应关系的设置，使得各个测试环节都配置了蓝图文件。本实施例中的测试环节包括但不限于单元测试(Unit Test，UT)、功能测试(Functional Test，FU)、系统测试(System Test，ST)、MergeCI合并持续集成，测试环节与蓝图文件中组成单元的对应关系如实施例一中的图4所示。其中，UT对应蓝图文件中的SL，FT对应蓝图文件中的MS，ST和MergeCI对应蓝图文件中的S。在本实施例中，上述的对应关系的设定是根据测试环节的数量、 层次以及蓝图文件的组成单元的结构设置的，可以理解的是，若蓝图文件出现变化，如组成单元增多等或者测试环节发生变化，如测试环节的层次增多等，上述的对应关系可以随实际的需求进行变化。
可以理解的是，当前测试环节是UT、FT、ST、MergeCI等中的一种。其中，FT、ST、MergeCI都是以至少一个UT构成的。根据上述的对应关系以及图4，ST和MergeCI中包含至少一个FT，而FT中包含了至少一个UT。换言之，UT、FT、ST、MergeCI代表了测试环节的不同层次，且分别对应至少一个UT(UT对应其自身，FT对应其所包含的各UT，ST(或MergeCI)对应其所包含的各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的代码仓库地址和目录列表标识与CI系统中流水线的代码仓库地址和目录列表标识分别进行匹配。即该匹配过程包括两部分的匹配，对代码仓库地址的匹配，以及对目录列表标识的匹配。对 于不同的匹配结果，得到流水线的方法可能不同，但是都是基于该至少一个单元测试的描述信息以及流水线标识得到包含当前测试环节节点的新流水线。
在本实施例中，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测试环节生成Pipeline的流程中，首先提取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 (12)

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

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2018145559A1 true WO2018145559A1 (zh) 2018-08-16

Family

ID=63094364

Family Applications (1)

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

Country Status (2)

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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110780885A (zh) * 2019-10-15 2020-02-11 卡斯柯信号有限公司 Cbtc中ats和联锁软件数据自动部署和环境启动装置及方法
US10872028B2 (en) 2019-03-01 2020-12-22 Red Hat Israel, Ltd. Methods and systems for identifying duplicate jobs in a continuous integration environment
US20230054780A1 (en) * 2021-08-16 2023-02-23 Amadeus S.A.S. Method and device for testing microservice-based computing platforms

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110895460A (zh) * 2018-09-13 2020-03-20 深圳市优必选科技有限公司 基于Jenkins的机器人系统集成方法、装置及终端设备
CN110018964A (zh) * 2019-04-12 2019-07-16 广东电网有限责任公司信息中心 一种面向电力行业研发测试流水线构建方法
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 建信金融科技有限责任公司 一种服务集成测试方法、装置和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104185840A (zh) * 2012-04-30 2014-12-03 惠普发展公司，有限责任合伙企业 持续部署流水线测试的优先化
CN104298588A (zh) * 2013-07-16 2015-01-21 阿里巴巴集团控股有限公司 一种持续集成的实现方法及装置
CN104407971A (zh) * 2014-11-18 2015-03-11 中国电子科技集团公司第十研究所 自动化测试嵌入式软件的方法
CN104778032A (zh) * 2014-01-09 2015-07-15 阿尔卡特朗讯 一种用于进行持续集成的方法和设备
US20170010889A1 (en) * 2014-01-27 2017-01-12 Hewlett Packard Enterprise Development Lp Continuous integration with reusable context aware jobs

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101334753B (zh) * 2007-06-26 2012-03-07 中兴通讯股份有限公司 一种单元测试方法及其装置
CN201607519U (zh) * 2010-01-29 2010-10-13 深圳市兆驰股份有限公司 生产流水线上的线路板功能测试设备
US9632919B2 (en) * 2013-09-30 2017-04-25 Linkedin Corporation Request change tracker

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104185840A (zh) * 2012-04-30 2014-12-03 惠普发展公司，有限责任合伙企业 持续部署流水线测试的优先化
CN104298588A (zh) * 2013-07-16 2015-01-21 阿里巴巴集团控股有限公司 一种持续集成的实现方法及装置
CN104778032A (zh) * 2014-01-09 2015-07-15 阿尔卡特朗讯 一种用于进行持续集成的方法和设备
US20170010889A1 (en) * 2014-01-27 2017-01-12 Hewlett Packard Enterprise Development Lp Continuous integration with reusable context aware jobs
CN104407971A (zh) * 2014-11-18 2015-03-11 中国电子科技集团公司第十研究所 自动化测试嵌入式软件的方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10872028B2 (en) 2019-03-01 2020-12-22 Red Hat Israel, Ltd. Methods and systems for identifying duplicate jobs in a continuous integration environment
CN110780885A (zh) * 2019-10-15 2020-02-11 卡斯柯信号有限公司 Cbtc中ats和联锁软件数据自动部署和环境启动装置及方法
CN110780885B (zh) * 2019-10-15 2022-08-23 卡斯柯信号有限公司 Cbtc中ats和联锁软件数据自动部署和环境启动装置及方法
US20230054780A1 (en) * 2021-08-16 2023-02-23 Amadeus S.A.S. Method and device for testing microservice-based computing platforms
US11947435B2 (en) * 2021-08-16 2024-04-02 Amadeus S.A.S. Method and device for testing microservice-based computing platforms

Also Published As

Publication number Publication date
CN108399082A (zh) 2018-08-14
CN108399082B (zh) 2022-11-15

Similar Documents

Publication Publication Date Title
WO2018145559A1 (zh) 持续集成流水线的生成方法和系统
CN106033436B (zh) 一种数据库的合并方法
US8615768B2 (en) Dependency-ordered resource synchronization across multiple environments using change list created based on dependency-ordered graphs of the multiple environments
US6363524B1 (en) System and method for assessing the need for installing software patches in a computer system
US11481440B2 (en) System and method for processing metadata to determine an object sequence
US8677376B2 (en) Expressing equivalency relationships with identity graphs across multiple environments to create change list to be traversed to conform the environments
CA3161753A1 (en) Blockchain-smart-contract debugging and releasing method and system thereof
US11593336B2 (en) Data pipeline branching
CN111158674A (zh) 组件管理方法、系统、设备及存储介质
CN112130891A (zh) 一种数据库持续部署的方法和设备
CN113535225B (zh) 应用软件的环境配置文件处理方法、装置、设备和介质
CN113179329B (zh) 服务发布方法及装置、服务器、存储介质
US20200409669A1 (en) Technique for transforming a standard messaging component to a customized component
CN114020840A (zh) 一种数据处理方法、装置、服务器、存储介质及产品
CN110991983B (zh) 一种任务处理方法、装置、介质和设备
CN106598703A (zh) 集成系统的事务补偿方法和装置
CN113515352B (zh) 分布式事务异库模式反交易调用方法及装置
CN105447012A (zh) 一种用于数据库的写入互斥方法及装置
CN111080250B (zh) 流程回退补偿方法、装置、存储介质及电子设备
CN113806327A (zh) 一种数据库设计方法、装置及相关设备
CN112418796A (zh) 子流程节点激活方法、装置、电子设备及存储介质
CN109726127A (zh) 一种基于单套测试环境的自动扩充方法
CN111930718B (zh) 配置管理数据库的节点调整方法及装置
CN113626652B (zh) 数据处理网络系统、数据处理网络部署系统及其方法
CN116483800A (zh) 数据库信息变更方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18751015

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18751015

Country of ref document: EP

Kind code of ref document: A1