Apparatus and method for software development collaboration
Through computer-executed quality assurance tests and quality gate composition comparison methods, the quality assurance automation and standardization problems across multiple software components in software development are solved, and the high quality and consistency of software components are achieved.
Patent Information
- Application Number
- CN202411786599.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-12-07
- Filing Date
- 2024-12-06
- Publication Date
- 2025-06-10
AI Technical Summary
The prior art is difficult to automate and standardize quality assurance across multiple software components in software development, especially in cases of complex dependencies, and it is difficult to ensure that all software components achieve specific quality metrics.
Through a computer-executed method, quality assurance tests are performed on multiple software components, metrics are extracted, and quality gate compositions are used to compare, and construction results and measurements are output to ensure that software components comply with standardized quality assurance methods.
Standardized quality assurance across multiple software components is achieved, ensuring that all software components comply with specific quality metrics, and improving the quality and consistency of software development.
Smart Images
Figure CN120122992A_ABST
Abstract
Description
Technical Field
[0001] Devices and methods consistent with exemplary embodiments of the present disclosure relate to quality gates for software component management. 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 component may implement different functions and may be referred to as a "software component". Software components may depend on other software components (i.e., dependencies may exist). When developing a software project, multiple software components may be developed in parallel to enable faster and more robust development.
[0003] In 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 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 enables the developer to test the new branch, which may include any new features the new branch may include. After changes to the new branch, they may 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 specific quality metrics.
[0005] In related art, a situation may arise where 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 accessible to all developers involved (e.g., there may be software components that may have closed source code). In other words, there may be "boundaries" between different software components based on ownership. Therefore, it may be difficult for developers to test whether a software component with an updated version / branch can function through a dependent software component with closed source code, i.e., what kind of effects the updated software component may have in the entire software component stack (e.g., the software component and its dependencies).
[0006] Furthermore, related art may describe using quality assurance tools for software development, but does not describe automating and standardizing the use of quality assurance tools across multiple software components. In particular, there is no method to ensure that all specified software components in a project meet specific quality metrics.
[0007] Therefore, there is a need for version control to manage multiple software components and their dependencies, and also to enforce quality standards through a standardized method across multiple software components. Summary of the Invention
[0008] According to one or more exemplary embodiments, apparatuses and methods are provided for software development collaboration. In particular, software components (which can each implement different functions) can be used. A computer-executable method can be provided for applying a quality gate to a plurality of software components of a given type. In particular, the computer performs a quality assurance test on each of the plurality of software components to receive result data, processes the result data to extract metrics (e.g., any method for determining the quality of a software component), receives a quality gate configuration for the given software component type, the quality gate configuration including metric gates that can be used to compare the requirements specified in the metric gates with the metrics. Thus, the result of the comparison and the metrics themselves can be output to the user. Accordingly, the quality gate ensures that a standardized quality assurance method is applied across the software components of a given software component type and that the user can easily access the results of the quality assurance tests for the quality gate.
[0009] According to an embodiment, a computer-executable method can be provided for validating quality assurance for a plurality of software components having a software component type. The computer performs the following processing. The computer performs a quality assurance test on each of the plurality of software components to receive result data, processes the result data for each software component to extract metrics, receives a quality gate configuration having at least one metric gate for the software component type, compares the metrics for each software component based on the at least one metric gate, and outputs the build result and the metrics based on the comparison and the quality gate configuration.
[0010] In the case where the comparison of the metric with the metric gate has a negative result, the build result can indicate a build failure. In the case where the comparison of the metric with the metric gate has a positive result, the build result can indicate a build success.
[0011] The quality gate configuration can include: a phase name identifier that can be used to identify the development phase in which the quality gate is applied; and an execution level parameter that can be output as the build result in the case where the metric gate has a negative result.
[0012] The at least one metric gate can include: a metric name identifier that can be used to identify the type of metric being compared; a threshold parameter having a warning threshold and an error threshold, where in the case where the warning threshold is satisfied by the comparison, the build result includes a specified warning, and in the case where the error threshold is satisfied by the comparison, the build result includes a specified error, and in the case where the build result is neither a warning nor an error, the build result alternatively includes a specified success; and a comparison type parameter indicating how the value of the metric should be compared with the threshold parameter.
[0013] The output build results and metrics can also include a visual rendering of the build results. When the results include a specified warning, a first style is rendered; when the results include a specified error, a second style is rendered; or when the results alternatively include a specified success, a third style is rendered. 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 multiple 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 of the exemplary embodiment can include: creating a new functional branch; branching from the parent software component to each of the dependent software components under the dependent software components; and merging the functional branch back into the main branch again. Each software component can be built and published by including a test that can build the software component without errors during branching. Therefore, the functional branch can be used to test and build the entire software component stack.
[0015] According to an embodiment, a computer-executed method for managing multiple 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, sends an error message if the built first software component is not successful, publicly discloses the built first software component as a first software package if the built first software component is successful, retrieves the dependent software components among the multiple software components that depend on the first software component, and branches each of the dependent software components.
[0016] The dependent software components can at least include a second software component. Branching each of the dependent software components includes branching the second software component. The computer updates the dependencies of the branched second software component to target the first software 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 discloses the built second software component as a second software package if the built second software component is successful, and checks whether the checks of all the dependent software components are successful.
[0017] If the checks of all the dependent software components are successful, the computer rebases the branched first software component to target the main branch, merges the branched first software component into the main branch, builds the merged first software component, publicly discloses the merged first software component as a first main branch software package, and retrieves the dependent software components.
[0018] The computer rebases the second software component after branching so that it targets the main branch, updates the dependencies of the second software component after branching so that it targets the first main branch software package, merges the second software component after branching into the main branch, builds the merged second software component, and publishes the merged second software component as the second main branch software package.
[0019] The additional solution part is described in the following description, becomes clear in part according to the description, or can be implemented by implementing the embodiments presented in this disclosure. Brief Description of the Drawings
[0020] The functions, solutions, and advantages of specific preferred embodiments of the present disclosure are described below with reference to the accompanying drawings, in which the same reference numerals denote the same elements.
[0021] Figure 1 It is a diagram of exemplary components of an apparatus of an exemplary embodiment.
[0022] Figure 2 It is a block diagram of a quality gate constitution document of one or more exemplary embodiments.
[0023] Figure 3 It is a flowchart showing a method of applying quality assurance testing to a software component of one or more exemplary embodiments.
[0024] Figure 4A It is a flowchart showing a method of branching and merging a feature branch for a software component of one or more exemplary embodiments.
[0025] Figure 4B It is a flowchart showing a method of branching and merging a feature branch for a software component of one or more exemplary embodiments.
[0026] Figure 5 It is a flowchart showing an example of creating a feature branch for a software component having dependencies of one or more exemplary embodiments. Detailed Description of the Invention
[0027] The following detailed description of exemplary embodiments refers to the accompanying drawings. The present disclosure provides examples and explanations, but is not intended to be inclusive, nor is it intended to limit more than one exemplary embodiment to the exact form disclosed. Modifications and variations are possible in view of the present disclosure, or can be learned from the implementation of more than one exemplary embodiment. Moreover, one or more functions or components of one exemplary embodiment can be incorporated into another exemplary embodiment (or one or more functions of another exemplary embodiment), or can be combined with it. Moreover, it can be understood that in the flowcharts and descriptions of actions provided in this specification, one or more actions can be omitted, one or more actions can be added, one or more actions can be performed simultaneously (at least in part), and the order of one or more actions can be switched.
[0028] Obviously, the exemplary embodiments of the systems and / or methods and / or non-transitory computer-readable storage media described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code for implementing the system and / or method is not limited to more than one exemplary embodiment. Therefore, the actions and behaviors of the system and / or method and / or non-transitory computer-readable storage media are described in this specification without reference to specific software code. It can be understood that the software and hardware can be designed to implement the system and / or method based on the description in this specification.
[0029] Even if a specific combination of functions is recited in the claims and / or disclosed in this specification, it is not intended that this combination limit the disclosure of possible exemplary embodiments. In fact, most of these functions can be combined by methods not specifically recited in the claims and / or not disclosed in this specification. Each of the dependent claims listed below can only directly depend on one claim, but the disclosure of possible exemplary embodiments includes each dependent claim combined with all the other claims in the set of claims.
[0030] Unless otherwise explicitly stated, elements, acts, or instructions used in this specification should not be construed as important or essential. Additionally, the articles "a" and "an" used in this specification are intended to include more than one item and can be used interchangeably with "more than one". In the case where only one item is intended, the term "one" or the like is used. Further, the terms "has", "have", "having", "include", "including", or similar terms used in this specification are intended to be open-ended terms. Moreover, unless otherwise explicitly stated, the phrase "based on" is intended to mean "at least partially based on". Also, 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.
[0031] The term "software component" used in this specification refers to each component or unit of software that can implement more than one function. The software component can depend on other software components. Multiple software components of the same software component type can also be provided. Specifically, the software component type can indicate what the software component intends to do (e.g., SDK (Software Development Kit), integration, system testing, etc.). Each software component type can have criteria (e.g., ISO standards) that the software component needs to pass in order to pass a specific development stage (e.g., the coverage stage where the user still only intends to collect and evaluate code coverage metrics). The criteria can be evaluated from the perspective of metrics. According to some embodiments, each software component can have an identifier that includes a version number and a function name, but is not limited thereto.
[0032] Figure 1 is a diagram of exemplary components of the software development device 100. As Figure 1 shown, the software development device 100 can 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.
[0033] The bus 110 includes components that enable communication among the components of the software development device 100. The processor 120 can be implemented by hardware, firmware, or a combination of hardware and software. The processor 120 can 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 other types of processing components. In more than one exemplary embodiment, the processor 120 includes more than one processor programmable to perform functions. The memory 130 includes random access memory (RAM), read only memory (ROM), and / or other types of dynamic or static storage devices (such as flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by the processor 120.
[0034] The storage component 140 stores information and / or software associated with the operation and use of the software development device 100. For example, the storage component 140 can include a hard disk (such as a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette tape, a magnetic tape, and / or other types of non-transitory computer-readable media, together with corresponding drives. The input component 150 includes components that enable the software development device 100 to receive information via user input, etc. (such as a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Further or alternatively, the input component 150 can include sensors that sense information (such as a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 160 includes components that provide output information from the software development device 100 (such as a display, a speaker, and / or more than one light emitting diode (LED)).
[0035] The communication interface 170 includes components such as a transceiver 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, etc. (such as a transceiver and / or separate receivers and transmitters). The communication interface 170 can enable the software development device 100 to receive information from other devices and / or provide information to other devices. For example, the communication interface 170 can include 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 interfaces of the like, but is not limited thereto.
[0036] The software development device 100 may perform one or more of the exemplary processes described in this specification. According to one or more exemplary embodiments, the software development device 100 may perform the process in response to the processor 120 executing software instructions stored in a non-transitory computer-readable medium such as the memory 130 and / or the storage component 140. The computer-readable medium is determined in this specification as a non-transitory memory device. The memory device includes storage space within a single physical storage device or storage space across multiple physical storage devices.
[0037] The software instructions may be read into the memory 130 and / or the storage component 140 from other computer-readable media or from other devices via the communication interface 170. The software instructions stored in the memory 130 and / or the storage component 140 may cause the processor 120 to perform one or more of the processes described in this specification when executed.
[0038] Further or alternatively, hardwired circuitry may be used in place of or in combination with the software instructions to perform one or more of the processes described in this specification. Accordingly, one or more of the exemplary embodiments described in this specification are also not limited to any particular combination of hardware circuitry and software.
[0039] Figure 1 The number and configuration of the components shown are provided as an example. In fact, Figure 1 compared to what is shown, the software development device 100 may include additional components, fewer components, different components, or components with a different configuration. Further or alternatively, a set of components (e.g., one or more components) of the software development device 100 may perform one or more of the functions of the functions described as being performed by other sets of components of the software development device 100.
[0040] Quality Gate
[0041] Figure 2 is a block diagram of a quality gate configuration file 200 of one or more exemplary embodiments. The quality gate configuration file 200 may include a metric gate 210, a phase name identifier (ID) 220, and an execution level parameter 230.
[0042] The metric gate 210 can formulate more than one rule for implementing whether the constructed software component passes the quality assurance test. The metric gate 210 can include: a metric name identifier (ID) 211, which can be used to uniquely identify each metric gate; a threshold parameter 212, which can be used to set a specific value for the pass / fail of the quality assurance test; and a comparison type parameter 213, which can be used to set how to compare the result of the quality assurance test with the threshold parameter 212. The threshold parameter 212 can also be determined by: a warning threshold 212-1, which can set the threshold for giving a warning result; and an error threshold 212-2, which can set the threshold for giving an error result.
[0043] For example, the metric gate 210 can check whether the quality assurance test pass result (e.g., a positive result) is strictly a value of 0.9 or more. In the case where the result is less than 0.9, it can represent an error for the build (e.g., a negative result). In the case where it is sufficiently more than 0.9, it can represent success for the build. In the case where it is exactly 0.9, it can represent a warning for the build.
[0044] In this case, the threshold parameter 212 can include a warning threshold 212-1 of 0.91 and an error threshold 212-2 of 0.90. The comparison type parameter 213 can be set to "greater", and as a result, in the metric, in order to bring a positive (success) result for the build, it should be checked whether the metric exceeds the threshold parameter. Nevertheless, it should be understood that various comparison methods can be used in the metric gate 210.
[0045] The phase name ID 220 can be included in the quality gate constitution file 200 to identify the specific development phase in which the quality gate is implemented. Different quality gates can be applied in different development phases, and this can be facilitated by using the phase name identifier. For example, in the case where the phase name ID 220 is "coverage", the quality gate can be applied only in the code coverage phase. Nevertheless, it should be understood that any appropriate syntax can be used.
[0046] The implementation level parameter 230 can be used to specify what the output / result of the build should be in the case where the metric gate 210 has a negative result. For example, in the case where it is set to "fail", the build result can be output as "fail" in the case where the metric 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 this output, and the syntax can be changed according to the implementation solution.
[0047] Figure 3 Is a flowchart of a method 300 for applying a quality assurance test to a software component representing more than one exemplary embodiment. It should be understood that it can be used as Figure 2The quality gate constitution document shown is the same constitution document 200.
[0048] In operation S310, quality assurance tests can be performed on each 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. Then, the results of the quality assurance tests can be obtained.
[0049] In operation S320, the results of the quality assurance tests can be processed to obtain metrics. In particular, the results of the quality assurance tests are sometimes not necessarily in a format that can be easily evaluated as a metric. Therefore, in some embodiments, the results of the quality assurance tests can be processed (e.g., parsed) to obtain quality metrics.
[0050] In operation S330, a quality gate constitution (e.g., the quality gate constitution document 200 as shown and described above) can be obtained for each software component type. According to some embodiments, this can include sending a request to obtain a file and a response including the file. Figure 2 Shown, the quality gate constitution document 200 as described above). According to some embodiments, this can include sending a request to obtain a file and a response including the file.
[0051] In operation S340, the metrics for each software component can be compared using the metric gates (e.g., metric gate 210) from the quality gate constitution document. In particular, the quality gate can be applied to compare the metrics for each software component using metric gate 210. Negative results related to the comparison using metric gate 210 can be used to output a representation of a build failure, and positive results related to the comparison can be used to obtain a representation of a build success. Nevertheless, it should be understood that the output of the results can vary according to the constitution of metric gate 210 (as described above). Although the example has been described using one metric gate 210, it should be understood that multiple metric gates can be used according to a particular implementation.
[0052] In operation S350, the result of the build can be output to the user together with the metrics themselves. This can be done based on a comparison using the metric gates in the quality gate constitution document 200 and any additional settings.
[0053] According to an embodiment, the output (e.g., in the case where the output is for a graphical user interface or a dashboard) may include a part of the visual scheme. For example, a user interface (GUI) may provide a build summary, the current development stage, and the build status of software components. According to an embodiment, visual rendering of results and metrics may be performed. For example, the metrics themselves may be enumerated in any suitable format (such as a list, a chart, etc.). The results may also have different visual styles depending on what the results are. For example, "warning", "success", "failure" may correspond to different visual styles. According to a part of the embodiments, the visual style may be different colors (e.g., warning may correspond to yellow, success may correspond to green, failure may correspond to red). In this example, colors may be used to emphasize a specific part of the user interface or may change the color of the text, etc. The above example of the user interface is only an example of how a user interface utilizing quality gates may be implemented, and it should be understood that any suitable method of visualizing results and metrics may be applied.
[0054] Based on the above embodiments, quality metrics are collected from each software component, and quality gates are applied across the software components, whereby the quality metrics required for passing the build can be standardized. Therefore, standardization of quality assurance can be achieved.
[0055] Feature branch
[0056] Figure 4A and Figure 4B is a flowchart of a method 400 for branching and merging feature branches for software components, representing one or more exemplary embodiments. Method 400 may be executed when receiving an instruction to create feature branches for a plurality of software components (SP). According to an embodiment, the instruction may be initiated by an application developer.
[0057] Referring to Figure 4A , in action S401, a branch of the first software component may be created. In particular, the branch may be created from the main branch. This step may be performed by an application developer. For example, when a developer provides their own changes to an application, the developer may use their software development interface to open a new feature branch.
[0058] In action S402, the branched software component may be built (e.g., compiled), and then tested subsequently. For example, this may include performing tests such as quality assurance tests and referring to Figure 3 using method 300 as described above. It should be understood that this may be automatically performed through continuous integration (CI) automation.
[0059] In operation S403, the result of the test can be automatically verified. In the case of a build failure, the entire process can be stopped. According to some embodiments, this can include sending an error message or a similar message to indicate to the user that the build was not successful. Alternatively, in the case of a successful build, in operation S404, the process can proceed to publish the built first software component as a first software package.
[0060] In operation S405, then, the process can retrieve dependent software components that depend on the first software component and repeatedly (e.g., loop) through the same branching process for each dependent software component. 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 also depend on the first software component.
[0061] In operation S406, a second software component that depends on the first software component is found, and thus, the second software component can be branched.
[0062] In operation S407, the dependencies of the branched second software component can be updated to target the first published software package.
[0063] In operation S408, the same (as in operation S402) build and test process can be performed on the branched second software component.
[0064] In operation S409, the same (as in operation S403) verification process can be performed on the branched second software component. That is, only if the second build is successful, in operation S410, the built second software component can be published as a second software package; otherwise, the entire process can be stopped. The process of branching the second software component can be repeated (i.e., operations S406 - S410 can be looped) for all dependent software components (e.g., the third, fourth, nth software components) when operation S410 is completed. Thus, the process can verify whether the verification / test of all dependent software components is successful and repeat the above process based on this verification.
[0065] According to some embodiments, it should be understood that during the test / verification process of whether the build is successful, if it is determined that any correction to the codebase is required, the developer can manually correct the code in the branch and then trigger the build and test actions again.
[0066] Referring to Figure 4B , in operation S411, based on as Figure 4AAfter the actions shown and after the tests for verifying all dependencies are successful, the feature branch can be merged into the main branch. Specifically, the first software component after branching as described with reference to Figure 4A can be rebased against the main branch. Then, the first software component after branching can be merged into the main branch again. Then, in operation S412, the merged first software component can be built and made publicly available as a first main branch software package.
[0067] After the first main branch software package is made publicly available, in operation S413, dependent software components can be retrieved. In particular, the second software component after branching can be rebased against the main branch. Then, in operation S414, the dependencies of the second software component after branching can be updated against the first main branch software package. In operation S415, the second software component after branching can be merged into the main branch, and then, in operation S416, the merged second software component can be built and made publicly available as a second main branch software package. The steps related to the second main branch software package can be repeated for the remaining dependent software components after branching (i.e., operations S414 - S416 can be looped).
[0068] It should be understood that in cases where the feature branch of a software component does not include any additional changes to the source code at all, in some embodiments, no additional actions by the developer are required, and only the version of the dependencies of the software component is updated. In other embodiments, in cases where the rebase fails due to previous changes to the main branch, the developer may need to manually rebase the feature branch in order to fix conflicts.
[0069] Figure 5 is a flowchart of an exemplary method 500 for creating a feature branch for a software component with dependencies, representing one or more exemplary embodiments.
[0070] With reference to Figure 5 , base 510 is a first software component. Core 520 is a second software component that depends on base 510. Application 530 is a third software component that depends on core 520. It should be understood that base 510 can be the same as the first software component described with reference to Figure 4A and Figure 4B , and core 520 is a second software component that can be the same as the second software component described with reference to Figure 4A and Figure 4B . Application 530 can be the same as one of the dependent software components described above with reference to Figure 4A and Figure 4B .
[0071] Figure 5Shows how the branching steps in the left column go down the list of dependencies from the parent software component, starting from the base 510 to the core 520, and then down to the application 530. After the branching and disclosure of the application 530 in the final package are completed, the merge steps in the right column also go down the list of dependencies from the parent software component.
[0072] Refer to Figure 5 The steps described in the branching and merging steps in can be the same as the steps specified in Figure 4A and Figure 4B It should also be understood that the version numbers and software component names can be arbitrarily selected, and any appropriate naming and version numbering scheme can be applied.
[0073] In action S511, a feature branch of the base 510 is created ( Figure 5 The feature branch in is represented by the "dev" version), and then, in action S512, it is built and disclosed.
[0074] In action S521, a feature branch of the core 520 is created.
[0075] In action S522, the dependencies of the feature branch of the core 520 are updated to the feature branch of the base 510, and then, in action S523, the feature branch of the core 520 is built and disclosed.
[0076] In action S531, a feature branch of the application 530 is created.
[0077] In action S532, the dependencies of the feature branch of the application 530 are updated to the feature branch of the core 520, and then, in action S533, the feature branch of the application 530 is built and disclosed.
[0078] In action S513, the feature branch of the base 510 is rebased and merged into the master branch. Then, in action S514, the master branch of the base 510 is built and disclosed.
[0079] In action S524, the feature branch of the core 520 is rebased and merged into the master branch.
[0080] In action S525, the dependencies of the master branch of the core 520 are updated to the master branch of the base 510, and then, in action S526, the master branch of the core 520 is built and disclosed.
[0081] In action S534, the feature branch of the application 530 is rebased and merged into the master branch.
[0082] In operation S535, the dependencies of the main branch of application 530 are updated to the main branch for core 520, and then, in operation S536, the main branch of application 530 is built and made public.
[0083] According to Figure 5 the above example in, functional branches can be created for multiple software components and their dependencies, and then rebased / merged back into the main branch again.
[0084] When creating functional branches, each software component is branched, whereby the entire software component stack can be easily tested and built without direct access to the source code for each dependent software component. Thus, even when a dependent software component is closed source, that dependent software component can still be used when testing the parent software component. Therefore, testing can be easily performed for each functional branch.
[0085] The foregoing disclosure provides examples and descriptions, but is not intended to be inclusive nor to limit one or more exemplary embodiments to the precise forms disclosed. Modifications and variations are possible in light of this disclosure, or can be learned from the practice of one or more exemplary embodiments.
[0086] One or more exemplary embodiments may relate to systems, methods, and / or computer-readable media at a level of detail of technology with any integration possibilities. Moreover, one or more of the above components can be stored in a computer-readable medium and implemented as instructions 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 (or media), in which there are computer-readable program instructions for causing a processor to perform operations.
[0087] A computer-readable storage medium can be a tangible device that holds and stores 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, without limitation. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: namely, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card or raised structures in a groove recording instructions, and any suitable combination of the foregoing. A computer-readable storage medium as used in this specification should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.
[0088] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to various computing / processing devices, or can 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 can include a copper transmission cable, an optical transmission fiber, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions for storage to a computer-readable storage medium in each computing / processing device.
[0089] The computer-readable program code / instructions for performing an action can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, 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 similar programming languages; and procedural programming languages such as the "C" programming language or the like. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or can be executed entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network including a local area network (LAN) or a wide area network (WAN), or can make a connection to an external computer (e.g., via 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 for a solution or an action.
[0090] The computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine, such that the instructions executed via the processor of the computer or other programmable data processing device generate a unit that implements the function / behavior specified in the block or blocks of the flowchart and / or block diagram. The computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct a computer, a programmable data processing device, and / or other devices to function in a particular manner, such that the instructions stored in the internal computer-readable storage medium embody a manufactured article that includes instructions for a solution that implements the function / behavior specified in the block or blocks of the flowchart and / or block diagram.
[0091] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device to perform a series of operational steps on the computer, other programmable device, or other device to generate a computer-implemented process, such that the instructions executed on the computer, other programmable device, or other device implement the function / behavior specified in the block or blocks of the flowchart and / or block diagram.
[0092] 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 for more than one exemplary embodiment. In this regard, each block in the flowchart or block diagram may represent a part of a microservice, module, segment, or instruction that includes 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 with different configurations than those depicted in the figures. In more than one alternative exemplary embodiment, the functions recited in the blocks may occur in an order different from that depicted in the figures. For example, two consecutive blocks shown may actually be executed simultaneously or substantially simultaneously, or the blocks may be executed in the reverse order depending on the associated functionality. It should also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware that performs the specified functions or actions or a combination of dedicated hardware and computer instructions.
[0093] Obviously, the systems and / or methods described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code for implementing the systems and / or methods is not limited to more than one exemplary embodiment. Therefore, it can be understood that the operations and behaviors of the systems and / or methods are described in this specification without reference to specific software code, and the software and hardware can be designed to implement the systems and / or methods based on the description in this specification. The software for implementing the systems and / or methods described in this specification can be provided as a computer program product.
Claims
1. A computer-implemented method for verifying quality assurance of a plurality of software components having a software component type, wherein: The computer performs the following processing: performing quality assurance testing on each of the plurality of software components to receive result data, processing the result data to extract metrics for each software component, receiving a quality gate composition for the software component type, the quality gate composition having at least one metric gate, comparing the metrics for each software component based on the at least one metric gate, Based on the comparison of the metrics and the quality gate formation, the results of the build and the metrics are output.
2. The method according to claim 1, wherein: In the event that the comparison of the metric to the metric gate has a negative result, the result of the build is to indicate that the build failed.
3. The method according to claim 1 or 2, wherein: In the event that the comparison of the metric to the metric gate has a positive result, the result of the build is indicative of a success of the build.
4. The method according to claim 1 or 2, wherein: The quality gate structure comprises: The phase name identifier, which can be used to identify the development phase for which the quality gate was applied; and An execution level parameter, which can be output as the result of the constructing if the metric gate has the negative result.
5. The method according to claim 1, wherein: At least one of the metrology gates comprises: A metric name identifier that can be used to identify the type of metric being compared; a threshold parameter, including a warning threshold and an error threshold, wherein when the warning threshold is satisfied by the comparison, the result of the build includes a specified warning, when the error threshold is satisfied by the comparison, the result of the build includes a specified error, and when the result of the build is neither a warning nor an error, the result of the build instead includes a specified success; as well as A comparison type parameter indicating how the value of the metric should be compared to the threshold parameter.
6. The method according to claim 5, wherein: Outputting the results and the metrics of the build also includes performing a visual rendering of the results of the build, rendering a first style if the results include a specified warning, rendering a second style if the results include a specified error, or rendering a third style if the results alternatively include a specified success, the first style, the second style, and the third style being different from each other.
7. A computer-implemented method for managing a plurality of software components including at least a first software component, wherein: The computer performs the following processing: Receive requests to create feature branches, branching the first software component, Building the first software component after branching, Check whether the first software component is constructed successfully, If the first software component is not successfully constructed, an error message is sent, If the first software component is constructed successfully, publishing the constructed first software component as a first software package, Retrieving a dependent software component among the plurality of software components that is dependent on the first software component, Branch each dependent software component.
8. The method according to claim 7, wherein: The dependent software components include at least a second software component, and causing each of the dependent software components to branch includes causing the second software component to branch, The computer performs the following processing: updating the dependency of the second software component after branching so that it targets the first software package, Building the second software component after branching, Check whether the second software component is constructed successfully, If the second software component is not successfully constructed, an error message is sent, If the second software component is constructed successfully, publishing the constructed second software component as a second software package, Verify whether all the dependent software components have been successfully verified.
9. The method according to claim 8, wherein: The computer performs the following processing: In case all the dependent software components are successfully verified, rebasing the first software component after branching to target the trunk branch, Merging the first software component after branching into the main branch, constructing the first combined software component, The merged first software component is made public as a first trunk branch software package, The dependent software components are retrieved.
10. The method according to claim 9, wherein: The computer also performs the following processing: rebasing the second software component after branching so as to make it target the trunk branch, updating the dependency of the second software component after branching so as to make it target the first trunk branch software package, Merging the branched second software component into the main branch, constructing the combined second software component, The merged second software component is published as a second trunk branch software package.
11. An apparatus for verifying quality assurance of a plurality of software components having a software component type, wherein: The device comprises: at least one memory storing computer executable instructions; and at least one processor, At least one of the processors is configured to execute the computer executable instructions to perform the following processes: performing quality assurance testing on each of the plurality of software components to receive result data, processing the result data to extract metrics for each software component, receiving a quality gate configuration having at least one metric gate for the software component type, comparing the metrics for each software component based on at least one of the metrics gates, Based on the comparison of the metrics and the quality gate formation, the results of the build and the metrics are output.
12. The device according to claim 11, wherein In the event that the comparison of the metric to the metric gate has a negative result, the result of the build is to indicate that the build failed.
13. The device according to claim 11 or 12, wherein: In the event that the comparison of the metric to the metric gate has a positive result, the result of the build is indicative of a success of the build.
14. The device according to claim 11 or 12, wherein: The quality gate structure comprises: The phase name identifier, which can be used to identify the development phase for which the quality gate was applied; and An execution level parameter, which can be output as the result of the constructing if the metric gate has the negative result.
15. The device according to claim 11 or 12, wherein: At least one of the metrology gates comprises: A metric name identifier that can be used to identify the type of metric being compared; a threshold parameter, including a warning threshold and an error threshold, wherein when the warning threshold is satisfied by the comparison, the result of the build includes a specified warning, when the error threshold is satisfied by the comparison, the result of the build includes a specified error, and when the result of the build is neither a warning nor an error, the result of the build instead includes a specified success; as well as A comparison type parameter indicating how the value of the metric should be compared to the threshold parameter.
16. The device according to claim 15, wherein: The at least one processor is further configured to execute the computer-executable instructions to output the results of the build and the metrics by performing a visual rendering of the results of the build, rendering a first style if the results include a specified warning, rendering a second style if the results include a specified error, or rendering a third style if the results alternatively include a specified success, the first style, the second style, and the third style being different from each other.
17. A device for managing a plurality of software components including at least a first software component, wherein: The device comprises: at least one memory storing computer executable instructions; and at least one processor, The at least one processor executes the computer executable instructions to further perform the following processes: Receive requests to create feature branches, branching the first software component, Building the first software component after branching, Check whether the first software component is constructed successfully, If the first software component is not successfully constructed, an error message is sent, If the first software component is constructed successfully, publishing the constructed first software component as a first software package, Retrieving a dependent software component among the plurality of software components that is dependent on the first software component, Branching is performed on each of the dependent software components.
18. The device according to claim 17, wherein: The dependent software components include at least a second software component, and branching each of the dependent software components includes branching the second software component. At least one of the processors is further configured to execute the computer executable instructions to perform the following processes: updating the dependency of the second software component after branching so that it targets the first software package, Building the second software component after branching, Check whether the second software component is constructed successfully, If the second software component is not successfully constructed, an error message is sent, If the second software component is constructed successfully, publishing the constructed second software component as a second software package, Verify whether all the dependent software components have been successfully verified.
19. The device according to claim 18, wherein: In the case that the verification of all the dependent software components is successful, at least one of the processors is further configured to execute the computer executable instructions to perform the following processing: rebasing the first software component after branching to target the trunk branch, Merge the first software component after branching into the main branch, constructing the first combined software component, The merged first software component is made public as a first trunk branch software package, The dependent software components are retrieved.
20. The device according to claim 19, wherein At least one of the processors is further configured to execute the computer executable instructions to perform the following processes: rebasing the second software component after branching so as to make it target the trunk branch, updating the dependency of the second software component after branching so as to make it target the first trunk branch software package, Merging the branched second software component into the main branch, constructing the combined second software component, The merged second software component is published as a second trunk branch software package.