Software pipeline automatic detection method and device, equipment, medium and product thereof

Abstract

The application relates to a software pipeline automatic detection method and device, equipment, medium and product, the method comprising: starting a latest version of a check program; implementing check on each development branch submitted to a test environment by a user in a corresponding pipeline according to check configuration information by the check program, sending a notification message to the user of the corresponding development branch and interrupting the pipeline for merging the codes of all the development branches when the check fails; when the check passes, comparing a pre-release branch list with each development branch submitted to the test environment by the user, determining a difference branch list, obtaining an updated version of the development branch in the difference branch list, and making all the development branches constitute a legal branch set of a software project; and merging all the development branches in the legal branch set to obtain a code set. The application can automatically detect and troubleshoot during the assembly process of the pipeline of the software engineering on the development branch, and can improve the implementation efficiency of the software engineering.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to an automatic detection method for software pipelines and the corresponding apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] During the development process, to facilitate the maintenance and management of software project development branches, branch names are required to include specific identifiers that allow all developers to better understand the branch's content (e.g., feature branch type, developer, release date). Establishing a reasonable merging process standard ensures that new features pass through all stages of the production pipeline, guaranteeing stable and correct operation.

[0003] In process management, when multiple features are under development simultaneously, a development process is typically established to address collaboration issues and ensure a streamlined, assembly-line-like workflow. This process involves a series of steps, including development, integration testing, testing, acceptance testing, and deployment, to guarantee the orderly and timely release of features. These steps are all implemented through development branches. After a feature is developed, the code is merged into a specific branch and deployed to the development environment for integration testing. This process continues, deploying to a test environment for system debugging, then to a pre-release environment for acceptance testing, and finally, deploying to the production environment according to the deployment plan.

[0004] Currently, these standards and process controls are all done manually. During development, branch naming and merging processes rely on developers' self-discipline. Before a version release, a specific developer needs to manually record the branch to be released and notify relevant developers to merge to that specific branch to ensure no branches are missing. After the release, it is also necessary to notify other developers still working on the project to synchronize the code and avoid problems such as merging failures due to significant version differences.

[0005] In particular, during the testing and pre-release phases of software projects, discrepancies often arise due to insufficient testing methods. This results in the user receiving a program that does not match the developer's expectations, and technical problems go undetected, leading to a significant waste of human and material resources and a loss of user experience. Summary of the Invention

[0006] The purpose of this application is to solve the above-mentioned problems by providing an automatic detection method for software pipelines and corresponding apparatus, computer equipment, computer-readable storage media, and computer program products.

[0007] To suit the various purposes of this application, the following technical solution is adopted:

[0008] In one aspect, to suit one of the purposes of this application, an automatic detection method for software pipelines is provided, comprising:

[0009] In response to pipeline inspection events, start the latest version of the verification program;

[0010] The verification program verifies the development branches submitted to the test environment by each user in the corresponding pipeline according to the verification configuration information. If the verification fails, a notification message is sent to the user of the corresponding development branch and the pipeline used to merge the code of all development branches is interrupted.

[0011] When the verification is successful, the pre-release branch list is compared with the development branches submitted to the test environment by each user to determine the difference branch list, and the updated version of the development branch in the difference branch list is obtained so that all development branches constitute the legal branch set of the software project.

[0012] In response to a branch merge request, all development branches in the set of valid branches are merged to obtain the code set corresponding to the software project.

[0013] Optionally, in response to pipeline inspection events, the latest version of the verification procedure can be started, including:

[0014] In response to a pipeline verification event, the verification procedure is started. The pipeline verification event is any one of the following: development branch commit event, merge request commit event, or scheduled task trigger event.

[0015] The verification program checks its own version, and if the version is outdated, it downloads and installs the latest version and then starts automatically.

[0016] Optionally, the verification program performs verification on the development branches submitted to the test environment by each user in the corresponding pipeline according to the verification configuration information, including:

[0017] The verification program verifies the names of the development branches submitted to the test environment by each user according to the branch naming rules in the verification configuration information. When the verification fails, an exception is thrown and the current pipeline is interrupted.

[0018] The verification program verifies the version information of the development branches submitted to the test environment by each user according to the branch synchronization rules in the verification configuration information. When the development branch lags behind the main branch in the verification configuration information, the verification is determined to have failed, an exception is thrown, and the current pipeline is interrupted.

[0019] The verification program verifies the compatibility between development branches submitted to the test environment by each user according to the branch merging rules in the verification configuration information. When there are incompatible development branches, the verification is determined to have failed, an exception is thrown, and the current pipeline is interrupted.

[0020] Optionally, a list of differing branches is determined by comparing the pre-release branch list with the development branches submitted to the test environment by each user, and the updated versions of the development branches in the differing branch list are obtained, including:

