JP2024075116A - Pipeline setting update device, pipeline setting update method, and program - Google Patents

Abstract

To provide a technology for updating pipeline setting in accordance with a dependence relation of a program to be built.SOLUTION: A pipeline setting update device according to an aspect of the present disclosure for updating setting information of pipeline processing in continuous integration, includes: a dependence relation information creation unit configured so as to create dependence relation information representing a dependence relation among respective program modules included in one or more program modules when source codes of the one or more program modules constituting a development object program are registered in a version management system; an execution order determination unit configured so as to determine an execution order in the case of building the one or more program modules in turn by the pipeline processing on the basis of the dependence relation information; and a setting update unit configured so as to update the setting information on the basis of the execution order.SELECTED DRAWING: Figure 2

Description

The present disclosure relates to a pipeline setting update device, a pipeline setting update method, and a program.

One method for developing programs is known as Continuous Integration (CI). Programs that realize CI are called CI tools, and in recent years have come to be widely used in program development. One prior art technique for CI is a technique that efficiently executes automatic execution in CI according to attribute information of tickets that manage details related to defects, etc. (Patent Document 1).

JP 2021-105866 A

CI tools can automatically execute builds and tests, but if the dependencies of the programs to be built change, the pipeline settings, which define the build execution order, must be manually updated each time.

The present disclosure has been made in consideration of the above points, and provides a technology for updating pipeline settings according to the dependencies of the programs to be built.

A pipeline setting update device according to one aspect of the present disclosure is a pipeline setting update device that updates setting information for pipeline processing in continuous integration, and includes a dependency information creation unit configured to create dependency information representing dependencies between each of the program modules included in one or more program modules when source code for the one or more program modules constituting a program to be developed is registered in a version control system, an execution order determination unit configured to determine an execution order when the one or more program modules are built in sequence by the pipeline processing based on the dependency information, and a setting update unit configured to update the setting information based on the execution order.

Technology is provided to update pipeline configurations based on the dependencies of the programs being built.

FIG. 1 illustrates an example of a relationship between module dependencies and a build execution order. 1 is a diagram illustrating an example of an overall configuration of a development support system according to an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of a hardware configuration of a pipeline setting update system according to an embodiment of the present invention. FIG. 11 is a diagram illustrating an example of a functional configuration of a pipeline setting update application according to the present embodiment. FIG. 13 is a diagram illustrating an example of a dependency relationship table. 10 is a flowchart illustrating an example of a process executed by a pipeline setting update application according to the embodiment. FIG. 4 is a diagram illustrating an example of module configuration information. FIG. 13 illustrates an example of updating a pipeline setting file.

One embodiment of the present invention is described below.

<Continuous integration/continuous delivery>
First, an overview of continuous integration (CI) and continuous delivery (CD), which is a development method related to or similar to CI, will be provided.

CI and CD are both program development methods in which the contents of processes (jobs) such as build, test, and deploy are defined as scripts, and the scripts are automatically executed when triggered by registration (commit) to a version control system (VCS) that manages the source code. A series of processes achieved by executing one or more jobs is called a "pipeline" or "pipeline processing." In general, CI refers to a method for automating builds and tests, and CD refers to a method for automating deployment.

The programs that realize CI/CD are called CI tools/CD tools, respectively. These tools execute jobs according to the processing content (scripts) and execution order of those processing defined in the pipeline configuration file. For this reason, users need to define the processing content of the jobs they want to automate and the execution order of those processing in the pipeline configuration file.

In what follows, we will assume that you are developing an application that is made up of multiple programs, and that you will automatically build each program using a CI tool. For this reason, in what follows, each program (including libraries, etc.) that makes up the application you are developing will also be referred to as a "module."

<Relationship between module dependencies and build execution order>
When an application is composed of multiple modules, there are often modules that have dependencies among them. For example, a certain module may refer to the processing results of another module, creating a parent-child relationship between the modules. In such a case, the parent module that refers to the module depends on the child module that refers to the module, and the child module must be built before the parent module is built.

For example, as shown in Figure 1, assume that there are modules A, B, and C, and that module A depends on module B, and module B depends on module C. In this case, it is necessary to execute the build in the order of module C → module B → module A.

At this time, for example, if module D is added as a module on which module B depends, the builds must be executed in the order of module C → module D → module B → module A, or module D → module C → module B → module A. For this reason, when module D is added, the user must add a definition of the build execution content for building module D to the pipeline setting file of the CI tool, and change the build execution order defined in the pipeline setting file.

