Apparatus and method for software development collaboration

Abstract

To provide a method and device for verifying quality assurance on a plurality of software parts.SOLUTION: A computer performs a quality assurance test on each software part of a plurality of software parts to receive result data, processes the result data for each software part to extract metrics, receives a quality gate configuration for the software part type, where the quality gate configuration comprises at least one metric gate, compares the metrics for each software part based on the at least one metric gate, and outputs a result of the build and the metrics based on the comparison and the quality gate configuration.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Apparatus and methods consistent with exemplary embodiments of the present disclosure relate to managing quality gates for software components. [Background technology]

[0002] In the field of software development, tools such as version control and quality assurance allow multiple collaborating software developers to collaborate on a software project, which may include each developer working on an individual component. Each individual component may implement a different function and may be referred to as a "software component." A software component may depend on (i.e., have dependencies on) other software components. When developing a software project, multiple software components may be developed in parallel to enable faster and more robust development.

[0003] In the related art, version control is typically implemented in scenarios where a developer wants to create a new version of software. Branching is typically used in the related art to implement version control. For example, there may be a main branch that is the current version of the software. To create the new version, the developer may create a new branch from the main branch. This may allow the developer to test the new branch, including any new functionality that the new branch may contain. Changes in this new branch may later be merged back into the main branch.

[0004] Quality assurance tools are also commonly used in software development and may allow a user to assess whether a software component achieves certain quality metrics.

[0005] In the related art, situations may arise in which multiple companies or entities in a supply chain are involved, and as a result, the source code for each software component may not be easily available to all involved developers (e.g., there may be software components that may have closed source code). In other words, there may be "boundaries" between different software components depending on ownership. Therefore, it may be difficult for developers to test whether a software component with a newer version / branch can function with a dependent software component that has closed source code, i.e., what kind of effect the newer software component may have across the entire software component stack (e.g., software components and their dependencies).

[0006] Additionally, while the related art may describe using quality assurance tools for software development, it does not describe automating and standardizing the use of quality assurance tools across multiple software components, and in particular, it does not provide a way to ensure that all specified software components in a project achieve specific quality metrics.

[0007] Therefore, there is a need for version control to manage multiple software components and their dependencies while also being able to enforce quality standards in a standardized way across multiple software components. Summary of the Invention

[0008] According to one or more exemplary embodiments, an apparatus and method are provided for software development collaboration. In particular, software parts (which are individual software components that may each implement different functions) may be used. A computer-implemented method for applying quality gates to multiple software parts of a given type may be provided. In particular, the computer performs quality assurance tests on each software part of the multiple software parts to receive result data, processes the result data to extract metrics (e.g., some means of determining the quality of the software part), and receives a quality gate configuration for the given software part type, the quality gate configuration including metric gates that can be used to compare the metrics with requirements specified in the metric gates. The results of the comparison and the metrics themselves may then be output to a user. The quality gates thus ensure that standardized quality assurance methods are enforced across each software part of a given software part type and that users can easily access the results of the quality assurance tests against the quality gates.

[0009] According to an embodiment, there may be provided a computer-implemented method for verifying quality assurance for a plurality of software components having a software component type, the method comprising: executing a quality assurance test for each software component of the plurality of software components to receive result data; processing the result data for each software component to extract metrics; receiving a quality gate configuration comprising at least one metrics gate for the software component type; comparing the metrics for each software component based on the at least one metrics gate; and outputting build results and metrics based on the comparison and the quality gate configuration.

[0010] If the comparison of the metric to the metric gate has a negative result, the result of the build may be an indication that the build failed. If the comparison of the metric to the metric gate has a positive result, the result of the build may be an indication that the build succeeded.

[0011] The quality gate configuration may include a stage name identifier that may be used to identify the development stage at which the quality gate is being enforced, and an enforcement level parameter that may be output as a result of the build if the metrics gate has a negative result.

[0012] At least one metric gate may include a metric name identifier that may be used to identify the type of metric being compared; threshold parameters comprising a warning threshold and an error threshold, where if the warning threshold is met by the comparison, the result of the build may include specifying a warning; if the error threshold is met by the comparison, the result of the build may include specifying an error; and if the result of the build is neither a warning nor an error, the result of the build may instead include specifying success; and a comparison type parameter that indicates how the value of the metric should be compared to the threshold parameters.