[0021] Responding to the pre-release instructions corresponding to the pre-release environment, obtain a pre-release branch list, which includes specified information of multiple development branches expected to be released;

[0022] Find a difference branch list consisting of all difference branches that have not been added to the pre-release branch list but have been released to the corresponding test branch list in the test environment, and send update notification messages to the users of each development branch in the difference branch list.

[0023] The development branch corresponding to the difference branch submitted in response to the update notification message is obtained as the updated version, and the corresponding development branch in the pre-release branch list is updated so that all development branches constitute a valid branch set for the software project.

[0024] Optionally, in response to a branch merge request, all development branches in the set of valid branches are merged to obtain the code set corresponding to the software project, including:

[0025] Create a merged draft based on the draft creation identifier contained in the verification configuration information;

[0026] In response to the user confirmation command for the merged draft, all development branches in the set of valid branches are merged to obtain the code set corresponding to the software project.

[0027] Optionally, after obtaining the code set corresponding to the software project, it includes:

[0028] Generate the corresponding computer program product for the code set and submit it to the app store for program release.

[0029] On the other hand, to meet one of the purposes of this application, an automatic software pipeline detection device is provided, comprising: a verification initiation module, used to respond to a pipeline verification event and initiate the latest version of the verification program; a verification execution module, used by the verification program to verify the development branches submitted by each user to the test environment in the corresponding pipeline according to verification configuration information, and to send a notification message to the user of the corresponding development branch and interrupt the pipeline used to merge the code of all development branches when the verification fails; a release verification module, used to compare the pre-release branch list with the development branches submitted by each user to the test environment when the verification passes, determine the difference branch list, obtain the updated version of the development branches in the difference branch list, so that all development branches constitute a legal branch set of the software project; and a merge execution module, used to respond to a branch merge request and merge all development branches in the legal branch set to obtain the code set corresponding to the software project.

[0030] Optionally, the verification startup module includes: a response startup unit, used to respond to pipeline verification events and start the verification program, wherein the pipeline verification event is any one of a development branch commit event, a merge request commit event, or a scheduled task trigger event; and a detection update unit, used to have the verification program detect its own version, and download and install the latest version when the version is outdated, and then start automatically.

[0031] Optionally, the verification execution module includes: a first verification unit, used by the verification program to verify the names of development branches submitted to the test environment by each user according to the branch naming rules in the verification configuration information; if the verification fails, an exception is thrown and the current pipeline is interrupted; a second verification unit, used by the verification program to verify the version information of development branches submitted to the test environment by each user according to the branch synchronization rules in the verification configuration information; if the development branch lags behind the main branch in the verification configuration information, the verification is determined to have failed, an exception is thrown, and the current pipeline is interrupted; a third verification unit, used by the verification program to verify the compatibility between development branches submitted to the test environment by each user according to the branch merging rules in the verification configuration information; if there are incompatible development branches, the verification is determined to have failed, an exception is thrown, and the current pipeline is interrupted.

[0032] Optionally, the release verification module includes: an instruction response unit, configured to respond to a pre-release instruction corresponding to the pre-release environment, obtain a pre-release branch list, the pre-release branch list including specified information of multiple expected development branches; a difference lookup unit, configured to look up a difference branch list consisting of all difference branches that have not been added to the pre-release branch list but have been released to the test branch list corresponding to the test environment, and send update notification messages to the users corresponding to each development branch in the difference branch list; and an update processing unit, configured to obtain the development branch corresponding to the difference branch submitted in response to the update notification message as an update version, update the corresponding development branch in the pre-release branch list, so that all development branches constitute a valid branch set for the software project.

[0033] Optionally, the merge execution module includes: a draft creation unit, used to create a merge draft according to the draft creation identifier contained in the verification configuration information; and a project merge unit, used to merge all development branches in the set of legal branches in response to the user confirmation instruction of the merge draft, to obtain the code set corresponding to the software project.

[0034] Optionally, following the merge execution module, there is a project release module, used to generate the corresponding computer program product of the code set and submit it to the application store to realize program release.

[0035] In another aspect, a computer device provided to suit one of the purposes of this application includes a central processing unit and a memory, the central processing unit being used to invoke and run a computer program stored in the memory to perform the steps of the software pipeline automatic detection method described in this application.

[0036] In another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the described software pipeline automatic detection method, which, when called by a computer, performs the steps included in the method.

[0037] In another aspect, a computer program product provided for another purpose of this application includes a computer program / instructions that, when executed by a processor, implement the steps of the automatic detection method for software pipelines described in any embodiment of this application.

[0038] Compared with existing technologies, this application has several advantages, including but not limited to:

[0039] First, by embedding verification programs in the pipeline of different development branches in the program development and assembly process to perform verification, the full-process automated detection of various aspects of the specifications of multiple development branches of the software project is achieved. The automated pipeline ensures a smoother software project assembly process and improves software assembly efficiency.

[0040] Secondly, by embedding the detection of development branches under both test and pre-release environments during the automatic detection process, the differences between the development side and the user side can be effectively identified, and the updated versions of the corresponding development branches can be obtained in a timely manner. This ensures that the pre-release branch is consistent with the test branch, guarantees user experience, and avoids unnecessary debugging time costs.

[0041] Furthermore, the automatic detection process of this application is universal and can be applied to various software engineering scenarios, thereby improving the development efficiency of software engineering. Attached Figure Description

[0042] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0043] Figure 1 This is a flowchart illustrating one embodiment of the automatic detection method for software pipelines according to this application.

[0044] Figure 2 This is a flowchart illustrating the routine verification process performed by the verification procedure in this application embodiment.

[0045] Figure 3 This is a schematic diagram illustrating the process of the verification procedure performing pre-release environment verification in the embodiments of this application.

[0046] Figure 4 This is a schematic diagram illustrating the process of implementing human-computer interaction based on verification configuration information to merge development branches in an embodiment of this application.

[0047] Figure 5 This is a schematic block diagram of the automatic detection device for the software pipeline of this application;

[0048] Figure 6 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0049] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0050] Unless otherwise specified, the neural network models referenced or potentially referenced in this application may be deployed on a remote server and invoked remotely on the client, or deployed on a client with the capability to invoke directly. In some embodiments, when running on the client, the corresponding intelligence may be acquired through transfer learning in order to reduce the requirements on the client's hardware resources and avoid excessive consumption of the client's hardware resources.

[0051] Unless otherwise expressly stated, the various embodiments disclosed in this application can be combined in a cross-cutting manner to flexibly construct new embodiments, as long as such combination does not depart from the inventive spirit of this application and can meet the needs of the prior art or solve a certain deficiency in the prior art. Those skilled in the art should be aware of such modifications.

[0052] The software pipeline automatic detection method of this application can be programmed into a computer program product and deployed in a client or server to run.

[0053] For example, an application scenario of this application could be deploying a computer program product obtained according to this application in a distributed version control system (GIT). Git is an open-source distributed version control system that can effectively and quickly handle version management for projects ranging from very small to very large. For ease of understanding, the various concepts used in Git are briefly explained below:

[0054] CI (Continuous Integration) refers to the frequent (multiple times a day) integration of code into the backbone through a pre-built pipeline, with the aim of ensuring product quality while iterating rapidly. It typically requires automated testing to ensure the stability of the integrated code.

[0055] CD (Continuous Delivery / Deployment) can be seen as the next step in continuous integration. It refers to frequently delivering new versions of software to the quality team or users for testing. If the tests pass, the code can be deployed to the production environment.

[0056] Pipeline: refers to the collective business logic that executes CI / CD processes. Continuous integration (CI) and / or continuous delivery (CD) can be achieved through pipelines.

[0057] Integration testing: refers to the process of breaking down the corresponding functions of a software project into several modules, assigning them to multiple R&D personnel with corresponding development branches, and finally integrating these subdivided modules together.

[0058] Development environment: A system provided to internal R&D personnel for research, development, debugging, etc.

[0059] Test environment: A system provided to testers to debug and accept complete functional modules or systems.

[0060] Pre-release environment: Provided to internal personnel for functional acceptance testing to ensure that the programs and business processes are correct and error-free.

[0061] Production environment: The system that users are given access to.

[0062] Verification procedure: A procedure obtained according to this application for implementing an automatic detection method for software pipelines.

[0063] Program Manager: This program is primarily used for downloading, installing, and updating the verification program for this application.

[0064] The subsequent disclosure of various embodiments in this application will be described with reference to the various related concepts of the GIT system. However, it should be understood that this application can also be deployed in similar systems other than GIT and is not limited thereto.

[0065] Please see Figure 1 The software pipeline automatic detection method of this application, in one embodiment, includes the following steps:

[0066] Step S1100: Respond to the pipeline inspection event and start the latest version of the verification program;

[0067] The verification program of this application is embedded in the CI / CD pipeline. The verification program is implemented to perform standard verification on the entire pipeline operation process and its various materials, and can be triggered in response to corresponding pipeline verification events.

[0068] To ensure timeliness, when the verification program is started in response to a pipeline verification event, the latest version of the verification program is set to be started by default.

[0069] In one embodiment, step S1100 can be implemented according to the following process, including the following specific steps:

[0070] Step S1110: Respond to the pipeline verification event and start the verification program. The pipeline verification event is any one of the following: development branch commit event, merge request commit event, and scheduled task trigger event.