As described above, when the dependencies of modules that make up the application being developed change as a result of adding, modifying, or deleting those modules, the user must manually update the pipeline setting file, which is a time-consuming process. Therefore, below we will explain a development support system 1 that can automatically update the pipeline setting file in accordance with the dependencies of the modules being built when automatically building a program using a CI tool.

<Example of overall configuration of development support system 1>
An example of the overall configuration of the development support system 1 according to this embodiment is shown in Fig. 2. As shown in Fig. 2, the development support system 1 according to this embodiment includes a pipeline setting update system 10, a continuous integration system 20, a version control system 30, and a developer terminal 40. Here, the pipeline setting update system 10 and the continuous integration system 20, the version control system 30 and the developer terminal 40, and the continuous integration system 20 and the version control system 30 are connected to each other so as to be able to communicate with each other via a communication network such as an in-house network.

When the source code of a module (or a project that manages a group of necessary files including the source code) is registered in the version control system 30, the pipeline setting update system 10 determines a build execution order based on the dependencies of each module that constitutes the application to be developed, and then updates the pipeline setting file 212 of the CI tool 210 (described later) based on this build execution order, etc. After updating the pipeline setting file 212, the pipeline setting update system 10 sends a pipeline execution instruction to the continuous integration system 20 to execute the builds of each module that constitutes the application to be developed in order.

Here, the pipeline setting update system 10 has a pipeline setting update application 110 and a dependency relationship table 120. The pipeline setting update application 110 is a program that determines the build execution order, updates the pipeline setting file 212, issues pipeline execution instructions, etc. The dependency relationship table 120 is table-format data that stores information indicating the dependency relationship between each module that constitutes the application to be developed. The pipeline setting update application 110 and the dependency relationship table 120 will be described in detail later.

When the continuous integration system 20 receives a pipeline execution instruction from the pipeline setting update system 10, the CI tool 210 instructs the build tool 220 to build each module constituting the application to be developed in sequence. Here, the CI tool 210 includes a build execution instruction unit 211 and a pipeline setting file 212, and the build execution instruction unit 211 instructs the build tool 220 to build each module in sequence according to the build execution content and build execution order defined in the pipeline setting file 212. As a result, the build tool 220 builds each module (the source code of the module) in the build execution order, and pipeline processing is realized.

The CI tool 210 may be any known CI tool, such as GitLab, Jenkins, Travis CI, etc. The build tool 220 may be any known build tool, such as Maven, Ant, Gradle, etc.

The version control system 30 includes a repository that manages the source code of a module and its version. When the source code of a module (or its project) is registered in the repository, the version control system 30 sends a registration notification to the pipeline setting update system 10. Note that any known version control system can be used as the version control system 30, and for example, Git, GitHub, etc. can be used.

The developer terminal 40 is a terminal used by a person (e.g., a module developer) who registers the source code of a module (or its project) in the repository of the version control system 30.

Note that the overall configuration of the development support system 1 shown in FIG. 2 is an example, and the overall configuration of the development support system 1 is not limited to this. For example, two or more of the pipeline setting update system 10, the continuous integration system 20, and the version control system 30 may be configured as an integrated system.

<Example of Hardware Configuration of Pipeline Setting Update System 10>
An example of a hardware configuration of the pipeline setting update system 10 according to the present embodiment is shown in Fig. 3. As shown in Fig. 3, the pipeline setting update system 10 according to the present embodiment includes an input device 11, a display device 12, an external I/F 13, a communication I/F 14, a RAM (Random Access Memory) 15, a ROM (Read Only Memory) 16, an auxiliary storage device 17, and a processor 18. Each of these pieces of hardware is connected to each other via a bus 19 so as to be able to communicate with each other.

The input device 11 is, for example, a keyboard, a mouse, a touch panel, a physical button, etc. The display device 12 is, for example, a display, a display panel, etc. Note that the pipeline setting update system 10 may not have at least one of the input device 11 and the display device 12, for example.

The external I/F 13 is an interface with external devices such as a recording medium 13a. Examples of the recording medium 13a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

The communication I/F 14 is an interface for connecting the pipeline setting update system 10 to a communication network. The RAM 15 is a volatile semiconductor memory (storage device) that temporarily stores programs and data. The ROM 16 is a non-volatile semiconductor memory (storage device) that can store programs and data even when the power is turned off. The auxiliary storage device 17 is a non-volatile storage device such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive). The processor 18 is various types of arithmetic devices such as a CPU (Central Processing Unit).

Note that the hardware configuration shown in FIG. 3 is an example, and the hardware configuration of the pipeline setting update system 10 is not limited to this. For example, the pipeline setting update system 10 may have multiple auxiliary storage devices 17 and multiple processors 18, may not have some of the hardware shown in the figure, or may have various hardware other than the hardware shown in the figure.