[0013] Outputting the results and metrics of the build may further include rendering a visualization of the results of the build, where a first style is rendered if the results include specifying a warning, a second style is rendered if the results include specifying an error, or a third style is rendered if the results instead include specifying success, wherein the first style, the second style, and the third style are different from one another.

[0014] According to example embodiments, a feature branch may be implemented that includes multiple software components. The software components may have a hierarchy, and a parent software component may have dependent software components. Apparatus and methods according to example embodiments may include creating a new feature branch, branching each software component down from the parent software component to the dependent software component, and merging the feature branch back into the main branch. Once branched, each software component may be built and published, including testing that the software component can be built without errors. Thus, the feature branch may be used to test and build the entire software component stack.

[0015] According to an embodiment, there may be provided a computer-implemented method for managing a plurality of software components including at least a first software component, wherein the computer receives a request to create a function branch, branches the first software component, builds the branched first software component, checks whether the built first software component is successful, sends an error message if the built first software component is not successful, publishes the built first software component as a first package if the built first software component is successful, searches for dependent software components of a plurality of software components that depend on the first software component, and branches each dependent software component.

[0016] The dependent software component may include at least a second software component, and branching each dependent software component includes branching the second software component, and the computer updates the dependency of the branched second software component to be on the first package, builds the branched second software component, checks whether the built second software component is successful, and if the built second software component is not successful, sends an error message, and if the built second software component is successful, publishes the built second software component as a second package, and checks whether the checks of all dependent software components were successful.

[0017] If the checks of all dependent software components are successful, the computer rebases the branched first software component to the main branch, merges the branched first software component into the main branch, builds the merged first software component, publishes the merged first software component as a first main branch package, and searches for dependent software components.

[0018] The computer rebases the branched second software component so that it is on the main branch, updates the dependency of the branched second software component so that it is on the first main branch package, merges the branched second software component into the main branch, builds the merged second software component, and publishes the merged second software component as a second main branch package.

[0019] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0020] Features, aspects, and advantages of certain preferred embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Figure 1] FIG. 1 is a diagram of exemplary components of a device according to an exemplary embodiment. [Figure 2] FIG. 2 is a block diagram of a quality gate configuration file according to one or more exemplary embodiments. [Figure 3] FIG. 3 is a flowchart diagram illustrating a method for applying quality assurance tests to software components according to one or more exemplary embodiments. [Figure 4A] FIG. 4A is a flowchart diagram illustrating a method for forking and merging function branches for a software component according to one or more exemplary embodiments. [Figure 4B] FIG. 4B is a flowchart diagram illustrating a method for forking and merging function branches for a software component according to one or more exemplary embodiments. [Figure 5] FIG. 5 is a flowchart diagram illustrating an example of creating function branches for software components with dependencies, according to one or more exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0021] The following detailed description of exemplary embodiments refers to the accompanying drawings. While the present disclosure provides illustration and description, it is not intended to be exhaustive or to limit one or more exemplary embodiments to the precise form disclosed. Modifications and variations are possible in light of the disclosure or may be learned from the practice of one or more exemplary embodiments. Moreover, one or more features or components of one exemplary embodiment may be incorporated into or combined with another exemplary embodiment (or one or more features of another exemplary embodiment). Furthermore, in the flowcharts and descriptions of operations provided herein, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may occur (at least partially) concurrently, or the order of one or more operations may be swapped.

[0022] It will be apparent that exemplary embodiments of the systems and / or methods and / or non-transitory computer-readable storage media described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement the systems and / or methods is not a limitation of one or more exemplary embodiments. Thus, the operation and behavior of the systems and / or methods and / or non-transitory computer-readable storage media will be described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0023] Although a particular combination of features may be recited in a claim and / or disclosed herein, such combination is not intended to limit the disclosure of possible example embodiments. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible example embodiments includes each dependent claim in combination with all other claims in the claim set.

[0024] No element, act, or instruction used herein should be construed as critical or required unless expressly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "a" or similar terms are used. Also, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0025] As used herein, the term "software component" refers to an individual component or unit of software that may implement one or more functions. Such software components may depend on other software components. Multiple software components having the same software component type may also be provided. Specifically, the software component type may indicate what the software component is intended for (e.g., SDK (Software Development Kit), integration, system testing, etc.). Each of the software component types may have a standard (e.g., an ISO standard) that the software component must pass in order to pass a particular development stage (e.g., a coverage stage where the user still intends to collect and evaluate only code coverage metrics). The standard may be evaluated in terms of metrics. According to some embodiments, each software component may have an identifier, including, but not limited to, a version number and a function name.