[0071] The pipeline verification event can be triggered at various times. For example, when a development branch corresponding to any module is submitted by a corresponding R&D user, a corresponding development branch submission event is triggered, and this development branch submission event can serve as the pipeline verification event to start the pipeline. Similarly, when any user wants the pipeline to merge various development branches and submits a corresponding merge request, a merge request submission event is triggered, and this merge request submission event can serve as the pipeline verification event. Furthermore, the pipeline can use a pre-set scheduled task to generate a scheduled task trigger event each time the scheduled time arrives; this scheduled task trigger event can serve as the pipeline verification event. In addition, any computer event that prompts the pipeline to run can cause the pipeline to treat it as a pipeline verification event and respond accordingly, so as to pre-start the verification program of this application to perform the corresponding verification for the pipeline.

[0072] Upon responding to the pipeline verification event, the installed verification program is first started. The verification program is pre-installed and may be the latest version or a previous version.

[0073] Step S1120: The verification program checks its own version. If the version is outdated, it downloads and installs the latest version and then starts automatically.

[0074] The verification program pre-implements self-checking business logic. When it is started, its corresponding process begins to execute its self-checking business logic, obtains the latest version number of the verification program in the verification configuration information corresponding to the pipeline, and then compares it with the current version number of the current verification program. If the current version number is the same as the latest version number, the subsequent steps are continued. If the current version number is behind the latest version number, the latest version of the verification program corresponding to the latest version number is downloaded, automatically installed, and automatically restarted to ensure that after responding to the pipeline verification event, the verification program corresponding to the latest version number is always running to perform verification for the pipeline.

[0075] It's easy to understand that ensuring the validation program always runs with the latest version can effectively maintain the healthy operation of the pipeline. By using the latest version of the validation business logic, the latest requirements of the entire software project that the pipeline needs to package can always be reflected, thereby ensuring the effective operation of the entire software engineering.

[0076] The aforementioned verification configuration information can be carried by environment variables, execution parameters and / or configuration files, and passed to the verification program in the form of wildcards, regular expressions, strings, JSON files, CI / CD configuration files, etc. It may contain relevant configurations required to implement the automatic detection method of this application, including but not limited to various matching rules, the on / off state of verification capabilities, and configuration items such as the keys corresponding to calling third-party services, etc., which will not be elaborated here.

[0077] Step S1200: The verification program verifies the development branches submitted to the test environment by each user in the corresponding pipeline according to the verification configuration information. If the verification fails, a notification message is sent to the user of the corresponding development branch and the pipeline used to merge the code of all development branches is interrupted.

[0078] In one embodiment, the verification configuration information includes configurations for various specifications required for pipeline verification. These specifications include, but are not limited to, branch naming specifications, branch synchronization specifications, branch merging specifications, development process specifications, release process specifications, and message notification specifications. Each specification uses one or more configuration items as described above to define corresponding rules for executing the corresponding verification tasks.

[0079] For example, branch naming rules can be defined using a combination of wildcards and matching rules to check whether each development branch conforms to the defined naming convention, making the branch naming convention suitable for validating the names of development branches. Similarly, branch synchronization rules can be defined using any one or more configuration items to check whether each development branch belongs to a synchronized version, making the branch synchronization specification suitable for validating version coordination relationships between development branches. Furthermore, branch merging rules can be defined using a combination of matching rules and validation capabilities to check whether different development branches are suitable for merging, making the branch merging specification suitable for validating compatibility between development branches.

[0080] Similarly, the development process specifications, release process specifications, and message notification specifications can all be implemented in a similar manner. Corresponding configuration items can be set in the verification configuration information, and their corresponding rules can be predefined to ultimately constitute the verification configuration information to serve the operation of the pipeline.

[0081] The latest version of the verification program, after it is started, can obtain the rules corresponding to various specifications by reading the verification configuration information, and then perform corresponding verifications on each development branch according to these rules.

[0082] In one embodiment, please refer to Figure 2 The verification can be performed using the following process, which includes the following steps:

[0083] Step S1210: The verification program verifies the names of the development branches submitted to the test environment by each user according to the branch naming rules in the verification configuration information. If the verification fails, an exception is thrown and the current pipeline is interrupted.

[0084] The verification program reads the configuration items corresponding to the branch naming convention from the verification configuration information, parses them to obtain the branch naming rules, and then checks the name of the development branch submitted by each user to the test environment to determine whether it conforms to the branch naming rules. If it conforms to the branch naming rules, the verification passes and subsequent steps can continue; if it does not conform to the branch naming rules, the verification fails, indicating that the corresponding development branch has an incorrect naming problem. Therefore, an exception is thrown directly, and the current pipeline operation is interrupted so that the corresponding user can correct it and restart the pipeline.

