WO2022093178A1 - Ci/cd pipeline code recommendations - Google Patents

Ci/cd pipeline code recommendations Download PDF

Info

Publication number
WO2022093178A1
WO2022093178A1 PCT/US2020/057387 US2020057387W WO2022093178A1 WO 2022093178 A1 WO2022093178 A1 WO 2022093178A1 US 2020057387 W US2020057387 W US 2020057387W WO 2022093178 A1 WO2022093178 A1 WO 2022093178A1
Authority
WO
WIPO (PCT)
Prior art keywords
steps
pipeline code
completed
partially
code
Prior art date
Application number
PCT/US2020/057387
Other languages
French (fr)
Inventor
Jhonny Marcos ACORDI MERTZ
Mauricio COUTINHO MORAES
Nailson Boaz COSTA LEITE
Original Assignee
Hewlett-Packard Development Company, L.P.
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 Hewlett-Packard Development Company, L.P. filed Critical Hewlett-Packard Development Company, L.P.
Priority to PCT/US2020/057387 priority Critical patent/WO2022093178A1/en
Publication of WO2022093178A1 publication Critical patent/WO2022093178A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/36Software reuse

Definitions

  • Computing devices rely on program code to execute applications and perform any variety of operations.
  • a programmer may desire to create a budgeting application or program. To do so, the programmer writes computer readable code to instruct the hardware resources of the computing device how to operate to carry out the intended function.
  • FIG. 1 is a block diagram of a system for recommending continuous integration/continuous deployment (CI/CD) pipeline code, according to an example of the principles described herein.
  • CI/CD continuous integration/continuous deployment
  • FIG. 2 is a flowchart of a method for recommending CI/CD pipeline code, according to an example of the principles described herein.
  • FIG. 3 is a flowchart of a method for recommending CI/CD pipeline code, according to an example of the principles described herein.
  • Figs. 4A and 4B depict a partially-completed CI/CD pipeline code and completed pipeline code files from which recommendations are drawn, according to an example of the principles described herein.
  • Fig. 5 depicts a non-transitory machine-readable storage medium for recommending CI/CD pipeline code, according to an example of the principles described herein.
  • programmers may develop applications to execute any number of operations. These applications are created using program code, which is a language that is recognizable by computer processors to carry out certain functions.
  • program code is tested and verified. For example, program code may be tested by providing inputs to the program code and observing how the program code behaves. For example, for each input into the program code, a system test may determine whether the program code produces an expected output.
  • DevOps refers to the process of coordinating program code development and operations with the intent to reduce the risk of change and increase the speed of application development and deployment.
  • an entity may employ a continuous integration/continuous deployment (CI/CD) pipeline which automates the processes of validating, building, testing, and deploying the program code.
  • CI/CD continuous integration/continuous deployment
  • a CI/CD pipeline allows developers to deliver applications to customers by introducing automation into the stages of application development.
  • the main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment.
  • CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of an application, from integration and testing phases to delivery and deployment. Taken together, these connected practices may be referred to as a CI/CD pipeline. That is, the CI/CD pipeline employs automated processes related to code quality instead of relying on manual performance of such operations.
  • Continuous deployment or continuous delivery refers to a practice that allows for frequent releases of application updates by maintaining the application in a deployable state. Continuous deployment, by automating deployment operations, reduces the load on operations personnel to perform manual deployment operations.
  • CI/CD pipelines may simplify and increase the efficacy of application development and release, certain enhancements may further increase their efficacy and reliability. That is, even with the automated processes executed along a CI/CD pipeline, it is still a laborious process to generate the code that executes the CI/CD pipeline. For example, a user may generate the code from scratch that compiles, executes, tests, and deploys the application program code. Were such steps carried out each time a new CI/CD pipeline was generated, the development timeline for an application may become prohibitively long.
  • the present specification describes a system, method, and machine-readable storage medium that suggests CI/CD code to be reused based on some amount of already completed CI/CD pipeline code.
  • a system suggests ranked CI/CD components to be reused by looking for similarities in source code present in a CI/CD template database that is collaboratively built by many different teams.
  • Recommendations may be ranked based on unique features of CI/CD pipeline code such as the definitions of step and jobs, as well as their proximity and frequency, the output of step executions, and metadata related to the steps of the completed pipeline code files.
  • recommendations are provided after every interaction with a programmer developing a particular CI/CD pipeline code.
  • the present specification describes a repository that includes pipeline code files for many projects.
  • the present system leverages the previous work done to find recommendations for a new project.
  • a developer may have a build job with particular steps and a test job with particular steps.
  • the developer may not have yet developed a deployment job of the CI/CD pipeline and may not even know what type of deployment steps should be implemented.
  • the system may identify other pipeline code files with similar build and test jobs. From those other pipeline code files with similar build and test jobs, the system may identify a deployment job from those other pipeline code files and recommend it to the user of the partially-completed pipeline code.
  • this process may be iterative. For example, a user may perform a keyword search for “java” as the developer may be generating a CI/CD pipeline to test/validate/deploy a java application. Certain suggestions for “java” may be presented and the developer may start generating a java build job. The characteristics of the java build job serve as additional input from which the system can identify completed pipeline code files with similar java build job characteristics to suggest java test jobs. That is, as the partially-completed java CI/CD pipeline code includes a java build job, the system may identify, from completed java CI/CD pipeline code files that a java test is generally used alongside a java build job and so suggests a particular java test job with its associated steps.
  • a developer may desire to generate CI/CD pipeline code that 1 ) builds a java project using a particular java build automation tool, 2) deploys the project as a web application using a particular deploy tool, 3) performs functional tests, and 4) reports resulting test code coverage.
  • a developer may perform queries using keywords of “java,” the particular java build automation tool, the particular deploy tool, “functional tests," and "code coverage" and their variations.
  • the output of such a search may be all files containing those keywords, which would potentially cause a developer to manually sift through the results to filter out irrelevant search results. Accordingly, the present specification provides more meaningful code suggestions based on a ranking of similarities between existing code and their actual project specifications.
  • the present specification describes a system.
  • the system includes a repository to store continuous integration/continuous development (CI/CD) pipeline code files, each pipeline code file to validate an application.
  • the system also includes a non-transitory machine-readable storage medium to store instructions and a processor to execute the instructions.
  • the instructions to cause the processor to 1 compare steps of a partially-completed pipeline code with steps of completed pipeline code files located in the repository and 2) recommend, from completed pipeline code files with similar steps as the partially-completed pipeline code file related steps for inclusion into the partially-completed source code.
  • the present specification also describes a method.
  • steps of a partially-completed continuous integration/continuous deployment (CI/CD) pipeline code are compared with steps of completed pipeline code files located in a repository to identify similarities therebetween.
  • the steps may be grouped together as jobs.
  • related steps are identified from the completed pipeline code files. The related steps are recommended for inclusion in the partially-completed source code.
  • the present specification also describes a non-transitory machine- readable storage medium encoded with instructions executable by a processor.
  • the machine-readable storage medium includes instructions to, when executed by the processor cause the processor to receive as input, a partially-completed continuous integration/continuous deployment (CI/CD) pipeline code, which partially-completed pipeline code includes a number of steps.
  • the instructions also, when executed by the processor, cause the processor to identify, from a repository of completed pipeline code files, completed pipeline code files having similar steps as the partially-completed pipeline code and recommend related steps from the completed pipeline code files. The recommendation is based on a similarity between the steps of the completed pipeline code files and the steps of the partially-completed pipeline code and a co-occurrence between the related steps and the steps of the completed pipeline code files.
  • using such a system, method, and machine-readable storage medium may, for example, 1 ) leverages previously used CI/CD pipeline code to complete CI/CD pipelines under development; 2) reduces duplication in different repositories; 3) provides visibility of the code used in various CI/CD pipelines; and 4) promotes collaborative use of CI/CD code.
  • the devices disclosed herein may address other matters and deficiencies in a number of technical areas, for example.
  • Fig. 1 is a block diagram of a system (100) for recommending continuous integration/continuous deployment (CI/CD) pipeline code, according to an example of the principles described herein.
  • CI/CD pipeline code files include the program code that executes the automated processes carried out on an application. That is, throughout its life, an application is subject to different stages such as quality assurance, development, staging, and production. Each of these stages are executed via program code that is compiled in a CI/CD pipeline code file.
  • the system (100) includes a repository (102) to store the CI/CD pipeline code files.
  • Each pipeline code file may correspond to a different CI/CD pipeline.
  • each CI/CD pipeline may include a hierarchical structure.
  • the CI/CD pipeline may be made up of stages, with each stage being made up of jobs, and each job being made up of steps.
  • stages represent the highest level (e.g., development, quality assurance, staging, production, etc.)
  • jobs represent an intermediate level (e.g., build, deploy, test, etc.)
  • steps represent the lowest level (e.g., download a tool, run a tool, verify results, etc.).
  • the pipeline code files may include tags, or other distinguishing metadata, for each of the stages, jobs, and steps that make up the CI/CD pipeline code files.
  • different CI/CD pipelines may be developed to automate different tasks.
  • different CI/CD pipelines may include different stages with the different stages potentially having different jobs found therein. Even if different CI/CD pipelines include the same stages, each stage may be different in that different jobs and steps are used in a particular stage.
  • two CI/CD pipelines may include a testing stage. However, the steps of each testing stage may be different between the different CI/CD pipelines.
  • a quality assurance stage and a production stage may each include a build job and a deploy job. However, the quality assurance stage may have a test job that the production stage does not.
  • the system (100) also includes a non-transitory machine-readable storage medium (104) to store CI/CD code instructions (105).
  • the system (100) also includes a processor (106) to execute the CI/CD code instructions (105).
  • the non-transitory machine-readable storage medium (104) is communicatively coupled to the processor (106).
  • the non-transitory machine-readable storage medium (104) may be an electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions.
  • the non-transitory machine- readable storage medium (104) may be, for example, Random-Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, etc.
  • the CI/CD code instructions (105) cause the processor (106) to execute certain operations. Specifically, the CI/CD code instructions (105) cause the processor (106) to receive an update to application files. That is, as described above, programmers may submit updates to application program code to the system (100) for automated building, testing, and deployment. The processor (106) receives these update files and executes the automated processes. That is, reception of the updates calls an associated pipeline code file to verify (build, test, and deploy) the application code with the update incorporated. [0030] The processor (106) may also compare steps of a partially-completed pipeline code with steps of completed pipeline code files located in the repository (102). As described above, pipeline code may have a hierarchical structure.
  • the pipeline code may be divided into stages, with each stage being made up of jobs, and each job being made up of steps.
  • the present specification describes the comparison of steps of a partially-completed pipeline code with the steps of completed pipeline code files in the repository (102).
  • a user may be developing a CI/CD pipeline that includes a test job and a deploy job.
  • the processor (106) may scan the repository (102) for completed CI/CD pipeline code files that include test jobs and deploy jobs of the same nature. That is, each job in a CI/CD pipeline code may have steps that are made of up tasks.
  • the processor (102) may identify completed pipeline code files that include similar steps which have similar tasks as the steps and tasks in a partially-completed CI/CD pipeline code.
  • Completed pipeline code files that include similar steps and/or tasks as a partially-completed pipeline code may serve as a source of recommendations to the developer of the partially-completed pipeline code. That is, as the developer is generating the pipeline code, the system (100) may identify similar features between the current pipeline code and completed pipeline code files. As they have similar features, the current pipeline code may benefit from including other features from the completed pipeline code file that have not yet been included in the current pipeline code. That is, the developer may leverage work done on a previous and similar CI/CD pipeline to add components that may increase the quality and efficacy of their pipeline code currently being worked on.
  • steps of a pipeline code are made up of tasks that are carried out during the automation process.
  • Steps may be a set of properties (i.e. , keys associated with respective values), and may include programming and configuration information.
  • steps may be stored in a document-oriented database and may be readily searched. For example, a step that involves the installation of a build automation tool may be retrieved with a query for a particular build automation tool. This same step may be retrieved with the query for “displayName:” followed by the particular build automation tool. This query would search the field “displayName” for the particular build automation tool.
  • step definitions may be clustered using nonsupervised learning that includes information retrieval approaches that use semantic information from the source code.
  • non-supervised learning may make use of both the keys and the values that make up the properties of a step definition, plus any programming logic and configuration present in it.
  • the processor (106) may compare the similarity of two or more whole steps and rank them accordingly. For example, a first step of: template: steps/_secure-file-download-v0.yaml parameters: filename: “settingsFile” secureFileName: ‘settings.
  • xml’ may be deemed more similar to a second step of: template: steps/_secure-file-download-v0.yaml parameters: filename: “settingsSecurityFile” secureFileName: ‘settings-security.xml’ as compared to a similarity of this second step to a third step of: task: FileTransform@2 inputs: folderPath: ‘$(Build.SourcesDirectory) ‘ xmlTransformationRules: jsonTargetFiles: ‘./conf/templates/$(environment).json’ [0034] Accordingly, as demonstrated above, steps of a CI/CD pipeline code are structured such that they may be readily compared to one another to determine similarity.
  • the CI/CD code instructions (105) in the non-transitory machine- readable storage medium (104) also cause the processor (106) to recommend steps from the completed pipeline code files to be included in the partially- completed pipeline code. That is, once a similarity is determined, additional steps from the completed pipeline code file are recommended for inclusion into the partially-completed pipeline code.
  • Such a recommendation includes the tasks that make up the step. That is, steps include a number of tasks and a recommended related step includes a recommendation of the tasks that make up the related step.
  • a recommendation may not be to just append a particular step to the pipeline source code in progress, but a recommendation of a specific step that has particular tasks deemed relevant to the partially completed pipeline code.
  • a pipeline code in progress may include a java build test and a java test step, each having particular tasks.
  • the recommendation may be based not only on an identification of completed pipeline code files containing these particular java build and java test steps, but that also include the particular tasks within each step.
  • the comparison is between the partially-completed pipeline code and multiple completed pipeline code files. That is, the processor (106) may identify multiple completed pipeline code files that have similar steps to those already entered in the partially-completed pipeline code.
  • the recommended related steps may be based on an aggregate of the multiple completed pipeline code files associated with the identified similarity.
  • Figs. 4A and 4B provide an example where a recommendation is based on multiple completed pipeline code files.
  • the steps of the pipeline code files are grouped as jobs. That is, jobs are composed of steps and may also have properties of their own. Accordingly, as semi-structured text, they may be compared similar to the operations described above regarding step comparison.
  • the comparing of the steps is performed at a job level. That is, jobs of a partially- completed pipeline code are compared with jobs of one or multiple completed pipeline code files in the repository (102).
  • a recommendation may be for a related job and the steps that are included therein. For example, a deploy job with particular steps may be recommended when particular build and test jobs are identified both in a partially-completed pipeline code and a similar completed pipeline code file.
  • the system (100) provides for the recommendation of particular CI/CD code content based on a comparison of unique features of CI/CD code, i.e. , jobs and steps, to identify similar content between a pipeline code in progress and completed pipeline code. Additional jobs and/or steps in the completed pipeline code are suggested for inclusion in the pipeline code in progress as the similarity may suggest that the additional jobs and/or steps would be desirable in the pipeline code in progress.
  • Fig. 2 is a flowchart of a method (200) for recommending CI/CD pipeline code, according to an example of the principles described herein.
  • each pipeline code file may include a hierarchical structure of stages, jobs, and steps.
  • the pipeline code file may include stages, where a stage is made up of a number of jobs.
  • each job may include a number of steps.
  • the method (200) includes comparing (block 201 ) steps of a partially- completed CI/CD pipeline code with steps of completed pipeline code files located in the repository (Fig. 1 , 102). Such a comparison (block 201 ) identifies similarities between the partially-completed pipeline code and the completed pipeline code files.
  • a variety of operations may be carried out.
  • a semi-structured text analysis of the pipeline code files may be performed. That is, the pipeline code may be semi-structured text meaning that it has certain consistent characteristics, but also has other features that are not consistent.
  • the pipeline code files include certain attributes such as stages, jobs, and steps, that may have consistent nomenclature. By comparison, the values associated with these attributes may vary.
  • the processor (Fig. 1 , 106) may carry out semi-structured text searching to identify similar pipeline code between a partially-completed pipeline code and completed pipeline code files.
  • the comparison (block 201 ) may also include performing a graph model similarity analysis of the pipeline code files. That is, each pipeline code file may be represented as a graph representation of the hierarchy. For example, stages of the CI/CD pipeline may be represented at one hierarchical level as stage nodes and the jobs that make up that stage may be represented as child nodes to the stage node. Similarly, the steps that make up a job may be represented as child nodes to a job node. Accordingly, the graphical model analysis may identify those code sections that are similar to different pipeline code files. Accordingly, as described above, the comparison (block 201 ) of the number of pipeline code includes a semistructured text analysis and a graph model analysis of the pipeline code to identify similarities.
  • the processor (Fig. 1 , 106) may then identify (block 202) related steps from the completed pipeline code files. This identification may be based on the similarity of steps between the partially-completed pipeline code and the completed pipeline code files. That is, once completed pipeline code files are determined to be similar to the partially-completed pipeline code based on similar steps and/or jobs, the processor (Fig. 1 , 106) may scan the completed pipeline code files for content that may be of use to the partially-completed pipeline code.
  • the partially-completed pipeline code may include a java build job and a java test job. From completed pipeline code files with java build jobs and java test jobs, the processor (Fig. 1 , 106) may determine that a java deploy job, with particular steps, is frequently found in these completed pipeline code files. Accordingly, the processor (Fig. 1 , 106) recommends (block 203) the related steps for inclusion in the partially-completed pipeline code.
  • the recommendation may be based on additional criteria.
  • the recommendation may be based on metadata associated with the related steps, which metadata may include an author of the related step, a quantity of use of the related step, and/or a timestamp of the uses of the related step.
  • metadata may include an author of the related step, a quantity of use of the related step, and/or a timestamp of the uses of the related step.
  • the metadata with a first related step may indicate that it is used more and has been used more recently than a second related step.
  • the recommendation may be to use the first related step as opposed to the second related step.
  • this additional metadata provides information such as who wrote an available piece of code to be reused and how many executions the same piece of code had in a predetermined time period. Such information may be relevant to determining which related steps would be most beneficial and practical for the developer to implement.
  • the method (200) may be performed cyclically as a developer is generating a CI/CD pipeline code.
  • the developer may give some information about the code, for example inputting the word “java” into a search query.
  • the system may provide a variety of steps and/or jobs with the java definition.
  • the recommendations may be quite broad. After inputting recommended code or other code, more input is available to the system (Fig. 1 , 100) for providing customized and tailored recommendations.
  • a developer may input a search query of the word “java.” Responsive to this input, the system (Fig. 1 , 100) may output a number of steps and/or jobs that relate to the word “java” anywhere in their definitions.
  • the output may be another recommendation of steps and jobs that are based on a comparison of the input additional steps and jobs with steps and jobs from the repository (Fig. 1 , 102).
  • a third interaction additional inputs to the pipeline code are suggested and the system (Fig. 1 , 100) considers all inputs, from the first, second, and third interactions, to recommend even more tailored content based on all the information previously provided.
  • This is a pattern that may continue throughout the generation of the CI/CD pipeline code.
  • the operations in the method (200), that is the comparing (block 201 ), identifying (block 202), recommending (block 203) may be performed in real-time as the partially-completed pipeline code is being generated.
  • Fig. 3 is a flowchart of a method (300) for recommending CI/CD pipeline code, according to an example of the principles described herein.
  • the method (300) may include comparing (block 301 ) partially-completed pipeline code with completed pipeline code files in a repository (Fig. 1 , 102) and identifying (block 302) related steps from the completed pipeline code files. These operations may be performed as described above in connection with Fig. 2.
  • comparing (block 301) partially-completed pipeline code may include analyzing an output of an execution of the step. The output of a particular step may be used to determine whether or not a step of a completed pipeline code file is similar to a partially-completed pipeline code.
  • the related steps may be ranked (block 304) based on a relatedness of the similar content. That is, if the partially-completed pipeline code is more similar to a first completed pipeline code file than to second completed pipeline code file, then the related items originating from the first completed pipeline code file may be ranked (block 304) higher.
  • the ranking (block 304) may be based on a cooccurrence of the related steps and steps from the completed pipeline code files deemed similar to the partially-completed pipeline code. That is, the proximity of jobs and steps and the frequency of such proximity may be considered in the recommendation (block 303). For example, jobs and steps are not isolated and therefore have jobs and steps that come before and after them. Such proximity, as well as the frequency of such proximity may be useful for developers looking for reusing CI/CD pipeline code. For example, a deployment job or step that is followed by a job or step of functional testing may be deemed more relevant than a deployment job or step that is not followed by functional testing.
  • the processor (Fig. 1 , 106) may execute association rule learning for discovering co-occurrence in databases.
  • Association rules may be created by searching data for frequent if-then patterns and using the criteria support and confidence to identify potentially relevant relationships.
  • the processor may determine a support, which refers to an indication of how frequently the items appear in the data.
  • the processor may also determine confidence which indicates the number of times the if-then statements are found true.
  • Figs. 4A and 4B provide a specific example of different related steps being ranked differently.
  • the recommended related steps may be visually appended (block 305) to the partially-completed pipeline code. That is, the developer may generate the pipeline code in a user interface with script displayed.
  • the processor Fig. 1 , 106 may visually append (block 305) the recommended content where it would be inserted were it to be accepted.
  • the recommendation may have a visual distinction, for example by being a different color than entered pipeline code.
  • the user may choose to accept, reject, or alter the recommended steps.
  • Figs. 4A and 4B depict a partially-completed CI/CD pipeline code (408) and sections of completed pipeline code files (410) from which recommendations are drawn, according to an example of the principles described herein.
  • a developer may start generation of a new CI/CD pipeline code (408) which may include certain steps such as a java_build step and a unit_test step. Based on a semi-structured analysis of this partially-completed pipeline code (408), the processor (Fig. 1 , 106) may identify three completed pipeline code files (410-1 , 410-2, 410-3) with related steps.
  • a first completed pipeline code file includes the steps java_build, unit_test, check_code_coverage, functional_test, publish_test_results
  • a second completed pipeline code file includes the steps java_build, functional_test, publish_test_results
  • a third completed pipeline code file includes the steps java_build, functional_test, publish_test_results.
  • the processor (Fig. 1 , 106) may determine various characteristics of similarity.
  • the processor may determine that when pipeline code includes a step for java_build there are also steps of functional_test and publish_test_results as indicated in each of the completed pipeline code files (410-1 , 410-2, 410-3).
  • the processor may also determine that when pipeline code includes a unit_test step, there is likely to be a check_code_coverage step as indicated in the second completed pipeline code file (410-2). Accordingly, in this example, the processor (Fig. 1 , 106) may recommend a functional_test, publish_test_results, and check_code_coverage steps for inclusion into the partially-completed pipeline code (408).
  • Fig. 5 depicts a non-transitory machine-readable storage medium (104) for recommending CI/CD pipeline code, according to an example of the principles described herein.
  • the system (Fig. 1 , 100) includes various hardware components. Specifically, the system (Fig. 1 , 100) includes a processor (Fig. 1 , 106) and a machine-readable storage medium
  • the machine-readable storage medium (104) is communicatively coupled to the processor.
  • the machine-readable storage medium (104) includes a number of instructions (512, 514, 516) for performing a designated function.
  • the instructions may be machine code and/or script code.
  • the machine-readable storage medium (104) causes the processor to execute the designated function of the instructions (512, 514, 516).
  • the machine- readable storage medium (104) can store data, programs, instructions, or any other machine-readable data that can be utilized to operate the system (Fig. 1 , 100).
  • Machine-readable storage medium (104) can store machine readable instructions that the processor of the system (Fig. 1 , 100) can process, or execute.
  • the machine-readable storage medium (104) can be an electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions.
  • Machine-readable storage medium (104) may be, for example, Random-Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, etc.
  • RAM Random-Access Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • the machine-readable storage medium (104) may be a non-transitory machine-readable storage medium (104).
  • using such a system, method, and machine-readable storage medium may, for example, 1 ) leverages previously used CI/CD pipeline code to complete CI/CD pipelines under development; 2) reduces duplication in different repositories; 3) provides visibility of the code used in various CI/CD pipelines; and 4) promotes collaborative use of CI/CD code.
  • the devices disclosed herein may address other matters and deficiencies in a number of technical areas, for example.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