[0026] 1 is a diagram of example components of a software development device 100. As shown in FIG. 1, software development device 100 may include a bus 110, a processor 120, a memory 130, a storage component 140, an input component 150, an output component 160, and a communication interface 170.

[0027] Bus 110 includes components that enable communication between components of software development device 100. Processor 120 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 120 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. In one or more exemplary embodiments, processor 120 includes one or more processors that are programmable to perform functions. Memory 130 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 120.

[0028] Storage component 140 stores information and / or software related to the operation and use of software development device 100. For example, storage component 140 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive. Input component 150 includes components (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone) that enable software development device 100 to receive information, such as via user input. Additionally or alternatively, input component 150 may include sensors (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator) that detect information. Output component 160 includes components (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)) that provide output information from software development device 100.

[0029] Communications interface 170 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable software development device 100 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communications interface 170 may enable software development device 100 to receive information from and / or provide information to another device. For example, communications interface 170 may include, but is not limited to, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, or the like.

[0030] Software development device 100 may perform one or more of the example processes described herein. According to one or more example embodiments, software development device 100 may perform such processes in response to processor 120 executing software instructions stored by a non-transitory computer-readable medium, such as memory 130 and / or storage component 140. Computer-readable media are defined herein as non-transitory memory devices. Memory devices include memory space within a single physical storage device or memory space spanning multiple physical storage devices.

[0031] Software instructions may be read into memory 130 and / or storage component 140 from another computer-readable medium or from another device via communications interface 170. The software instructions stored in memory 130 and / or storage component 140, when executed, may cause processor 120 to perform one or more of the processes described herein.

[0032] Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more of the processes described herein. Thus, one or more exemplary embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0033] The number and arrangement of components shown in Figure 1 are provided as an example. In fact, software development device 100 may include additional, fewer, different, or differently arranged components than those shown in Figure 1. Additionally or alternatively, a set of components (e.g., one or more components) of software development device 100 may perform one or more functions that are described as being performed by another set of components of software development device 100.

[0034] Quality Gate

[0035] 2 is a block diagram of a quality gate configuration file 200 according to one or more exemplary embodiments. The quality gate configuration file 200 may include a metrics gate 210, a stage name identifier (ID) 220, and an enforcement level parameter 230.

[0036] Metrics gate 210 may define one or more rules that enforce whether a built software component passes a quality assurance test. Metrics gate 210 may include a metrics name identifier (ID) 211 that may be used to uniquely identify each metrics gate, threshold parameters 212 that may be used to set specific values ​​for passing / failing a quality assurance test, and comparison type parameters 213 that may be used to set how the results of the quality assurance test are compared to threshold parameters 212. Threshold parameters 212 may be further defined by warning threshold 212-1, which may set the threshold at which a warning result is given, and error threshold 212-2, which may set the threshold at which an error result is given.

[0037] For example, metrics gate 210 may check whether a quality assurance test results in a value of strictly 0.9 or greater for a passing result (e.g., a positive result). If the result is less than 0.9, an error may be indicated for the build (e.g., a negative result). If it is well above 0.9, a success may be indicated for the build. If it is just barely 0.9, a warning may be indicated for the build.

[0038] In this case, the threshold parameters 212 may include a warning threshold 212-1 of 0.91 and an error threshold 212-2 of 0.90. The comparison type parameter 213 may be set to "greater than," so that the metric should be checked to see if it exceeds the threshold parameters in order to result in a positive (successful) outcome for the build. Nevertheless, it should be understood that a variety of comparison methods may be used in the metrics gate 210.

[0039] The stage name ID 220 may be included in the quality gate configuration file 200 and used to identify the particular development stage at which the quality gate is being enforced. Different quality gates may be applied at different development stages, which may be facilitated by the use of a stage name identifier. For example, if the stage name ID 220 is "coverage," the quality gate may only be applied during the code coverage stage. Nevertheless, it should be understood that any suitable syntax may be used.