[0085] Step S1220: The verification program verifies the version information of the development branches submitted to the test environment by each user according to the branch synchronization rules in the verification configuration information. When the development branch lags behind the main branch in the verification configuration information, it is determined that the verification has failed, an exception is thrown, and the current pipeline is interrupted.

[0086] The verification program reads the configuration items corresponding to the branch synchronization rules from the verification configuration information, parses them to obtain the branch synchronization rules, and then identifies the version information of each development branch submitted by each user to the test environment. Typically, this involves comparing the version number of a development branch with the version number of the designated main branch. If the former lags behind the latter, the verification fails, and a notification message is sent to the developer of the former, allowing them to synchronize the main branch to their local machine for correction and resubmitting their corresponding development branch. Similarly, an exception can be thrown and the current pipeline interrupted. When the verification passes, subsequent steps can continue. By verifying whether the current development branch is behind the main branch, it ensures that the development branch does not lag behind, thus avoiding serious version conflicts later.

[0087] Step S1230: The verification program verifies the compatibility between the development branches submitted to the test environment by each user according to the branch merging rules in the verification configuration information. When there are incompatible development branches, the verification is determined to have failed, an exception is thrown, and the current pipeline is interrupted.

[0088] The verification program reads the configuration items corresponding to the branch merging rules from the verification configuration information, parses them to obtain the branch merging rules, and then verifies whether each development branch submitted by each user to the test environment is allowed to be merged with each other. Specifically, it verifies whether each development branch is suitable for merging into the target branch, or whether it is suitable for merging with other branches in the correct order. If merging is not allowed or cannot be performed in the preset merging order, the verification fails, a corresponding notification message is sent to the user of the relevant development branch, an exception is thrown, and the current pipeline is interrupted. When the verification passes, subsequent steps are allowed to continue.

[0089] As can be seen from the above exemplary implementation of the verification, for each development branch, this embodiment performs layer-by-layer in-depth verification through branch naming rules, branch synchronization rules, and branch merging rules, realizing a systematic detection of the legality of the development branches, ensuring that each development branch entering the test environment is a legal branch, ensuring that the test environment can obtain effective development branches for testing, thereby ensuring the smooth production of the software project.

[0090] Step S1300: When the verification is passed, the pre-release branch list is compared with the development branches submitted to the test environment by each user to determine the difference branch list, and the updated version of the development branches in the difference branch list is obtained so that all development branches constitute the legal branch set of the software project.

[0091] In practice, even if users successfully complete the test in the test environment, the lack or imperfection of the verification mechanism often leads to the failure to obtain a development branch consistent with the test environment in the subsequent pre-release environment. Therefore, this step is added to the automatic detection method of this application to perform consistency verification on the development branches of the pre-release environment and the test environment.

[0092] To this end, a pre-release branch list corresponding to the pre-release environment is obtained, along with a set of development branches submitted by each user in the test environment. Then, the pre-release branch list is compared with the development branch set to identify discrepancies, generating a discrepancy information list for these branches. Next, updated versions of the development branches required by the pre-release environment are retrieved for these discrepancy branch lists. These updated versions can typically be submitted by the corresponding development users or management users. Development branches in the test environment that have not yet been submitted to the pre-release environment can be directly specified for submission to the pre-release environment to achieve version updates. During this process, the verification program of this application monitors whether these updated versions have arrived. When updated versions of all discrepancies in the discrepancy branch list have arrived, the pre-release environment obtains the legal branch set required to construct the software project.

[0093] It is easy to understand that setting up a verification step between the test environment and the pre-release environment can help to identify and fill any gaps in the necessary components of the pre-branch environment, ensuring that the development branch structure in the pre-release environment is consistent with that in the test environment. This allows the pipeline to transfer all development branches that have passed the test environment to the pre-release environment for correct release, ensuring that the pipeline can successfully assemble the corresponding computer program product of the software project.

[0094] Step S1400: Respond to the branch merge request and merge all development branches in the set of legal branches to obtain the code set corresponding to the software project.

[0095] Once the verification of the development branch in the pre-release environment is complete, a draft of the merge request can be automatically generated according to the configuration item set in the verification configuration information to indicate the automatic creation of a draft merge request. This allows developers to clearly see the merge draft in the pipeline management information and subsequently confirm the merge draft to trigger the branch merge request.

[0096] When a branch merge request is triggered, in response to the request, the pipeline merges all development branches in the set of valid branches to obtain the code set corresponding to the software project, and can generate the corresponding computer program product based on the code set.

[0097] In one embodiment, to complete the release of the software project, the following steps are further added based on the above embodiments:

[0098] Step S1500: Generate the corresponding computer program product of the code set and submit it to the application store to realize program release.