In an example in accordance with the present disclosure, a system is described. The system includes a repository to store continuous integration/continuous development (Cl/CD) pipeline code files, each pipeline code file to validate an application. The system also includes a non-transitory machine- readable storage medium to store instructions and a processor to execute the instructions. The instructions to cause the processor to compare steps of a partially-completed pipeline code with steps of completed pipeline code files located in the repository. The instructions also cause the processor to recommend, from completed pipeline code files with similar steps as the partially-completed pipeline code, related steps for inclusion into the partially-completed pipeline code.

Description

CI/CD PIPELINE CODE RECOMMENDATIONS
BACKGROUND
[0001] Computing devices rely on program code to execute applications and perform any variety of operations. For example, a programmer may desire to create a budgeting application or program. To do so, the programmer writes computer readable code to instruct the hardware resources of the computing device how to operate to carry out the intended function.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] The accompanying drawings illustrate various examples of the principles described herein and are part of the specification. The illustrated examples are given merely for illustration, and do not limit the scope of the claims.
[0003] Fig. 1 is a block diagram of a system for recommending continuous integration/continuous deployment (CI/CD) pipeline code, according to an example of the principles described herein.
[0004] Fig. 2 is a flowchart of a method for recommending CI/CD pipeline code, according to an example of the principles described herein.
[0005] Fig. 3 is a flowchart of a method for recommending CI/CD pipeline code, according to an example of the principles described herein.
[0006] Figs. 4A and 4B depict a partially-completed CI/CD pipeline code and completed pipeline code files from which recommendations are drawn, according to an example of the principles described herein. [0007] Fig. 5 depicts a non-transitory machine-readable storage medium for recommending CI/CD pipeline code, according to an example of the principles described herein.
[0008] Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the example shown. Moreover, the drawings provide examples and/or implementations consistent with the description; however, the description is not limited to the examples and/or implementations provided in the drawings.
DETAILED DESCRIPTION
[0009] As described above, programmers may develop applications to execute any number of operations. These applications are created using program code, which is a language that is recognizable by computer processors to carry out certain functions. In general, before release to the public, program code is tested and verified. For example, program code may be tested by providing inputs to the program code and observing how the program code behaves. For example, for each input into the program code, a system test may determine whether the program code produces an expected output.
[0010] When performed manually, such a process may be long and complex and may involve coordination between a plurality of different systems and devices to keep track of modifications made to the program code.
[0011] DevOps refers to the process of coordinating program code development and operations with the intent to reduce the risk of change and increase the speed of application development and deployment. To expedite the development and deployment of application program code, an entity may employ a continuous integration/continuous deployment (CI/CD) pipeline which automates the processes of validating, building, testing, and deploying the program code. [0012] A CI/CD pipeline allows developers to deliver applications to customers by introducing automation into the stages of application development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. Specifically, CI/CD introduces ongoing automation and continuous monitoring throughout the lifecycle of an application, from integration and testing phases to delivery and deployment. Taken together, these connected practices may be referred to as a CI/CD pipeline. That is, the CI/CD pipeline employs automated processes related to code quality instead of relying on manual performance of such operations.
[0013] During development of program code, it may be that the code is changed, sometimes by different programmers working on different aspects of the code. If not coordinated, one programmer’s contributions may conflict with another programmer’s efforts, such that bugs may result. Continuous integration involves programmers integrating, checking-in, or merging their work to a shared repository for an application. Each code update may be verified by a rebuild of the application with the changes included. Automated tests are performed to ensure the source file operates correctly with the addition of the update. Successful integration ensures that new code changes to an application are built, tested, and merged to a shared repository. Doing so prevents having too many updates to an application in development at the same time, which updates may conflict with one another.
[0014] Continuous deployment or continuous delivery refers to a practice that allows for frequent releases of application updates by maintaining the application in a deployable state. Continuous deployment, by automating deployment operations, reduces the load on operations personnel to perform manual deployment operations.
[0015] Particular examples of processes that may be automated include compiling search files and packaging the search files into another format such as a .zip file. Another step may be to deploy this generated file into a runtime structure where it can receive and respond to HTTP requests. Yet another operation may be to run automated tests. [0016] While such CI/CD pipelines may simplify and increase the efficacy of application development and release, certain enhancements may further increase their efficacy and reliability. That is, even with the automated processes executed along a CI/CD pipeline, it is still a laborious process to generate the code that executes the CI/CD pipeline. For example, a user may generate the code from scratch that compiles, executes, tests, and deploys the application program code. Were such steps carried out each time a new CI/CD pipeline was generated, the development timeline for an application may become prohibitively long.
[0017] Accordingly, the present specification describes a system, method, and machine-readable storage medium that suggests CI/CD code to be reused based on some amount of already completed CI/CD pipeline code. Specifically, a system suggests ranked CI/CD components to be reused by looking for similarities in source code present in a CI/CD template database that is collaboratively built by many different teams. Recommendations may be ranked based on unique features of CI/CD pipeline code such as the definitions of step and jobs, as well as their proximity and frequency, the output of step executions, and metadata related to the steps of the completed pipeline code files. In some examples, recommendations are provided after every interaction with a programmer developing a particular CI/CD pipeline code.
[0018] In other words, the present specification describes a repository that includes pipeline code files for many projects. The present system leverages the previous work done to find recommendations for a new project. As an example, suppose a developer is generating a new CI/CD pipeline code. In this example, the developer may have a build job with particular steps and a test job with particular steps. However, the developer may not have yet developed a deployment job of the CI/CD pipeline and may not even know what type of deployment steps should be implemented. Accordingly, based on the steps already included in the pipeline code, the system may identify other pipeline code files with similar build and test jobs. From those other pipeline code files with similar build and test jobs, the system may identify a deployment job from those other pipeline code files and recommend it to the user of the partially-completed pipeline code.
[0019] In some examples, this process may be iterative. For example, a user may perform a keyword search for “java” as the developer may be generating a CI/CD pipeline to test/validate/deploy a java application. Certain suggestions for “java” may be presented and the developer may start generating a java build job. The characteristics of the java build job serve as additional input from which the system can identify completed pipeline code files with similar java build job characteristics to suggest java test jobs. That is, as the partially-completed java CI/CD pipeline code includes a java build job, the system may identify, from completed java CI/CD pipeline code files that a java test is generally used alongside a java build job and so suggests a particular java test job with its associated steps. Responsive to a user accepting the java test job recommendation, additional information is available to the system to provide additional recommendations to complete the java CI/CD pipeline code. Thus, the recommendations of CI/CD code to use become more tailored to a particular project as the developer is providing more and more input for the system to analyze and find appropriate recommendations.
[0020] As another example, a developer may desire to generate CI/CD pipeline code that 1 ) builds a java project using a particular java build automation tool, 2) deploys the project as a web application using a particular deploy tool, 3) performs functional tests, and 4) reports resulting test code coverage. Without the present recommending system, a developer may perform queries using keywords of “java,” the particular java build automation tool, the particular deploy tool, “functional tests," and "code coverage" and their variations. The output of such a search may be all files containing those keywords, which would potentially cause a developer to manually sift through the results to filter out irrelevant search results. Accordingly, the present specification provides more meaningful code suggestions based on a ranking of similarities between existing code and their actual project specifications. [0021] Specifically, the present specification describes a system. The system includes a repository to store continuous integration/continuous development (CI/CD) pipeline code files, each pipeline code file to validate an application. The system also includes a non-transitory machine-readable storage medium to store instructions and a processor to execute the instructions. The instructions to cause the processor to 1 ) compare steps of a partially-completed pipeline code with steps of completed pipeline code files located in the repository and 2) recommend, from completed pipeline code files with similar steps as the partially-completed pipeline code file related steps for inclusion into the partially-completed source code.
[0022] The present specification also describes a method. According to the method, steps of a partially-completed continuous integration/continuous deployment (CI/CD) pipeline code are compared with steps of completed pipeline code files located in a repository to identify similarities therebetween. The steps may be grouped together as jobs. Based on a similarity between steps of the partially-completed pipeline code and the completed pipeline code files, related steps are identified from the completed pipeline code files. The related steps are recommended for inclusion in the partially-completed source code.
[0023] The present specification also describes a non-transitory machine- readable storage medium encoded with instructions executable by a processor. The machine-readable storage medium includes instructions to, when executed by the processor cause the processor to receive as input, a partially-completed continuous integration/continuous deployment (CI/CD) pipeline code, which partially-completed pipeline code includes a number of steps. The instructions also, when executed by the processor, cause the processor to identify, from a repository of completed pipeline code files, completed pipeline code files having similar steps as the partially-completed pipeline code and recommend related steps from the completed pipeline code files. The recommendation is based on a similarity between the steps of the completed pipeline code files and the steps of the partially-completed pipeline code and a co-occurrence between the related steps and the steps of the completed pipeline code files. [0024] In summary, using such a system, method, and machine-readable storage medium may, for example, 1 ) leverages previously used CI/CD pipeline code to complete CI/CD pipelines under development; 2) reduces duplication in different repositories; 3) provides visibility of the code used in various CI/CD pipelines; and 4) promotes collaborative use of CI/CD code. However, it is contemplated that the devices disclosed herein may address other matters and deficiencies in a number of technical areas, for example.
[0025] As used in the present specification and in the appended claims, the term “a number of” or similar language is meant to be understood broadly as any positive number including 1 to infinity.
[0026] Fig. 1 is a block diagram of a system (100) for recommending continuous integration/continuous deployment (CI/CD) pipeline code, according to an example of the principles described herein. As described above, CI/CD pipeline code files include the program code that executes the automated processes carried out on an application. That is, throughout its life, an application is subject to different stages such as quality assurance, development, staging, and production. Each of these stages are executed via program code that is compiled in a CI/CD pipeline code file. Accordingly, the system (100) includes a repository (102) to store the CI/CD pipeline code files. Each pipeline code file may correspond to a different CI/CD pipeline. In general, each CI/CD pipeline may include a hierarchical structure. For example, the CI/CD pipeline may be made up of stages, with each stage being made up of jobs, and each job being made up of steps. As such, stages represent the highest level (e.g., development, quality assurance, staging, production, etc.), jobs represent an intermediate level (e.g., build, deploy, test, etc.), and steps represent the lowest level (e.g., download a tool, run a tool, verify results, etc.). Accordingly, the pipeline code files may include tags, or other distinguishing metadata, for each of the stages, jobs, and steps that make up the CI/CD pipeline code files.
[0027] That is, different CI/CD pipelines may be developed to automate different tasks. Specifically, different CI/CD pipelines may include different stages with the different stages potentially having different jobs found therein. Even if different CI/CD pipelines include the same stages, each stage may be different in that different jobs and steps are used in a particular stage. For example, two CI/CD pipelines may include a testing stage. However, the steps of each testing stage may be different between the different CI/CD pipelines. As another example, a quality assurance stage and a production stage may each include a build job and a deploy job. However, the quality assurance stage may have a test job that the production stage does not.
[0028] The system (100) also includes a non-transitory machine-readable storage medium (104) to store CI/CD code instructions (105). The system (100) also includes a processor (106) to execute the CI/CD code instructions (105). The non-transitory machine-readable storage medium (104) is communicatively coupled to the processor (106). The non-transitory machine-readable storage medium (104) may be an electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. The non-transitory machine- readable storage medium (104) may be, for example, Random-Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, etc.
[0029] As described above, the CI/CD code instructions (105) cause the processor (106) to execute certain operations. Specifically, the CI/CD code instructions (105) cause the processor (106) to receive an update to application files. That is, as described above, programmers may submit updates to application program code to the system (100) for automated building, testing, and deployment. The processor (106) receives these update files and executes the automated processes. That is, reception of the updates calls an associated pipeline code file to verify (build, test, and deploy) the application code with the update incorporated. [0030] The processor (106) may also compare steps of a partially-completed pipeline code with steps of completed pipeline code files located in the repository (102). As described above, pipeline code may have a hierarchical structure. Specifically, the pipeline code may be divided into stages, with each stage being made up of jobs, and each job being made up of steps. The present specification describes the comparison of steps of a partially-completed pipeline code with the steps of completed pipeline code files in the repository (102). For example, a user may be developing a CI/CD pipeline that includes a test job and a deploy job. Accordingly, the processor (106) may scan the repository (102) for completed CI/CD pipeline code files that include test jobs and deploy jobs of the same nature. That is, each job in a CI/CD pipeline code may have steps that are made of up tasks. Accordingly, rather than just looking for a completed pipeline code file that includes the same steps, the processor (102) may identify completed pipeline code files that include similar steps which have similar tasks as the steps and tasks in a partially-completed CI/CD pipeline code.
[0031] Completed pipeline code files that include similar steps and/or tasks as a partially-completed pipeline code may serve as a source of recommendations to the developer of the partially-completed pipeline code. That is, as the developer is generating the pipeline code, the system (100) may identify similar features between the current pipeline code and completed pipeline code files. As they have similar features, the current pipeline code may benefit from including other features from the completed pipeline code file that have not yet been included in the current pipeline code. That is, the developer may leverage work done on a previous and similar CI/CD pipeline to add components that may increase the quality and efficacy of their pipeline code currently being worked on.
[0032] As described, similarity may be determined on a similarity of steps. That is, the steps of a pipeline code are made up of tasks that are carried out during the automation process. Steps may be a set of properties (i.e. , keys associated with respective values), and may include programming and configuration information. Given their semi-structured text form, steps may be stored in a document-oriented database and may be readily searched. For example, a step that involves the installation of a build automation tool may be retrieved with a query for a particular build automation tool. This same step may be retrieved with the query for “displayName:” followed by the particular build automation tool. This query would search the field “displayName” for the particular build automation tool.
[0033] In some examples, step definitions may be clustered using nonsupervised learning that includes information retrieval approaches that use semantic information from the source code. Such non-supervised learning may make use of both the keys and the values that make up the properties of a step definition, plus any programming logic and configuration present in it. Based on this searching function, the processor (106) may compare the similarity of two or more whole steps and rank them accordingly. For example, a first step of: template: steps/_secure-file-download-v0.yaml parameters: filename: “settingsFile” secureFileName: ‘settings. xml’ may be deemed more similar to a second step of: template: steps/_secure-file-download-v0.yaml parameters: filename: “settingsSecurityFile” secureFileName: ‘settings-security.xml’ as compared to a similarity of this second step to a third step of: task: FileTransform@2 inputs: folderPath: ‘$(Build.SourcesDirectory) ‘ xmlTransformationRules: jsonTargetFiles: ‘./conf/templates/$(environment).json’ [0034] Accordingly, as demonstrated above, steps of a CI/CD pipeline code are structured such that they may be readily compared to one another to determine similarity.
[0035] The CI/CD code instructions (105) in the non-transitory machine- readable storage medium (104) also cause the processor (106) to recommend steps from the completed pipeline code files to be included in the partially- completed pipeline code. That is, once a similarity is determined, additional steps from the completed pipeline code file are recommended for inclusion into the partially-completed pipeline code.
[0036] Such a recommendation includes the tasks that make up the step. That is, steps include a number of tasks and a recommended related step includes a recommendation of the tasks that make up the related step. In other words, a recommendation may not be to just append a particular step to the pipeline source code in progress, but a recommendation of a specific step that has particular tasks deemed relevant to the partially completed pipeline code. For example, a pipeline code in progress may include a java build test and a java test step, each having particular tasks. In this example, the recommendation may be based not only on an identification of completed pipeline code files containing these particular java build and java test steps, but that also include the particular tasks within each step.
[0037] In some examples, the comparison is between the partially-completed pipeline code and multiple completed pipeline code files. That is, the processor (106) may identify multiple completed pipeline code files that have similar steps to those already entered in the partially-completed pipeline code. In this example, the recommended related steps may be based on an aggregate of the multiple completed pipeline code files associated with the identified similarity. Figs. 4A and 4B provide an example where a recommendation is based on multiple completed pipeline code files.
[0038] In some examples, the steps of the pipeline code files are grouped as jobs. That is, jobs are composed of steps and may also have properties of their own. Accordingly, as semi-structured text, they may be compared similar to the operations described above regarding step comparison. In this example, the comparing of the steps is performed at a job level. That is, jobs of a partially- completed pipeline code are compared with jobs of one or multiple completed pipeline code files in the repository (102). As such, a recommendation may be for a related job and the steps that are included therein. For example, a deploy job with particular steps may be recommended when particular build and test jobs are identified both in a partially-completed pipeline code and a similar completed pipeline code file. Accordingly, the system (100) provides for the recommendation of particular CI/CD code content based on a comparison of unique features of CI/CD code, i.e. , jobs and steps, to identify similar content between a pipeline code in progress and completed pipeline code. Additional jobs and/or steps in the completed pipeline code are suggested for inclusion in the pipeline code in progress as the similarity may suggest that the additional jobs and/or steps would be desirable in the pipeline code in progress.
[0039] Fig. 2 is a flowchart of a method (200) for recommending CI/CD pipeline code, according to an example of the principles described herein. As described above, each pipeline code file may include a hierarchical structure of stages, jobs, and steps. Specifically, the pipeline code file may include stages, where a stage is made up of a number of jobs. Similarly, each job may include a number of steps. [0040] The method (200) includes comparing (block 201 ) steps of a partially- completed CI/CD pipeline code with steps of completed pipeline code files located in the repository (Fig. 1 , 102). Such a comparison (block 201 ) identifies similarities between the partially-completed pipeline code and the completed pipeline code files. To identify the similar steps, a variety of operations may be carried out. For example, a semi-structured text analysis of the pipeline code files may be performed. That is, the pipeline code may be semi-structured text meaning that it has certain consistent characteristics, but also has other features that are not consistent. For example, the pipeline code files include certain attributes such as stages, jobs, and steps, that may have consistent nomenclature. By comparison, the values associated with these attributes may vary. Accordingly, the processor (Fig. 1 , 106) may carry out semi-structured text searching to identify similar pipeline code between a partially-completed pipeline code and completed pipeline code files.
[0041] The comparison (block 201 ) may also include performing a graph model similarity analysis of the pipeline code files. That is, each pipeline code file may be represented as a graph representation of the hierarchy. For example, stages of the CI/CD pipeline may be represented at one hierarchical level as stage nodes and the jobs that make up that stage may be represented as child nodes to the stage node. Similarly, the steps that make up a job may be represented as child nodes to a job node. Accordingly, the graphical model analysis may identify those code sections that are similar to different pipeline code files. Accordingly, as described above, the comparison (block 201 ) of the number of pipeline code includes a semistructured text analysis and a graph model analysis of the pipeline code to identify similarities.
[0042] The processor (Fig. 1 , 106) may then identify (block 202) related steps from the completed pipeline code files. This identification may be based on the similarity of steps between the partially-completed pipeline code and the completed pipeline code files. That is, once completed pipeline code files are determined to be similar to the partially-completed pipeline code based on similar steps and/or jobs, the processor (Fig. 1 , 106) may scan the completed pipeline code files for content that may be of use to the partially-completed pipeline code. For example, the partially-completed pipeline code may include a java build job and a java test job. From completed pipeline code files with java build jobs and java test jobs, the processor (Fig. 1 , 106) may determine that a java deploy job, with particular steps, is frequently found in these completed pipeline code files. Accordingly, the processor (Fig. 1 , 106) recommends (block 203) the related steps for inclusion in the partially-completed pipeline code.
[0043] In some examples, the recommendation (block 203) may be based on additional criteria. Specifically, the recommendation may be based on metadata associated with the related steps, which metadata may include an author of the related step, a quantity of use of the related step, and/or a timestamp of the uses of the related step. For example, there may be multiple related steps. However, the metadata with a first related step may indicate that it is used more and has been used more recently than a second related step. Accordingly, the recommendation may be to use the first related step as opposed to the second related step. Put another way, this additional metadata provides information such as who wrote an available piece of code to be reused and how many executions the same piece of code had in a predetermined time period. Such information may be relevant to determining which related steps would be most beneficial and practical for the developer to implement.
[0044] In some examples, the method (200) may be performed cyclically as a developer is generating a CI/CD pipeline code. For example, as a developer starts development of a new pipeline code, the developer may give some information about the code, for example inputting the word “java” into a search query. Responsive, the system (Fig. 1 , 100) may provide a variety of steps and/or jobs with the java definition. As the input at this point is a single word, the recommendations may be quite broad. After inputting recommended code or other code, more input is available to the system (Fig. 1 , 100) for providing customized and tailored recommendations.
[0045] As a specific example, in a first interaction, a developer may input a search query of the word “java.” Responsive to this input, the system (Fig. 1 , 100) may output a number of steps and/or jobs that relate to the word “java” anywhere in their definitions.
[0046] In a second interaction, specific java steps and jobs are input into the pipeline code. In this example, the output may be another recommendation of steps and jobs that are based on a comparison of the input additional steps and jobs with steps and jobs from the repository (Fig. 1 , 102).
[0047] In a third interaction, additional inputs to the pipeline code are suggested and the system (Fig. 1 , 100) considers all inputs, from the first, second, and third interactions, to recommend even more tailored content based on all the information previously provided. This is a pattern that may continue throughout the generation of the CI/CD pipeline code. As described above, the operations in the method (200), that is the comparing (block 201 ), identifying (block 202), recommending (block 203) may be performed in real-time as the partially-completed pipeline code is being generated.
[0048] Fig. 3 is a flowchart of a method (300) for recommending CI/CD pipeline code, according to an example of the principles described herein. As described above, the method (300) may include comparing (block 301 ) partially-completed pipeline code with completed pipeline code files in a repository (Fig. 1 , 102) and identifying (block 302) related steps from the completed pipeline code files. These operations may be performed as described above in connection with Fig. 2.
[0049] In some examples, additional measures may be taken. That is, in an example, comparing (block 301) partially-completed pipeline code may include analyzing an output of an execution of the step. The output of a particular step may be used to determine whether or not a step of a completed pipeline code file is similar to a partially-completed pipeline code.
[0050] As one particular example, the related steps may be ranked (block 304) based on a relatedness of the similar content. That is, if the partially-completed pipeline code is more similar to a first completed pipeline code file than to second completed pipeline code file, then the related items originating from the first completed pipeline code file may be ranked (block 304) higher.
[0051] In another example, the ranking (block 304) may be based on a cooccurrence of the related steps and steps from the completed pipeline code files deemed similar to the partially-completed pipeline code. That is, the proximity of jobs and steps and the frequency of such proximity may be considered in the recommendation (block 303). For example, jobs and steps are not isolated and therefore have jobs and steps that come before and after them. Such proximity, as well as the frequency of such proximity may be useful for developers looking for reusing CI/CD pipeline code. For example, a deployment job or step that is followed by a job or step of functional testing may be deemed more relevant than a deployment job or step that is not followed by functional testing. The processor (Fig. 1 , 106) may execute association rule learning for discovering co-occurrence in databases. Association rules may be created by searching data for frequent if-then patterns and using the criteria support and confidence to identify potentially relevant relationships. Specifically, the processor (Fig. 1 , 106) may determine a support, which refers to an indication of how frequently the items appear in the data. The processor (Fig. 1 , 106) may also determine confidence which indicates the number of times the if-then statements are found true. Figs. 4A and 4B provide a specific example of different related steps being ranked differently.
[0052] According to the method (300), the recommended related steps may be visually appended (block 305) to the partially-completed pipeline code. That is, the developer may generate the pipeline code in a user interface with script displayed. In this example, the processor (Fig. 1 , 106) may visually append (block 305) the recommended content where it would be inserted were it to be accepted. The recommendation may have a visual distinction, for example by being a different color than entered pipeline code. In this example, the user may choose to accept, reject, or alter the recommended steps.
[0053] Figs. 4A and 4B depict a partially-completed CI/CD pipeline code (408) and sections of completed pipeline code files (410) from which recommendations are drawn, according to an example of the principles described herein.
[0054] As described above, a developer may start generation of a new CI/CD pipeline code (408) which may include certain steps such as a java_build step and a unit_test step. Based on a semi-structured analysis of this partially-completed pipeline code (408), the processor (Fig. 1 , 106) may identify three completed pipeline code files (410-1 , 410-2, 410-3) with related steps. Specifically, a first completed pipeline code file includes the steps java_build, unit_test, check_code_coverage, functional_test, publish_test_results, a second completed pipeline code file includes the steps java_build, functional_test, publish_test_results, and a third completed pipeline code file includes the steps java_build, functional_test, publish_test_results. The processor (Fig. 1 , 106) may determine various characteristics of similarity.
[0055] By applying association rules, the processor (Fig. 1 , 106) may determine that when pipeline code includes a step for java_build there are also steps of functional_test and publish_test_results as indicated in each of the completed pipeline code files (410-1 , 410-2, 410-3). The processor (Fig. 1 , 106) may also determine that when pipeline code includes a unit_test step, there is likely to be a check_code_coverage step as indicated in the second completed pipeline code file (410-2). Accordingly, in this example, the processor (Fig. 1 , 106) may recommend a functional_test, publish_test_results, and check_code_coverage steps for inclusion into the partially-completed pipeline code (408).
[0056] Fig. 5 depicts a non-transitory machine-readable storage medium (104) for recommending CI/CD pipeline code, according to an example of the principles described herein. To achieve its desired functionality, the system (Fig. 1 , 100) includes various hardware components. Specifically, the system (Fig. 1 , 100) includes a processor (Fig. 1 , 106) and a machine-readable storage medium
(104). The machine-readable storage medium (104) is communicatively coupled to the processor. The machine-readable storage medium (104) includes a number of instructions (512, 514, 516) for performing a designated function. In some examples, the instructions may be machine code and/or script code.
[0057] The machine-readable storage medium (104) causes the processor to execute the designated function of the instructions (512, 514, 516). The machine- readable storage medium (104) can store data, programs, instructions, or any other machine-readable data that can be utilized to operate the system (Fig. 1 , 100). Machine-readable storage medium (104) can store machine readable instructions that the processor of the system (Fig. 1 , 100) can process, or execute. The machine-readable storage medium (104) can be an electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Machine-readable storage medium (104) may be, for example, Random-Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, etc. The machine-readable storage medium (104) may be a non-transitory machine-readable storage medium (104). [0058] Referring to Fig. 5, receive instructions (512), when executed by the processor (Fig. 1 , 106), cause the processor (Fig. 1 , 106) to, receive as input, a partially-completed CI/CD pipeline code (Fig. 4, 408) which includes a number of steps. Identify instructions (516), when executed by the processor (Fig. 1 , 106), cause the processor (Fig. 1 , 106) to, identify, from a repository (Fig. 1 , 102) of completed pipeline code files (Fig. 4, 410), completed pipeline code files (Fig. 4, 410) having similar steps as the partially-completed pipeline code (Fig. 4, 408). Recommend instructions (518), when executed by the processor (Fig. 1 , 106), cause the processor (Fig. 1 , 106) to, recommend related steps from the completed pipeline code files (Fig. 4, 410) based on 1 ) a similarity between the steps of the completed pipeline code files (Fig. 4, 410) and the steps of the partially-completed pipeline code (Fig. 4, 408) and 2) a co-occurrence between the related steps and the steps of the completed pipeline code files (Fig. 4, 410).
[0059] In summary, using such a system, method, and machine-readable storage medium may, for example, 1 ) leverages previously used CI/CD pipeline code to complete CI/CD pipelines under development; 2) reduces duplication in different repositories; 3) provides visibility of the code used in various CI/CD pipelines; and 4) promotes collaborative use of CI/CD code. However, it is contemplated that the devices disclosed herein may address other matters and deficiencies in a number of technical areas, for example.