[0040] The enforcement level parameter 230 may be used to specify what the output / result of the build should be if the metrics gate 210 has a negative result. For example, if it is set to "fail," the build result may be output as "fail" if the metrics gate 210 has a negative result. Nevertheless, it should be noted that in some embodiments, the value of the result may not be exactly the same as the output, and syntax may vary depending on the implementation.

[0041] 3 is a flowchart diagram illustrating a method 300 for applying quality assurance tests to software components according to one or more exemplary embodiments. It should be understood that a configuration file similar to the quality gate configuration file 200 as shown in FIG. 2 may be used.

[0042] At operation S310, quality assurance tests may be performed on each software component of the plurality of software components to receive result data. Each software component may have its own software component type. This may be done using any appropriate quality assurance tool as deemed appropriate by the software developer. Results of the quality assurance tests may then be obtained.

[0043] At operation S320, the results of the quality assurance tests may be processed to obtain metrics. In particular, because the results of quality assurance tests may not always be in a format that can be easily evaluated as metrics, in some embodiments, the results of the quality assurance tests may be processed (e.g., parsed) to obtain quality metrics.

[0044] At operation S330, a quality gate configuration (e.g., quality gate configuration file 200 as shown in FIG. 2 and described above) may be obtained for each software component type. According to some embodiments, this may include sending a request to obtain the file and a response that includes the file.

[0045] At operation S340, the metrics for each software component may be compared using a metrics gate (e.g., metrics gate 210) from the quality gate configuration file. In particular, a quality gate may be applied such that the metrics for each software component are compared using metrics gate 210. A negative result of the comparison using metrics gate 210 may be used to output an indication that the build failed, and a positive result of the comparison may be used to obtain an indication that the build was successful. Nevertheless, it should be understood that depending on the configuration of metrics gate 210 (as described above), the output for the result may vary. While the example is described using one metrics gate 210, it should be understood that multiple metrics gates may be used depending on the particular implementation.

[0046] At operation S350, the results of the build along with the metrics themselves may be output to the user, which may be based on a comparison using the metrics gates and any additional settings in the quality gate configuration file 200.

[0047] According to embodiments, the output may include some visual aspects (e.g., if the output is for a graphical user interface or dashboard). For example, a user interface (GUI) may provide an overview of the build, the current development stage, and the build status of the software components. According to embodiments, a visualization of the results and metrics may be rendered. For example, the metrics themselves may be listed in any suitable format (e.g., a list, a chart, etc.). The results may also have different visual styles depending on what the result was. For example, "warning," "success," and "failure" may correspond to different visual styles. According to some embodiments, the visual styles may be different colors (e.g., warning may correspond to yellow, success may correspond to green, and failure may correspond to red). In this example, colors may be used to highlight certain parts of the user interface, text colors may be changed, etc. It should be understood that the above examples for user interfaces are merely examples of how a user interface utilizing quality gates may be implemented, and any suitable method of visualizing results and metrics may be applied.

[0048] Based on the above embodiment, by collecting quality metrics from each software component and enforcing quality gates across each software component, the quality metrics required for a build to pass can be standardized, and therefore standardization of quality assurance can be achieved.

[0049] Feature Branch

[0050] 4A and 4B are flowchart diagrams illustrating a method 400 for forking and merging function branches for software components, according to one or more exemplary embodiments. Method 400 may be performed when an instruction is received to create function branches for multiple software components (SPs). According to an embodiment, this instruction may be initiated by an application developer.

[0051] 4A, in operation S401, a branch of a first software component may be created. In particular, the branch may be created from a main branch. This step may be performed by an application developer. For example, when a developer contributes their own changes to an application, the developer may open a new feature branch using their software development interface.

[0052] At operation S402, the branched software parts are built (e.g., compiled) and may then be subsequently tested. For example, this may include testing, such as quality assurance testing, and utilizing method 300 as described above with reference to FIG. 3. It should be appreciated that this may be done automatically through continuous integration (CI) automation.

[0053] At operation S403, the results of the test may be automatically checked. If the build is unsuccessful, the entire process may be stopped. According to some embodiments, this may include sending an error message or the like to indicate to the user that the build was not successful. Alternatively, if the build is successful, at operation S404, the process may proceed to publishing the built first software part as a first package.