[0099] Specifically, the code set can be compiled by calling an encoding program to generate a corresponding computer program product and mark its version information. Then, it can be submitted to the publishing interface of the application store predetermined in the verification configuration information to publish the computer program product to the corresponding application store, making the computer program product available to the public and facilitating any user to download and install the computer program product from the application product.

[0100] Based on the above embodiments, it is easy to understand that this application has many advantages, including but not limited to:

[0101] First, by embedding verification programs in the pipeline of different development branches in the program development and assembly process to perform verification, the full-process automated detection of various aspects of the specifications of multiple development branches of the software project is achieved. The automated pipeline ensures a smoother software project assembly process and improves software assembly efficiency.

[0102] Secondly, by embedding the detection of development branches under both test and pre-release environments during the automatic detection process, the differences between the development side and the user side can be effectively identified, and the updated versions of the corresponding development branches can be obtained in a timely manner. This ensures that the pre-release branch is consistent with the test branch, guarantees user experience, and avoids unnecessary debugging time costs.

[0103] Furthermore, the automatic detection process of this application is universal and can be applied to various software engineering scenarios, thereby improving the development efficiency of software engineering.

[0104] Based on any embodiment of this application, please refer to Figure 3By comparing the pre-release branch list with the development branches submitted to the test environment by each user, a difference branch list is determined, and the updated versions of the development branches in the difference branch list are obtained, including:

[0105] Step S1310: Respond to the pre-release command corresponding to the pre-release environment and obtain the pre-release branch list, wherein the pre-release branch list includes specified information of multiple expected release development branches;

[0106] Typically, a pre-release branch list is maintained by the R&D staff, which contains the specified information for each development branch that needs to be released. When it is time to release the software project of this application, the corresponding pre-release instruction can be issued to start the pre-release phase of the pipeline.

[0107] In response to the pre-release instruction, the verification program of this application can directly read the pre-release branch list in order to perform corresponding verification on the pre-release branch list.

[0108] Step S1320: Find the difference branch list, which consists of all difference branches that have not been added to the pre-release branch list but have been released to the test branch list corresponding to the test environment, and send update notification messages to the users of each development branch in the difference branch list.

[0109] When validating the pre-release branch list, the main process involves comparing it with the set of development branches that have been submitted to the test environment, i.e., the test branch list, to identify the difference branches. In this embodiment, the difference branches refer to development branches that have been released to the test environment but not to the pre-release branch list. In other words, we find development branches that have passed the test but have not been merged into the pre-release environment, thereby obtaining the difference branch list.

[0110] For each development branch in the difference branch list, an update notification message is sent to the corresponding R&D user to notify the R&D user to confirm the submission of the updated version. Generally, the updated version can be the development branch version that has been submitted to the test environment and passed the test.

[0111] Step S1330: Obtain the development branch corresponding to the difference branch submitted in response to the update notification message as the updated version, update the corresponding development branch in the pre-release branch list, so that all development branches constitute a legal branch set of the software project.

[0112] When a development user on a development branch within the difference branch list receives the update notification message and submits the corresponding difference branch as an update version to the pre-release environment in response to the update notification message, the specified information of the update version is added to the pre-release branch list to complete the development branches in the pre-release branch list. Finally, when the update versions corresponding to each difference branch have arrived, all the development branches specified in the pre-release branch list of the pre-release environment constitute the set of legal branches required for the software project, which can be used to produce the code set corresponding to the software project.

[0113] As can be seen from the above embodiments, by verifying the differences between the development branches of the pre-release environment and the test environment in the pre-release stage of the pipeline through the verification procedure of this application, the development branches of the pre-release can be checked for omissions and deficiencies, avoiding confusion caused by the inconsistency between the development branches of the test and release stages, and ensuring the consistency of test results and user experience.

[0114] Based on any embodiment of this application, please refer to Figure 4 In response to a branch merge request, all development branches in the set of valid branches are merged to obtain the code set corresponding to the software project, including:

[0115] Step S1410: Create a merged draft according to the draft creation identifier contained in the verification configuration information;

[0116] The verification configuration information can be pre-set with a draft creation identifier, which indicates that after all development branches required in the pre-release environment have passed the verification procedure of this application, a merge draft will be automatically generated. The merge draft is used to indicate the description information corresponding to the generated merge request.

[0117] After verifying the pre-release branch list of the pre-release environment, the program in this application identifies the draft creation identifier stored in the verification configuration information and automatically generates a merged draft based on the draft creation identifier.

[0118] Step S1420: In response to the user confirmation instruction of the merged draft, merge all development branches in the set of legal branches to obtain the code set corresponding to the software project.

[0119] The merge draft can be viewed and confirmed by users with corresponding management permissions. Once a user agrees to the description of the merge draft and confirms the operation, a corresponding user confirmation instruction is issued. In response to this instruction, the pipeline is responsible for merging all development branches in the set of legal branches, causing the code of all development branches belonging to side branches to flow to the main branch, and merging the code of the main branch with the relevant development branches to obtain the code set corresponding to the software project, which can be used to generate the corresponding computer program product.