Claims

CLAIMS What is claimed is:
1. A system, comprising: a repository to store continuous integration/continuous development (CI/CD) pipeline code files, each pipeline code file to validate an application; a non-transitory machine-readable storage medium to store instructions; and a processor to execute the instructions, the instructions to cause the processor to: compare steps of a partially-completed pipeline code with steps of completed pipeline code files located in the repository; and recommend, from completed pipeline code files with similar steps as the partially-completed pipeline code, related steps for inclusion into the partially-completed pipeline code.
2. The system of claim 1 , wherein: a step comprises a number of tasks; and a recommended related step comprises a recommendation of tasks that make up the related step.
3. The system of claim 1 , wherein the processor is to recommend related steps based on a comparison of the partially-completed pipeline code with multiple completed pipeline code files located in the repository.
4. The system of claim 1 , wherein the steps of the pipeline code files are grouped as jobs.
5. The system of claim 4, wherein comparing steps of a partially-completed pipeline code with steps of completed pipeline code files located in the repository comprises comparing a job of the partially-completed completed pipeline code with jobs of the completed pipeline code files in the repository.
6. The system of claim 4, wherein a recommendation comprises an additional job and the steps that are included therein.
7. A method, comprising: comparing steps of a partially-completed continuous integration/continuous deployment (C 1/CD) pipeline code with steps of completed pipeline code files located in a repository to identify similarities therebetween, wherein steps are grouped together as jobs; identifying, based on a similarity between steps of the partially-completed pipeline code and the completed pipeline code files, related steps from the completed pipeline code files; and recommending the related steps for inclusion in the partially-completed pipeline code.
8. The method of claim 7, further comprising visually appending recommended related steps to the partially-completed pipeline code.
9. The method of claim 7, further comprising ranking related steps based on a degree of relatedness between the partially-completed pipeline code and the completed pipeline code file.
10. The method of claim 9, wherein the ranking is further based on a cooccurrence of the related steps and steps from the completed pipeline code file.
11 . The method of claim 7, wherein identifying related steps is further based on an output of an execution of the step.
12. The method of claim 7, wherein recommending the related steps is based on metadata associated with the related steps.
13. The method of claim 12, wherein the metadata is selected from the group consisting of: an author of the related step; a quantity of use of the related step; and a timestamp of the uses of the related step.
14. A non-transitory machine-readable storage medium encoded with instructions executable by a processor, the machine-readable storage medium comprising instructions to, when executed by the processor cause the processor to: receive as input, a partially-completed continuous integration/continuous deployment (CI/CD) pipeline code, which partially- completed pipeline code comprises a number of steps; identify, from a repository of completed pipeline code files, completed pipeline code files having similar steps as the partially-completed pipeline code; and recommend related steps from the completed pipeline code files based on: a similarity between the steps of the completed pipeline code files and the steps of the partially-completed pipeline code; and a co-occurrence between the related steps and the steps of the completed pipeline code files.
15. The non-transitory machine-readable storage medium of claim 14, wherein receiving a partially-completed CI/CD pipeline code, identifying completed pipeline code files having similar steps as the partially-completed pipeline code, and recommending related steps are performed while the partially-completed pipeline code is being generated.
22
PCT/US2020/057387 2020-10-26 2020-10-26 Ci/cd pipeline code recommendations WO2022093178A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2020/057387 WO2022093178A1 (en) 2020-10-26 2020-10-26 Ci/cd pipeline code recommendations

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2020/057387 WO2022093178A1 (en) 2020-10-26 2020-10-26 Ci/cd pipeline code recommendations