[0054] At operation S405, the process may then search for dependent software components that were dependent on the first software component and perform a similar branching process repeatedly (e.g., in a loop) for each of the dependent software components. In an exemplary embodiment, it should be understood that although there may be a second software component that is dependent on the first software component, three, four, ..., n software components may nonetheless depend on the first software component.

[0055] In operation S406, a second software component is found that depends on the first software component, so the second software component may be branched.

[0056] In operation S407, the dependency of the branched second software component may be updated to be on the first public package.

[0057] At act S408, a similar build and test process (similar to act S402) may be performed on the forked second software component.

[0058] In operation S409, a similar check process (similar to operation S403) may be performed on the branched second software component, and only if the second build is successful, the built second software component may be published as a second package in operation S410; if not, the entire process may be stopped. This process of branching the second software component may be repeated for all dependent software components (e.g., third, fourth, nth software components) upon completing operation S410 (i.e., operations S406-S410 may be looped). Thus, the process may check whether the checks / tests of all dependent software components were successful, and based on this check, repeat the above process.

[0059] It should be appreciated that according to some embodiments, if during the test / check process for a successful build it is determined that any modifications to the code base are necessary, the developer may manually modify the code in the branch and then re-trigger the build and test operations.

[0060] 4B, in operation S411, after checking that all dependency tests are successful based on the operations as shown in FIG. 4A, the feature branch may be merged into the main branch. Specifically, the branched first software component as described with reference to FIG. 4A may be rebased to the main branch. The branched first software component may then be merged back into the main branch. The merged first software component may then be built and published as a first main branch package in operation S412.

[0061] After the first main branch package is published, dependent software components may be retrieved in operation S413. In particular, the branched second software component may be rebased to the main branch. Thereafter, in operation S414, the dependency of the branched second software component may be updated to the first main branch package. In operation S415, the branched second software component may be merged into the main branch, and then, in operation S416, the merged second software component may be built and published as a second main branch package. The steps for the second main branch package may be repeated for the remaining branched dependent software components (i.e., operations S414-S416 may be looped).

[0062] It should be understood that if the feature branch of a software component does not contain any additional changes to the source code, in some embodiments, no additional action from the developer is required and only the versions of the software component's dependencies are updated. In other embodiments, if a rebase fails due to previous changes to the main branch, the developer may need to manually rebase the feature branch to fix the conflicts.

[0063] FIG. 5 is a flowchart diagram illustrating an example method 500 for creating function branches for software components with dependencies, according to one or more example embodiments.

[0064] 5, base 510 is a first software component. Core 520 is a second software component that depends on base 510. App 530 is a third software component that depends on core 520. It should be understood that base 510 may be similar to the first software component described with reference to FIGS. 4A and 4B, and core 520 is a second software component that may be similar to the second software component described with reference to FIGS. 4A and 4B. App 530 may be similar to one of the dependent software components as described above with reference to FIGS. 4A and 4B.

[0065] Figure 5 shows how the branching step in the left column proceeds from the parent software component down the list of dependencies, starting from base 510, to core 520, and then down to app 530. After the branching and publishing of the last package, app 530, is complete, the merging step in the right column also proceeds from the parent software component down the list of dependencies.

[0066] The steps described with reference to the branching and merging steps in Figure 5 may be similar to those specified in Figures 4A and 4B. It should also be understood that version numbers and software part names, for example, are arbitrarily selected and any suitable name and version numbering scheme may be applied.

[0067] In operation S511, a feature branch of base 510 (feature branches in FIG. 5 are represented by the "dev" version) is created, and then built and published in operation S512.

[0068] In operation S521, a function branch of the core 520 is created.

[0069] In operation S522, the dependencies of the feature branches of core 520 are updated to be on the feature branches of base 510, and then the feature branches of core 520 are built and published in operation S523.

[0070] In operation S531, a function branch of the app 530 is created.

[0071] In operation S532, the dependency of the feature branch of app 530 is updated to be on the feature branch of core 520, and then the feature branch of app 530 is built and published in operation S533.

[0072] In operation S513, the feature branch on base 510 is rebased and the feature branch is merged into the master branch, which is then built and published in operation S514.

[0073] In operation S524, the feature branch of core 520 is rebased and the feature branch is merged into the master branch.

[0074] In operation S525, the dependency of the master branch of core 520 is updated to be on the master branch of base 510, and then the master branch of core 520 is built and published in operation S526.

