Device 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] Apparatuses and methods consistent with exemplary embodiments of the present disclosure relate to managing quality gates for software components.

Background Art

[0002] In the field of software development, tools such as version control and quality assurance enable multiple collaborating software developers to collaborate on a software project, which may include each developer working on individual components. Each individual component may implement different functions and may be referred to as a "software component". Software components may be dependent on other software components (i.e., may have dependencies). When deploying 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 wishes 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 a new version, a developer may create a new branch from the main branch. This may enable the developer to test the new branch, which may include any new features the new branch may contain. Changes to this new branch may later be merged back into the main branch.

[0004] Quality assurance tools may also typically be used in software development. Such tools may enable a user to evaluate whether a software component meets certain quality metrics.

[0005] In related technologies, situations may occur where multiple companies or entities in the supply chain are involved. As a result, the source code for each software component may not be easily accessible to all developers involved (for example, there may be software components that can have closed-source code). In other words, there may be a "boundary" between different software components depending on ownership. Therefore, it can 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, that is, what kind of effects a newer software component can have across the entire software component stack (for example, software components and their dependencies).

[0006] In addition, related technologies may describe the use of quality assurance tools for software development, but there is no description of automating and standardizing the use of quality assurance tools across multiple software components. In particular, there is no way to guarantee that all specified software components in a project achieve specific quality metrics.

[0007] Therefore, while it is also possible to enforce quality standards in a standardized manner across multiple software components, version control is necessary to manage multiple software components and their dependencies. 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 components (which are individual software components that can each implement different functions) can be used. A method executed by a computer for applying quality gates to multiple software components of a given type can be provided. In particular, the computer executes quality assurance tests on each software component of the multiple software components to receive result data, processes the result data to extract metrics (e.g., any means for determining the quality of a software component), receives a quality gate configuration for a given software component type, and the quality gate configuration includes a metrics gate that can be used to compare the requirements specified in the metrics gate with the metrics. Thus, the result of the comparison and the metrics themselves can be output to the user. Thus, the quality gate ensures that a standardized quality assurance method is implemented across each software component of a given software component type and that the user can easily access the results of the quality assurance tests against the quality gate.

[0009] According to an embodiment, a method executed by a computer for verifying quality assurance for multiple software components having a software component type can be provided. The computer performs the following processes. The computer executes quality assurance tests on each software component of the multiple software components to receive result data, processes the result data for each software component to extract metrics, receives a quality gate configuration with at least one metrics gate for the software component type, compares the metrics for each software component based on the at least one metrics gate, and outputs the build result and the metrics based on the comparison and the quality gate configuration.

[0010] If the comparison of metrics with the metrics gate has a negative result, the build result may indicate that the build has failed. If the comparison of metrics with the metrics gate has a positive result, the build result may indicate that the build has succeeded.

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

[0012] At least one metrics gate is a metrics name identifier that can be used to identify the type of metrics being compared, and a threshold parameter having a warning threshold and an error threshold, wherein when the warning threshold is met by the comparison, the build result includes specifying a warning, and when the error threshold is met by the comparison, the build result includes specifying an error, and when the build result is neither a warning nor an error, the build result instead includes specifying success, and a comparison type parameter indicating how the value of the metrics should be compared with the threshold parameter.

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

[0014] According to an exemplary embodiment, a functional branch including a plurality of software components can be implemented. The software components can have a hierarchy, and a parent software component can have dependent software components. The apparatus and method according to the exemplary embodiment can include creating a new functional branch, branching each software component downward from the parent software component to the dependent software components, and merging the functional branch back into the main branch. Each software component, when branched, can be built and published including a test that the software component can be built without errors. Thus, the functional branch can be used to test and build the entire software component stack.

[0015] According to an embodiment, a method executed by a computer for managing a plurality of software components including at least a first software component can be provided. The computer receives a request to create a functional branch, branches the first software component, builds the branched first software component, checks whether the built first software component is successful, if the built first software component is not successful, sends an error message, if the built first software component is successful, publishes the built first software component as a first package, searches for dependent software components of the plurality of software components dependent on the first software component, and branches each dependent software component.

[0016] A dependent software component may include at least a second software component. Branching each dependent software component includes branching the second software component. The computer updates the dependencies of the branched second software component to be for the first package, builds the branched second software component, checks whether the built second software component is successful, sends an error message if the built second software component is not successful, publicly releases the built second software component as the second package if the built second software component is successful, and checks whether the check of all dependent software components was successful.

[0017] If the check of all dependent software components was successful, the computer rebases the branched first software component to be for the main branch, merges the branched first software component into the main branch, builds the merged first software component, publicly releases the merged first software component as the first main branch package, and searches for dependent software components.