Publications (1)

Publication Number Publication Date
WO2022093178A1 true WO2022093178A1 (en) 2022-05-05

Family

ID=81383110

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/057387 WO2022093178A1 (en) 2020-10-26 2020-10-26 Ci/cd pipeline code recommendations

Country Status (1)

Country Link
WO (1) WO2022093178A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4290368A1 (en) * 2022-06-09 2023-12-13 Siemens Aktiengesellschaft Computer-implemented method and system for generating a command pipeline for controlling a technical device

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6715145B1 (en) * 1999-08-31 2004-03-30 Accenture Llp Processing pipeline in a base services pattern environment
US20100017459A1 (en) * 2000-06-30 2010-01-21 International Business Machines Corporation Device and method for updating code
US20100057663A1 (en) * 2008-08-29 2010-03-04 Oracle International Corporation Techniques for matching a certain class of regular expression-based patterns in data streams
US8037453B1 (en) * 2006-09-13 2011-10-11 Urbancode, Inc. System and method for continuous software configuration, test and build management
US20110307879A1 (en) * 2009-02-24 2011-12-15 Toyota Jidosha Kabushiki Kaisha Program update device, program update method, and information processing device
US20140189641A1 (en) * 2011-09-26 2014-07-03 Amazon Technologies, Inc. Continuous deployment system for software development

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6715145B1 (en) * 1999-08-31 2004-03-30 Accenture Llp Processing pipeline in a base services pattern environment
US20100017459A1 (en) * 2000-06-30 2010-01-21 International Business Machines Corporation Device and method for updating code
US8037453B1 (en) * 2006-09-13 2011-10-11 Urbancode, Inc. System and method for continuous software configuration, test and build management
US20100057663A1 (en) * 2008-08-29 2010-03-04 Oracle International Corporation Techniques for matching a certain class of regular expression-based patterns in data streams
US20110307879A1 (en) * 2009-02-24 2011-12-15 Toyota Jidosha Kabushiki Kaisha Program update device, program update method, and information processing device
US20140189641A1 (en) * 2011-09-26 2014-07-03 Amazon Technologies, Inc. Continuous deployment system for software development

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4290368A1 (en) * 2022-06-09 2023-12-13 Siemens Aktiengesellschaft Computer-implemented method and system for generating a command pipeline for controlling a technical device
WO2023237439A1 (en) * 2022-06-09 2023-12-14 Siemens Aktiengesellschaft Computer-implemented method and system for generating a command pipeline for controlling a technical device