[0075] In operation S534, the feature branch of app 530 is rebased and the feature branch is merged into the master branch.

[0076] In operation S535, the dependency of the master branch of app 530 is updated to be on the master branch of core 520, and then the master branch of app 530 is built and published in operation S536.

[0077] According to the above example in Figure 5, feature branches can be created for multiple software components and their dependencies and later rebased / merged back into the master branch.

[0078] By branching each software component when creating a feature branch, the entire software component stack can be easily tested and built without requiring direct access to the source code for each dependent software component. Thus, even if a dependent software component is closed source, the dependent software component can still be used in testing the parent software component. Thus, testing can be easily performed for each feature branch.

[0079] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the exemplary embodiment or embodiments to the precise forms disclosed. Modifications and variations are possible in light of the disclosure or may be learned from practice of the exemplary embodiment or embodiments.

[0080] One or more exemplary embodiments may relate to a system, method, and / or computer-readable medium at any possible level of technical detail of integration. Furthermore, one or more of the above-described components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium(s) having computer-readable program instructions thereon for causing a processor to perform operations.

[0081] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0082] The computer-readable program instructions described herein may be downloaded to each computing / processing device from a computer-readable storage medium, or may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0083] The computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider). In one or more exemplary embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuit to perform an aspect or operation.

[0084] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture containing instructions that implement aspects of the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams.

[0085] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0086] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible example implementations of systems, methods, and computer-readable media according to one or more exemplary embodiments. In this regard, each block in a flowchart or block diagram may represent a microservice, module, segment, or portion of an instruction set, comprising one or more executable instructions that implement the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those depicted in the figures. In one or more alternative exemplary embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0087] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual specialized control hardware or software code used to implement the systems and / or methods is not a limitation of one or more exemplary embodiments. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A computer-implemented method for verifying quality assurance for a plurality of software components having a software component type, comprising: The computer performing a quality assurance test on each software component of the plurality of software components to receive result data; processing the resulting data for each software component to extract metrics; receiving a quality gate configuration for the software component type, the quality gate configuration comprising at least one metrics gate; comparing the metrics for each software component based on the at least one metrics gate; Execute a process that outputs build results and the metrics based on the comparison of the metrics and the quality gate configuration. method.

2. if the comparison of the metric to the metric gate has a negative result, the result of the build is an indication that the build failed. The method of claim 1.

3. if the comparison of the metric to the metric gate has a positive result, the result of the build is an indication that the build was successful.

3. The method according to claim 1 or 2.

4. The quality gate configuration includes: a stage name identifier that may be used to identify the development stage at which the quality gate is being enforced; an enforcement level parameter that can be output as the result of the build if the metrics gate has the negative result; Equipped with 3. The method according to claim 1 or 2.

5. At least one of the metrics gates comprises: a metric name identifier that can be used to identify the type of metric being compared; and threshold parameters comprising a warning threshold and an error threshold, wherein if the warning threshold is met by the comparison, the result of the build includes specifying a warning, if the error threshold is met by the comparison, the result of the build includes specifying an error, and if the result of the build is neither a warning nor an error, the result of the build instead includes specifying success; a comparison type parameter indicating how the value of the metric should be compared to the threshold parameter. The method of claim 1.

6. outputting the results and metrics of the build; rendering a visualization of the results of the build, wherein a first style is rendered if the results include specifying a warning, a second style is rendered if the results include specifying an error, or a third style is rendered if the results alternatively include specifying success, wherein the first style, the second style, and the third style are different from one another. The method of claim 5.

7. 1. A computer-implemented method for managing a plurality of software components including at least a first software component, comprising: The computer A request to create a feature branch is received, branching the first software component; Building the branched first software component; Checking whether the first software component was built successfully; If the first software component is not successfully built, sending an error message; If the first software component is successfully built, publishing the built first software component as a first package; Searching for dependent software components of the plurality of software components that depend on the first software component; Branch each dependent software component, execute the process, method.

8. the dependent software components include at least a second software component, and branching each dependent software component includes branching the second software component; The computer updating the dependency of the branched second software component to be on the first package; Building the branched second software component; Checking whether the second software component is successfully built; If the second software component is not successfully built, sending an error message; If the second software component is successfully built, publishing the built second software component as a second package; Check whether the check of all the dependent software components has been successful, and execute the process. The method of claim 7.