[0018] The computer rebases the branched second software component to be for the main branch, updates the dependencies of the branched second software component to be for the first main branch package, merges the branched second software component into the main branch, builds the merged second software component, and publicly releases the merged second software component as the second main branch package.

[0019] Additional aspects may be described in part in the following description and become apparent in part from the description or may be realized by the practice of the presented embodiments of the disclosure.

Brief Description of the Drawings

[0020] The functions, aspects, and advantages of specific preferred embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals indicate like elements.

Figure 1

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 5

Mode for Carrying Out the Invention

[0021] The following detailed description of the exemplary embodiments refers to the accompanying drawings. This disclosure provides examples and explanations, but is not intended to be comprehensive, nor is it intended to limit one or more exemplary embodiments to the exact forms disclosed. Modifications and variations are possible in view of this disclosure or can be learned from the implementation of one or more exemplary embodiments. Further, one or more functions or components of one exemplary embodiment can be incorporated into or combined with another exemplary embodiment (or one or more functions of another exemplary embodiment). Additionally, 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 be performed (at least partially) simultaneously, and the order of one or more operations may be switched.

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

[0023] Even if specific combinations of functions are recited in the claims and / or disclosed herein, such combinations are not intended to limit the disclosure to any exemplary embodiments that might be possible. Indeed, many of these functions may be combined in ways that are not specifically recited in the claims and / or not disclosed herein. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of any possible exemplary embodiments includes each dependent claim in combination with all the other claims in the set of claims.

[0024] Elements, acts, or instructions used herein should not be construed as important or essential unless specifically described as such. 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 “one” or similar terminology is used. Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “at least partially based on” unless specifically stated otherwise. Additionally, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood to include only A, only B, or both A and B.

[0025] As used herein, the term "software component" refers to an individual component or unit of software that can implement one or more functions. The software component may depend on other software components. A plurality of 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, for system testing, etc.). Each of the software component types may have a standard (e.g., ISO standard) that the software component needs to pass through in order to pass through a specific development stage (e.g., a coverage stage where the user still intends to collect and evaluate only code coverage metrics). The standard can be evaluated from the perspective of metrics. According to some embodiments, each software component may have an identifier, which may include, but is not limited to, a version number and a function name.

[0026] FIG. 1 is a diagram of exemplary components of a software development device 100. As shown in FIG. 1, the 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 among 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 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] The storage component 140 stores information and / or software related to the operation and use of the software development device 100. For example, the storage component 140, together with the corresponding drive, may include a hard disk (e.g., 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, a magnetic tape, and / or another type of non-transitory computer-readable medium. The input component 150 includes components (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone) that enable the software development device 100 to receive information via user input or the like. Additionally or alternatively, the 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. The 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 the software development device 100.

[0029] The communication interface 170 includes components such as a transceiver (e.g., a transceiver and / or separate receivers and transmitters) that enable the software development device 100 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 170 may enable the software development device 100 to receive information from and / or provide information to other devices. For example, the communication 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] The software development device 100 can perform one or more of the exemplary processes described herein. According to one or more exemplary embodiments, the software development device 100 can perform the process in response to the processor 120 executing software instructions stored by a non-transitory computer-readable medium such as the memory 130 and / or the storage component 140. The computer-readable medium is defined herein as a non-transitory memory device. The memory device includes a memory space within a single physical memory device or a memory space spanning multiple physical memory devices.

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

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

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

[0034] Quality Gate

[0035] Figure 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 execution level parameter 230.

[0036] The metrics gate 210 may define one or more rules for performing whether the built software components pass quality assurance tests. The metrics gate 210 may include a metrics name identifier (ID) 211 that may be used to uniquely identify each metrics gate, a threshold parameter 212 that may be used to set specific values for pass / fail of quality assurance tests, and a comparison type parameter 213 that may be used to set how to compare the results of quality assurance tests with the threshold parameter 212. The threshold parameter 212 may further be defined by a warning threshold 212-1 that may set a threshold for which a warning result is given, and an error threshold 212-2 that may set a threshold for which an error result is given.

[0037] For example, the metrics gate 210 may check whether the quality assurance test results in a value that is strictly 0.9 or greater for a pass 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 sufficiently exceeds 0.9, success may be indicated for the build. If it is exactly 0.9, a warning may be indicated for the build.

[0038] In this case, the threshold parameter 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", and as a result, the metrics should check whether the metrics exceed the threshold parameter in order to result in a positive (success) result for the build. Nevertheless, it should be understood that various comparison methods may be used in the metrics gate 210.

[0039] Stage name ID 220 is included in the quality gate configuration file 200 and can be used to identify a specific development stage at which the quality gate is implemented. Different quality gates can be applied at different development stages, which can be facilitated by using the stage name identifier. For example, if the stage name ID 220 is "Coverage", the quality gate can only be applied during the code coverage stage. Nevertheless, it should be understood that any suitable syntax can be used.