Similar Documents

Publication Publication Date Title
Karampatsis et al. How often do single-statement bugs occur? the manysstubs4j dataset
Aljedaani et al. Test smell detection tools: A systematic mapping study
Youm et al. Improved bug localization based on code change histories and bug reports
CN111832236B (en) Chip regression testing method and system, electronic equipment and storage medium
US11907107B2 (en) Auto test generator
Rolim et al. Learning quick fixes from code repositories
Pantiuchina et al. Why developers refactor source code: A mining-based study
Chaturvedi et al. Tools in mining software repositories
Langer et al. A posteriori operation detection in evolving software models
Wang et al. Formalizing and integrating the dynamic model within OMT
US11256502B2 (en) Automatic generation of documentation and aggregation of community content
Hu et al. Modeling the evolution of development topics using dynamic topic models
US20110161938A1 (en) Including defect content in source code and producing quality reports from the same
Sacramento et al. Web application model generation through reverse engineering and UI pattern inferring
Kamienski et al. Pysstubs: Characterizing single-statement bugs in popular open-source python projects
Jebnoun et al. Clones in deep learning code: what, where, and why?
Agarwal et al. Copilot Evaluation Harness: Evaluating LLM-Guided Software Programming
WO2022093178A1 (en) Ci/cd pipeline code recommendations
Carvalho et al. DMOSS: Open source software documentation assessment
Elaasar et al. VPML: an approach to detect design patterns of MOF-based modeling languages
Frick Understanding software changes: Extracting, classifying, and presenting fine-grained source code changes
Karakoidas et al. Generating the blueprints of the Java ecosystem
Fluri et al. Recommending method invocation context changes
Falchi IT tools for the management of multi—Representation geographical information
Sualim et al. Ontology of mutation testing for Java operators

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: 20960100

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: 20960100

Country of ref document: EP

Kind code of ref document: A1