9. The computer If the checks of all the dependent software components are successful, rebasing the branched first software component onto a main branch; Merging the branched first software component into the main branch; Building the merged first software component; publishing the merged first software component as a first main branch package; Searching for the dependent software component and executing the process; The method of claim 8.

10. The computer rebasing the branched second software component onto the main branch; updating the dependency of the branched second software component to be on the first main branch package; Merging the branched second software component into the main branch; Building the merged second software component; The method of claim 9 , further comprising: publishing the merged second software part as a second main branch package.

11. 1. An apparatus for verifying quality assurance for a plurality of software components having a software component type, the apparatus comprising: at least one memory storing computer-executable instructions; at least one processor; wherein at least one of the processors executes the computer-executable instructions to performing a quality assurance test on each software component of the plurality of software components to receive result data; processing the resulting data for each software component to extract metrics; receiving a quality gate configuration for the software component type, the quality gate configuration comprising at least one metrics gate; comparing the metrics for each software component based on at least one of the metrics gates; The apparatus is configured to perform a process that outputs build results and the metrics based on the comparison of the metrics and the quality gate configuration.

12. if the comparison of the metric to the metric gate has a negative result, the result of the build is an indication that the build failed.

12. The apparatus of claim 11.

13. if the comparison of the metric to the metric gate has a positive result, the result of the build is an indication that the build was successful.

13. Apparatus according to claim 11 or 12.

14. The quality gate configuration includes: a stage name identifier that may be used to identify the development stage at which the quality gate is being enforced; an enforcement level parameter that can be output as the result of the build if the metrics gate has the negative result; 13. The apparatus according to claim 11 or 12, comprising:

15. At least one of the metrics gates comprises: a metric name identifier that can be used to identify the type of metric being compared; and threshold parameters comprising a warning threshold and an error threshold, wherein if the warning threshold is met by the comparison, the result of the build includes specifying a warning, if the error threshold is met by the comparison, the result of the build includes specifying an error, and if the result of the build is neither a warning nor an error, the result of the build instead includes specifying success; a comparison type parameter indicating how the value of the metric should be compared to the threshold parameter; 13. The apparatus according to claim 11 or 12, comprising:

16. The at least one processor further executes the computer-executable instructions to: configured to output the results and the metrics of the build by rendering a visualization of the results of the build, wherein a first style is rendered if the results include specifying a warning, a second style is rendered if the results include specifying an error, or a third style is rendered if the results instead include specifying a success, and wherein the first style, the second style, and the third style are different from one another.

16. The apparatus of claim 15.

17. 1. An apparatus for managing a plurality of software components including at least a first software component, the apparatus comprising: at least one memory storing computer-executable instructions; at least one processor; wherein the at least one processor executes the computer-executable instructions to A request to create a feature branch is received, branching the first software component; Building the branched first software component; Checking whether the first software component was built successfully; If the first software component is not successfully built, sending an error message; If the first software component is successfully built, publishing the built first software component as a first package; Searching for dependent software components of the plurality of software components that depend on the first software component; branching each of the dependent software components and further executing the process; Device.

18. the dependent software components include at least a second software component, and branching each dependent software component includes branching the second software component; At least one of the processors further executes the computer-executable instructions; updating the dependency of the branched second software component to be on the first package; Building the branched second software component; Checking whether the second software component is successfully built; If the second software component is not successfully built, sending an error message; If the second software component is successfully built, publishing the built second software component as a second package; Check whether the checks of all the dependent software components have been successful.

18. The device of claim 17, configured to:

19. If all of the dependent software components are checked successfully, the at least one processor further executes the computer-executable instructions to: rebasing the branched first software component onto a main branch; Merging the branched first software component into a main branch; Building the merged first software component; publishing the merged first software component as a first main branch package; configured to execute a process for searching for the dependent software component; 20. The apparatus of claim 18.

20. At least one of the processors further executes the computer-executable instructions to: rebasing the branched second software component onto the main branch; updating the dependency of the branched second software component to be on the first main branch package; Merging the branched second software component into the main branch; Building the merged second software component; and executing a process to publish the merged second software component as a second main branch package.

20. The apparatus of claim 19.

Images