<Example of Functional Configuration of Pipeline Setting Update Application 110>
As shown in FIG. 4, the pipeline setting update application 110 according to this embodiment can realize, by processing executed by the processor 18 or the like, a registration notification receiving unit 111, a module configuration information acquiring unit 112, a dependency table creating/updating unit 113, a build execution order determining unit 114, a pipeline setting file updating unit 115, and a pipeline execution instructing unit 116.

The registration notification receiving unit 111 receives a registration notification from the version management system 30.

When the registration notification receiving unit 111 receives a registration notification, the module configuration information acquiring unit 112 acquires module configuration information from the source code or project of each module that constitutes the application to be developed. Module configuration information is information that indicates modules on which the module depends (hereinafter, also referred to as dependent modules).

However, for each module that constitutes the application to be developed, multiple versions of source code or projects may be registered in the version control system 30. Therefore, the module configuration information acquisition unit 112 acquires module configuration information for each module that constitutes the application to be developed from the latest version of the source code or project of the module.

When the module configuration information is acquired by the module configuration information acquisition unit 112, the dependency table creation/update unit 113 creates a new dependency table 120 using the module configuration information, and overwrites and updates the existing dependency table 120. However, if there is no existing dependency table 120, the dependency table creation/update unit 113 may simply save the new dependency table 120 as is in a storage area such as the auxiliary storage device 17.

The build execution order determination unit 114 uses the dependency table 120 created and updated by the dependency table creation and update unit 113 to determine the build execution order of each module that constitutes the application to be developed.

When the build execution order is determined by the build execution order determination unit 114, the pipeline setting file update unit 115 updates the pipeline setting file 212 using information required to define the build execution content of each module that constitutes the application to be developed and the build execution order. Here, the information required to define the build execution content of each module refers to the parameters and their values defined in the pipeline setting file 212 as the build execution content.

When the pipeline configuration file 212 is updated by the pipeline configuration file update unit 115, the pipeline execution instruction unit 116 sends a pipeline execution instruction to the continuous integration system 20.

<Dependency Table 120>
As an example, assume that there are modules A, B, C, and D, and these modules are named "module A", "module B", "module C", and "module D", respectively. In this case, Fig. 5 shows a dependency relationship table 120 in the case where module A depends on module B, and module B depends on modules C and D. As shown in Fig. 5, in the dependency relationship table 120, a "module name" indicating the module name of each module constituting the application to be developed is associated with a "dependent module name" indicating the module name of a module on which the module with that module name depends (dependent module).

For example, the module name "moduleA" is associated with the dependent module name "moduleB". This indicates that module A depends on module B.

For example, the module name "module B" is associated with the dependent module names "module C" and "module D." This indicates that module B depends on module C and module D.

In this way, the dependency table 120 stores information that represents the dependencies of each module that constitutes the application being developed.

<Processing Executed by Pipeline Setting Update Application 110>
As an example, the process performed by the pipeline configuration update application 110 under the following conditions will be described with reference to FIG.

-The programming language of the application to be developed is assumed to be Java.

-The build tool 220 is assumed to be Maven.

-The CI tool 210 is assumed to be GitLab.

- Developers create Maven projects for each module, and these Maven projects are registered in the version control system 30.

-As shown in Figure 1, when there are modules A, B, and C, and module A depends on module B, and module B depends on module C, module D is added as a dependent module of module B.

However, the above conditions are only examples, and the process described below is not limited to the above conditions. For example, the programming language is not limited to Java, and any programming language for which a build exists can be targeted. In addition, the build tool 220 is not limited to Maven, and the CI tool 210 is not limited to GitLab.

At this time, it is assumed that a Maven project including the source code of module D is registered in the version control system 30 by a developer's developer terminal 40, and a registration notification is sent to the pipeline setting update system 10.

First, the registration notification receiving unit 111 receives a registration notification from the version control system 30 (step S101).

Next, the module configuration information acquisition unit 112 acquires module configuration information from the Maven project of each module (i.e., module A, module B, module C, and module D) that constitutes the application to be developed (step S102). However, if there are multiple Maven projects for the same module, the module configuration information acquisition unit 112 acquires module configuration information from the latest version of the Maven project.

Here, in addition to the source code of the module, the Maven project contains a file called pom.xml in which the module configuration information of the module is defined. Therefore, the module configuration information acquisition unit 112 can acquire the module configuration information of the module from the pom.xml of the module.

Examples of pom.xml for modules A to D are shown in Figures 7(a) to 7(d), respectively.