[0120] As can be easily understood from the above embodiments, after completing a series of verifications, this application can automatically generate a merged draft. Relevant users only need to perform a confirmation operation to control the pipeline to automatically complete the assembly of the code set. The required manpower cost is extremely low, which greatly improves the efficiency of software engineering implementation.

[0121] Please see Figure 5 To meet one of the purposes of this application, an automatic software pipeline detection device is provided, which is a functional embodiment of the automatic software pipeline detection method of this application. The device includes: a verification initiation module 1100, used to respond to pipeline verification events and start the latest version of the verification program; a verification execution module 1200, used to have the verification program perform verification on the development branches submitted by each user to the test environment in the corresponding pipeline according to the verification configuration information, and send a notification message to the user of the corresponding development branch and interrupt the pipeline used to merge the code of all development branches when the verification fails; a release verification module 1300, used to compare the pre-release branch list with the development branches submitted by each user to the test environment when the verification passes, determine the difference branch list, obtain the updated version of the development branches in the difference branch list, so that all development branches constitute a legal branch set of the software project; and a merge execution module 1400, used to respond to the branch merge request, merge all development branches in the legal branch set, and obtain the code set corresponding to the software project.

[0122] Based on any embodiment of this application, the verification startup module 1100 includes: a response startup unit, used to respond to a pipeline verification event and start a verification program, wherein the pipeline verification event is any one of a development branch submission event, a merge request submission event, or a scheduled task trigger event; and a detection update unit, used to have the verification program detect its own version, and download and install the latest version when the version is outdated, and then start automatically.

[0123] Based on any embodiment of this application, the verification execution module 1200 includes: a first verification unit, used by the verification program to verify the names of development branches submitted to the test environment by each user according to the branch naming rules in the verification configuration information, and to throw an exception and interrupt the current pipeline when the verification fails; a second verification unit, used by the verification program to verify the version information of development branches submitted to the test environment by each user according to the branch synchronization rules in the verification configuration information, and to determine that the verification fails when the development branch lags behind the main branch in the verification configuration information, and to throw an exception and interrupt the current pipeline; and a third verification unit, used by the verification program to verify the compatibility between development branches submitted to the test environment by each user according to the branch merging rules in the verification configuration information, and to determine that the verification fails when there are incompatible development branches, and to throw an exception and interrupt the current pipeline.

[0124] Based on any embodiment of this application, the release verification module 1300 includes: an instruction response unit, configured to respond to a pre-release instruction corresponding to the pre-release environment, obtain a pre-release branch list, the pre-release branch list including specified information of multiple expected development branches; a difference lookup unit, configured to look up a difference branch list consisting of all difference branches that have not been added to the pre-release branch list but have been released to the test branch list corresponding to the test environment, and send update notification messages to the users corresponding to each development branch in the difference branch list; and an update processing unit, configured to obtain the development branch corresponding to the difference branch submitted in response to the update notification message as an update version, update the corresponding development branch in the pre-release branch list, so that all development branches constitute a legal branch set of the software project.

[0125] Based on any embodiment of this application, the merge execution module 1400 includes: a draft creation unit, used to create a merge draft according to the draft creation identifier contained in the verification configuration information; and a project merging unit, used to merge all development branches in the legal branch set in response to the user confirmation instruction of the merge draft, to obtain the code set corresponding to the software project.

[0126] Based on any embodiment of this application, the merge execution module 1400 further includes: a project release module, used to generate computer program products corresponding to the code set and submit them to an application store for program release.

[0127] To address the aforementioned technical problems, embodiments of this application also provide computer equipment. For example... Figure 6As shown, the computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store a sequence of control information. When the computer-readable instructions are executed by the processor, the processor can implement a product search category identification method. The processor of the computer device provides computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute the software pipeline automatic detection method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that... Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0128] In this embodiment, the processor is used to execute... Figure 5 The system includes the specific functions of each module and its sub-modules, and stores the program code and various data required to execute these modules or sub-modules. A network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the software pipeline automatic detection device of this application, and the server can call the server's program code and data to execute the functions of all sub-modules.

[0129] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the software pipeline automatic detection method of any embodiment of this application.

[0130] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0131] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0132] In summary, this application can improve the implementation efficiency of software engineering, effectively verify various aspects of information related to the development branches of the software project during the software project release process, ensure the smooth operation of the assembly line of the software project, obtain high-quality computer program products, and ensure user experience.

Claims