[0040] The enforcement level parameter 230 can be used to specify what the output / result of the build should be when the metrics gate 210 has a negative result. For example, if it is set to "Failure", the build result can be output as "Failure" when 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 the syntax can vary according to the implementation.

[0041] FIG. 3 is a flowchart diagram showing 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 can be used.

[0042] In operation S310, the quality assurance test can be executed for each software component of a plurality of software components to receive result data. Each software component can have its own software component type. This can be done using any suitable quality assurance tool considered appropriate by the software developer. Thereafter, the results of the quality assurance test can be obtained.

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

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

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

[0046] In operation S350, the results of the build can be output to the user along with the metrics themselves. This can be done based on the comparison using the metrics gate and any additional settings in the quality gate configuration file 200.

[0047] According to an embodiment, the output may include some visual aspects (e.g., if the output is for a graphical user interface or a dashboard). For example, the user interface (GUI) may provide an overview of the build, the current development stage, and the build status of software components. According to an embodiment, the visualization of results and metrics may be rendered. For example, the metrics themselves may be enumerated in any suitable format (e.g., a list, a chart, etc.). The results may also have different visual styles depending on what the results were. For example, "warning", "success", "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, it may be that colors are used to highlight specific parts of the user interface, or that the color of the text is changed, etc. The above example for the user interface is merely an example of how a user interface utilizing quality gates may be implemented, and it should be understood that any suitable method for visualizing results and metrics may be applied.

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

[0049] Feature branch

[0050] Figures 4A and 4B are flowchart diagrams showing a method 400 for branching and merging feature branches for software components according to one or more exemplary embodiments. The method 400 may be executed when instructions are received to create feature branches for a plurality of software components (SP). According to an embodiment, these instructions may be initiated by an application developer.

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

[0052] In operation S402, the branched software component can be built (e.g., compiled) and then tested. For example, this can include performing tests such as quality assurance tests and utilizing method 300 as described above with reference to FIG. 3. It should be understood that this can be automatically performed by continuous integration (CI) automation.

[0053] In operation S403, the test results can be automatically checked. If the build fails, the entire process can be stopped. According to some embodiments, this can 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, in operation S404, the process can proceed to publish the built first software component as a first package.

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

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

[0056] In operation S407, the dependencies of the branched second software component can be updated to be for the first public package.

[0057] In operation S408, a similar (similar to operation S402) build and test process can be performed on the branched second software component.

[0058] In operation S409, a similar (similar to operation S403) check process can be performed on the branched second software component. Only if the second build is successful, the built second software component can be published as the second package in operation S410, and otherwise, the whole process can be stopped. This process of branching the second software component can be repeated for all dependent software components (e.g., the third, fourth, nth software components) when operation S410 is completed (i.e., operations S406 - S410 can be looped). Therefore, the process can check whether the checks / tests of all dependent software components are successful and, based on this check, repeat the above process.

[0059] According to some embodiments, it should be understood that during the test / check process of whether the build is successful, if it is determined that any modification to the codebase is required, the developer can manually modify the code in the branch and then re - trigger the build and test operations.

[0060] Referring to FIG. 4B, in operation S411, after checking that all dependencies are successfully tested based on the operations as shown in FIG. 4A, the feature branch can be merged into the main branch. Specifically, the branched first software component as described with reference to FIG. 4A can be rebased to be for the main branch. Then, the branched first software component can be merged into the main branch again. The merged first software component can then be built and published as the first main branch package in operation S412.

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

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

[0063] FIG. 5 is a flowchart diagram showing an exemplary method 500 of creating a feature branch for a software component having dependencies according to one or more exemplary embodiments.

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

[0065] FIG. 5 shows how the dependency list starting from the base 510 and going down to the core 520 and then to the app 530 progresses downward from the parent software component for the branch steps in the left column. After the branching and publishing of the last package of the app 530 are completed, the merge step in the right column also progresses downward the dependency list from the parent software component.

[0066] The steps described with reference to the branching and merge steps in FIG. 5 may be similar to those specified in FIGS. 4A and 4B. It should also be understood that the version numbers and software component names are, for example, arbitrarily selected and any suitable naming and numbering scheme for names and versions may be applied.

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

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

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

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

[0071] In operation S532, the dependencies of the function branch of the application 530 are updated to be those with respect to the function branch of the core 520, and then the function branch of the application 530 is built and published in operation S533.

[0072] In operation S513, the function branch of the base 510 is rebased, and the function branch is merged into the master branch. Then, the master branch of the base 510 is built and published in operation S514.

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