As shown in FIG. 7(a), the pom.xml of module A includes dependency information 1100 that defines dependent modules (including libraries) of module A. Therefore, the module configuration information acquisition unit 112 analyzes the dependency information 1100 included in the pom.xml of module A, and acquires the identification information of the dependent module obtained as a result of the analysis (e.g., module name, module ID, etc.) as module configuration information. In the example shown in FIG. 7(a), the module name "moduleB" of the dependent module is defined as the artifact ID in the dependency information 1100, and this module name "moduleB" is acquired as the module configuration information of module A.

Similarly, as shown in FIG. 7(b), the pom.xml of module B includes dependency information 1200 that defines dependent modules (including libraries) of module A. Therefore, the module configuration information acquisition unit 112 analyzes the dependency information 1200 included in the pom.xml of module B, and acquires the identification information of the dependent modules obtained as a result of the analysis as module configuration information. In the example shown in FIG. 7(b), the module names "moduleC" and "moduleD" of the dependent modules are defined as artifact IDs in the dependency information 1200, and these module names "moduleC" and "moduleD" are acquired as the module configuration information of module B.

On the other hand, as shown in Figures 7(c) and (d), the pom.xml of module C and the pom.xml of module D do not contain dependency information. For this reason, for example, information indicating "no dependency" is obtained as the module configuration information of module C, and similarly, information indicating "no dependency" is obtained as the module configuration information of module D. However, in this case, the module configuration information does not have to be obtained.

Next, the dependency table creation/update unit 113 creates a new dependency table 120 using the module configuration information acquired in step S102 above, and overwrites and updates the existing dependency table 120 (step S103). That is, the dependency table creation/update unit 113 creates the dependency table 120 shown in FIG. 5 using the module configuration information of modules A to D, and overwrites and updates the existing dependency table 120.

Next, the build execution order determination unit 114 uses the dependency relationship table 120 created/updated in step S103 above to determine the build execution order of each module that constitutes the application to be developed (step S104). For example, the build execution order determination unit 114 determines the build order for modules that are not dependent on each other in a predetermined order (for example, by module name or module ID), and for modules that are dependent on each other, determines the build order so that the dependent module comes first and the module that depends on the dependent module comes later.

For example, in the dependency relationship table 120 shown in FIG. 5, the build order of module B comes before the build order of module A. Furthermore, the build order of modules C and D both come before the build order of module B. On the other hand, since modules C and D have no dependency relationship with each other, the build order is determined in a predetermined order (for example, in the order of module names), and the build order of module C comes before the build order of module D. Therefore, in the dependency relationship table 120 shown in FIG. 5, the build order is determined as follows: module C → module D → module B → module A.

Next, the pipeline setting file update unit 115 updates the pipeline setting file 212 using the information required to define the build execution content of each module that constitutes the application to be developed and the build order determined in step S104 above (step S105).

Figure 8 shows an example of the pipeline setting file 212 before the update in step S105 above and an example of the pipeline setting file 212 after the update. As shown in Figure 8, the pipeline setting file 212 includes a build execution order definition section 310 and a build execution content definition section 320.

In the build execution content definition section 320 of the pipeline configuration file 212 before the update, build execution content 320A for module A, build execution content 320B for module B, and build execution content 320C for module C are defined. In addition, in the build execution order definition section 310 of the pipeline configuration file 212 before the update, the stage name "buildC" of the job (build) defined in build execution content 320C, the stage name "buildB" of the job (build) defined in build execution content 320B, and the stage name "buildA" of the job (build) defined in build execution content 320A are defined in that order from top to bottom. This indicates that the builds are executed in the order of module C → module B → module A.

At this time, the pipeline setting file update unit 115 updates the build execution content definition unit 320 using information required to define the build execution content of each module constituting the application to be developed, and updates the build execution order definition unit 310 using the build order determined in step S104 above. Specifically, the pipeline setting file update unit 115 adds the build execution content 320D to the build execution content definition unit 320 using information required to define the build execution content of module D, and adds the stage name "buildD" of the job (build) defined in the build execution content 320D after "buildC" using the build order "module C → module D → module B → module A" determined in step S104 above. This results in an updated pipeline setting file 212, which makes it possible to execute builds in the order of "module C → module D → module B → module A".

Some of the parameters and their values included in the information required to define the build execution content of each module that constitutes the application to be developed are predetermined, while other parameters and their values can be obtained from the Maven project of the module. For example, in the example shown in Figure 8, the value of the parameter "script" is predetermined. On the other hand, the values of the parameters "image", "artifacts", and "stage", for example, can be obtained from the Maven project.