1. An automatic detection method for software pipelines, characterized in that, include: In response to pipeline inspection events, start the latest version of the verification program; The verification program verifies the development branches submitted to the test environment by each user in the corresponding pipeline according to the verification configuration information. If the verification fails, a notification message is sent to the user of the corresponding development branch and the pipeline used to merge the code of all development branches is interrupted. The verification configuration information includes branch naming rules for verifying the names of the development branches submitted to the test environment by each user, branch synchronization rules for verifying the version information of the development branches submitted to the test environment by each user, and branch merging rules for verifying the compatibility between the development branches submitted to the test environment by each user. When the verification is successful, the pre-release branch list is compared with the development branches submitted by each user to the test environment to determine the difference branch list and notify the users of each development branch in it. The updated version submitted by the user for the development branch in the difference branch list is obtained, so that all development branches constitute the legal branch set of the software project; wherein, the pre-release branch list includes specified information of multiple development branches expected to be released. In response to a branch merge request, all development branches in the set of valid branches are merged to obtain the code set corresponding to the software project.

2. The automatic detection method for software pipelines according to claim 1, characterized in that, In response to pipeline inspection events, start the latest version of the verification procedure, including: In response to a pipeline verification event, the verification procedure is started. The pipeline verification event is any one of the following: development branch commit event, merge request commit event, or scheduled task trigger event. The verification program checks its own version, and if the version is outdated, it downloads and installs the latest version and then starts automatically.

3. The automatic detection method for software pipelines according to claim 1, characterized in that, The verification program performs verification on the development branches submitted by each user to the test environment in the corresponding pipeline according to the verification configuration information, including: The verification program verifies the names of the development branches submitted to the test environment by each user according to the branch naming rules in the verification configuration information. When the verification fails, an exception is thrown and the current pipeline is interrupted. The verification program verifies the version information of the development branches submitted to the test environment by each user according to the branch synchronization rules in the verification configuration information. When the development branch lags behind the main branch in the verification configuration information, the verification is determined to have failed, an exception is thrown, and the current pipeline is interrupted. The verification program verifies the compatibility between development branches submitted to the test environment by each user according to the branch merging rules in the verification configuration information. When there are incompatible development branches, the verification is determined to have failed, an exception is thrown, and the current pipeline is interrupted.

4. The automatic detection method for software pipelines according to claim 1, characterized in that, By comparing the pre-release branch list with the development branches submitted by each user to the test environment, a list of differing branches is determined and users on each development branch are notified. The updated versions submitted by users for the corresponding development branches in the differing branch list are then retrieved, including: Respond to the pre-release instructions corresponding to the pre-release environment and obtain the list of pre-release branches; Find a difference branch list consisting of all difference branches that have not been added to the pre-release branch list but have been released to the corresponding test branch list in the test environment, and send update notification messages to the users of each development branch in the difference branch list. The development branch corresponding to the difference branch submitted in response to the update notification message is obtained as the updated version, and the corresponding development branch in the pre-release branch list is updated so that all development branches constitute a valid branch set for the software project.

5. The automatic detection method for software pipelines according to claim 1, characterized in that, In response to a branch merge request, all development branches in the set of valid branches are merged to obtain the code set corresponding to the software project, including: Create a merged draft based on the draft creation identifier contained in the verification configuration information; In response to the user confirmation command for the merged draft, all development branches in the set of valid branches are merged to obtain the code set corresponding to the software project.

6. The automatic detection method for software pipelines according to any one of claims 1 to 5, characterized in that, After obtaining the code set corresponding to the software project, it includes: Generate the corresponding computer program product for the code set and submit it to the app store for program release.

7. An automatic inspection device for a software pipeline, characterized in that, include: The verification startup module is used to respond to pipeline verification events and start the latest version of the verification program; The verification execution module is used by the verification program to verify the development branches submitted to the test environment by each user in the corresponding pipeline according to the verification configuration information. When the verification fails, a notification message is sent to the user of the corresponding development branch and the pipeline used to merge the code of all development branches is interrupted. The verification configuration information includes branch naming rules for verifying the names of the development branches submitted to the test environment by each user, branch synchronization rules for verifying the version information of the development branches submitted to the test environment by each user, and branch merging rules for verifying the compatibility between the development branches submitted to the test environment by each user. The release verification module is used to compare the pre-release branch list with the development branches submitted by each user to the test environment when the verification is passed, determine the difference branch list and notify the users of each development branch in it, obtain the updated version submitted by the user for the development branch in the difference branch list, so that all development branches constitute the legal branch set of the software project; wherein, the pre-release branch list includes specified information of multiple development branches expected to be released; The merge execution module is used to respond to branch merge requests, merge all development branches in the set of legal branches, and obtain the code set corresponding to the software project.

8. A computer device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 6, which, when invoked by a computer, executes the steps included in the corresponding method.

10. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 6.

Images