[0074] In operation S525, the dependencies of the master branch of the core 520 are updated to be those with respect to the master branch of the base 510, and then the master branch of the core 520 is built and published in operation S526.

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

[0076] In operation S535, the dependencies of the master branch of the application 530 are updated to be those with respect to the master branch of the core 520, and then the master branch of the application 530 is built and published in operation S536.

[0077] According to the above example in FIG. 5, function branches are created for a plurality of software components and their dependencies and can be rebased / merged back into the master branch later.

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

[0079] The above disclosure provides examples and explanations, but is neither intended to be comprehensive nor to limit one or more exemplary embodiments to the exact form disclosed. Modifications and variations are possible in view of the present disclosure or can be learned from the practice of one or more exemplary embodiments.

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

[0081] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes, hereinafter, namely, 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 disks (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. A computer-readable storage medium as used herein should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0082] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or can be downloaded from 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 can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each respective computing / processing device.

[0083] The computer-readable program code / instructions for performing the operations can be written in assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, where the one or more programming languages include 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 can be executed fully on the user's computer, partially on the user's computer, executed as a stand-alone software package, executed partially on the user's computer and partially on a remote computer, or executed fully on a remote computer or server. In the latter scenario, the remote computer can 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 a connection to an external computer can be made (e.g., through the Internet using an Internet service provider). In one or more exemplary embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions by personalizing the electronic circuit using the state information of the computer-readable program instructions to perform an aspect or operation.

[0084] The computer-readable program instructions may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / acts specified in the blocks or block(s) of a flowchart and / or block diagram. The computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium storing the instructions contains an article of manufacture including instructions which implement the aspects of the functions / acts specified in the blocks or block(s) of a flowchart and / or block diagram.

[0085] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / acts specified in the blocks or block(s) of a flowchart and / or block diagram.

[0086] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible exemplary embodiments of systems, methods, and computer-readable media according to one or more exemplary embodiments. In this regard, each block in the flowchart or block diagram may represent a micro-service, module, segment, or part of an instruction that comprises one or more executable instructions for implementing the specified logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently compared to those depicted in the drawings. In one or more alternative exemplary embodiments, the functions recited in the blocks may occur without regard to the order and relationship depicted in the figures. For example, two blocks shown in succession may actually be executed simultaneously or substantially simultaneously, or the blocks may be executed in the reverse order depending on the related functionality. It should also be noted that each block of the block diagram and / or flowchart diagram, and combinations of blocks in the block diagram and / or flowchart diagram, may be implemented by a dedicated hardware-based system that performs the specified function or action 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 a combination of hardware and software. The actual dedicated 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 is understood that software and hardware may 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 parts having a software part type, comprising: The computer includes: performing quality assurance tests 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; Executing 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. 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 may be output as the result of the build if the metrics gate has the negative result; Equipped with The method according to claim 1 or 2.

5. At least one of the metrics gates comprises: a metric name identifier that may be used to identify the type of metric being compared; and 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 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 specifies success; and 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 the metrics of the build includes: 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, the first style, the second style, and the third style being distinct from one another. The method according to claim 5.

7. 1. A computer-implemented method for managing a plurality of software parts, including at least a first software part, comprising: The computer includes: Receives a request to create a feature branch, Branching the first software component; Building the branched first software part; Checking whether the first software component is successfully built; 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 includes: updating the dependency of the branched second software component to be on the first package; Building the branched second software part; 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 part as a second package; Check whether the check of all the dependent software components is successful; and execute a process. The method according to claim 7.

9. The computer includes: 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 part; publishing the merged first software part as a first main branch package; Searching for the dependent software component; executing a process; The method according to claim 8.

10. The computer includes: 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 part; 10. The method of claim 9, further comprising the step of: publishing the merged second software part as a second main branch package.

11. 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 quality assurance tests 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 said metrics for each software component based on at least one of said metrics gates; The apparatus is configured to perform a process that outputs a result of a build 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 may 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 may be used to identify the type of metric being compared; and 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 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 specifies 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, 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 a success, the first style, the second style, and the third style being distinct from one another.

16. The apparatus of claim 15.

17. 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 Receives a request to create a feature branch, Branching the first software component; Building the branched first software part; Checking whether the first software component is successfully built; 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; Further performing a process of branching each of the dependent software components; 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 part; 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 part as a second package; A process is executed to check whether the check of all the dependent software components is successful.

20. The apparatus of claim 17, configured to:

19. If all of the dependent software components are successfully checked, 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 part; publishing the merged first software part as a first main branch package; The dependent software component is configured to execute a process of 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 part; and executing a process to publish the merged second software part as a second main branch package.

20. The apparatus of claim 19.

Images