Then, the pipeline execution instruction unit 116 sends a pipeline execution instruction to the continuous integration system 20 (step S106). As a result, in the continuous integration system 20, the build execution instruction unit 211 issues a build instruction to the build tool 220 for the build execution contents defined in the build execution content definition unit 320 according to the build execution order defined in the build execution order definition unit 310 of the pipeline configuration file 212, and the build tool 220 builds the module (source code).

<Summary>
As described above, in the development support system 1 according to this embodiment, when building modules constituting an application to be developed, the pipeline setting file 212 of the CI tool 210 can be updated in accordance with the dependencies of those modules, and the build execution order can be dynamically changed. Therefore, even if the dependencies of the modules constituting the application to be developed change, the user does not need to manually update the pipeline setting file 212 each time, thereby reducing the effort required.

In the above embodiment, we have described a case where dependencies change due to the addition of modules that make up the application to be developed, but this is not limited to this, and the same can be applied to a case where dependencies change due to the modification or deletion of modules.

In addition, in the above embodiment, a case has been described in which a pipeline setting file 212 already exists and is updated, but the present invention can also be applied to a case in which, for example, a pipeline setting file 212 does not exist and a new one is created.

Furthermore, in the above embodiment, when source code or a project is registered in the version control system 30, a registration notification is sent to the pipeline setting update system 10, but this is not limited to the above. For example, the pipeline setting update system 10 may periodically poll the version control system 30 to check whether new source code or a project has been registered.

The present invention is not limited to the specifically disclosed embodiments above, and various modifications, changes, and combinations with known technologies are possible without departing from the scope of the claims.

REFERENCE SIGNS LIST 1 Development support system 10 Pipeline setting update system 11 Input device 12 Display device 13 External I/F
13a Recording medium 14 Communication I/F
15 RAM
16 ROM
17 Auxiliary storage device 18 Processor 19 Bus 20 Continuous integration system 30 Version control system 40 Developer terminal 110 Pipeline setting update application 111 Registration notification receiving unit 112 Module configuration information acquisition unit 113 Dependency table creation/update unit 114 Build execution order determination unit 115 Pipeline setting file update unit 116 Pipeline execution instruction unit 120 Dependency table 210 CI tool 211 Build execution instruction unit 212 Pipeline setting file 220 Build tool

Claims (7)

A pipeline setting update device that updates setting information of a pipeline process in continuous integration, comprising:
a dependency information creation unit configured to create dependency information representing dependencies between each of the program modules included in one or more program modules when source code of the one or more program modules constituting a development target program is registered in a version control system;
an execution order determination unit configured to determine an execution order when the one or more program modules are built in sequence by the pipeline processing based on the dependency information;
A setting update unit configured to update the setting information based on the execution order;
A pipeline setting update device having: an acquisition unit configured to acquire, when source code of one or more program modules constituting the development target program is registered in a version control system, configuration information representing identification information of other program modules on which the program module depends, for each program module included in the one or more program modules;
The dependency information creation unit
2. The pipeline setting update device according to claim 1, configured to create the dependency information based on configuration information of each program module included in the one or more program modules. The acquisition unit is
3. The pipeline setting update device according to claim 2, configured to acquire, for each program module included in the one or more program modules, the configuration information from a project created for each source code of the program module. The execution order determination unit is
4. The pipeline setting update device according to claim 2 or 3, configured to determine the execution order in a predetermined order for program modules that are not dependent on each other based on the dependency information, and to determine the execution order for program modules that are dependent on each other such that another program module on which the program module depends is executed before the program module. The setting update unit is
The pipeline setting update device according to claim 4 , configured to update information included in the setting information, which indicates a build execution order of the one or more program modules in the pipeline processing, with the execution order. A pipeline setting update method for updating setting information of a pipeline process in continuous integration, comprising:
a dependency information creation step of creating dependency information representing dependencies between each of the program modules included in one or more program modules when source code of the one or more program modules constituting a program to be developed is registered in a version control system;
an execution order determination step for determining an execution order when the one or more program modules are built in sequence by the pipeline processing based on the dependency information;
a setting update procedure for updating the setting information based on the execution order;
The computer runs a pipeline set up to update the method. A program for updating configuration information of a pipeline process in continuous integration,
a dependency information creation step of creating dependency information representing dependencies between each of the program modules included in one or more program modules when source code of the one or more program modules constituting a program to be developed is registered in a version control system;
an execution order determination step for determining an execution order when the one or more program modules are built in sequence by the pipeline processing based on the dependency information;
a setting update procedure for updating the setting information based on the execution order;
A program that causes a computer to execute the following.

Images