One-package-to-the-end method, device and equipment based on main engineering and storage medium

Through a one-pack-to-end method based on main project, the code and environment configuration are managed together, and the problem of rapid recovery of systems and data in product management in the existing technology is solved, and the effect of rapid recovery and minimizing business interruptions in the face of failures or disasters is achieved.

CN119597332AActive Publication Date: 2025-03-11ZHAOLIAN CONSUMER FINANCE CO LTD
View PDF 9 Cites 0 Cited by

Patent Information

Application Number
CN202411502867.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-10-25
Publication Date
2025-03-11
Estimated Expiration
2044-10-25

AI Technical Summary

Technical Problem

The prior art is difficult to quickly restore the system and corresponding data in product management, resulting in a significant impact on business interruption in the face of failure or disaster.

Method used

A one-pack-to-end method based on main project is adopted to manage the code and the corresponding environment configurations in a coordinated manner, so as to quickly restore the system and corresponding data when deploying the environment.

Benefits of technology

After the installation package is modified, it quickly passes the development self-test environment, ST test environment to the UAT acceptance environment, to ensure that the released final installation package is consistent with the content of the installation package to be tested in the test, thereby achieving a quick recovery and deployment system with one package to the end.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119597332A_ABST
    Figure CN119597332A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of product management, in particular to a one-package-to-the-end method and device based on main engineering, equipment and a storage medium. The method comprises the following steps: maintaining a to-be-tested installation package by adopting a dev branch, carrying out development local verification, and if the development local verification is passed, executing ST testing; judging whether the system elements meet code construction conditions or not, and if yes, constructing codes in the ST environment; determining a pre-published installation package in combination with the system elements and codes on the ST environment, maintaining the pre-published installation package by adopting a release branch pair, and performing function verification; if the function verification is passed, executing UAT test submission; judging whether a code construction condition is met or not, and if yes, constructing a code in the UAT environment; and obtaining a final installation package in combination with the system elements and the codes on the UAT environment, and maintaining the final installation package by adopting a master branch. Codes and environment configuration are managed in a matched mode, the system is rapidly pulled up when the environment is deployed, and the beneficial effect of rapidly recovering and deploying the system is achieved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the technical field of product management, and in particular to a one-package-to-the-end method, device, equipment and storage medium based on a main project. Background Art

[0002] Artifact management is a key activity to ensure the correctness, integrity, and security of each version and build in the software delivery process. At present, the mainstream artifact management method is to place all products in the artifact library for centralized management. When all artifacts are stored in the artifact library without effective version management, it will become difficult and time-consuming to find complete artifacts associated with specific historical versions of the system over time. However, in actual operations, different merchants may have different business needs and operating models, and therefore require different system functions and features to support their businesses. In other words, different merchants require different system versions. If there is a lack of rapid pulling of historical version system products based on historical versions, it will cause certain inconveniences. Therefore, a rapid recovery deployment system based on artifacts is very important, which allows organizations to quickly recover to a known good state in the face of failures or disasters, thereby minimizing the impact of business interruptions.

[0003] In summary, how to realize the function of quickly recovering and deploying the system based on products in product management is a technical problem that needs to be solved urgently. Summary of the invention

[0004] In order to overcome the shortcomings of the prior art, the present application provides a one-package-to-the-end method, device, equipment and storage medium based on the main project, so as to adopt a one-package-to-the-end solution to manage the code and the corresponding environment configuration in a matching manner, thereby realizing the rapid recovery of the system and corresponding data when the environment is deployed, and achieving the beneficial effect of rapid recovery of the deployment system based on the product.

[0005] The technical solution adopted by this application to solve its technical problem is: In a first aspect, the present application provides a one-package-to-the-end method based on a main project, the method comprising: The dev branch of the main project is used to maintain the updated installation package to be tested, and the installation package to be tested is verified locally. If the installation package to be tested passes the local verification, ST testing is performed to promote the system elements in the installation package to be tested to the ST test environment. Determine whether the system element meets the preset code building conditions, and if so, build the code on the ST environment, where the code on the ST environment is the code of the installation package to be tested reconstructed in the ST test environment; A pre-release installation package is constructed by combining the system elements and the code on the ST environment, and the release branch of the main project is used to maintain the pre-release installation package and perform functional verification on the pre-release installation package; If the pre-release installation package passes the functional verification, UAT testing is performed to upgrade the system element to the UAT acceptance environment; Determine whether the system element meets the preset code building conditions, and if so, build the code on the UAT environment, where the code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment; The system elements and the code on the UAT environment are combined to obtain a final installation package, and the master branch of the main project is used to maintain the final installation package.

[0006] Optionally, before the step of performing ST testing to upgrade the system elements in the installation package to be tested to the ST test environment, the step includes: Conduct multiple pre-checks on the system elements to be promoted to the ST test environment, including code quality check, configuration quality check, package dependency check, code review check, file resource quality check and self-test check; Determine whether any of the pre-checks fails. If not, determine that the pre-release installation package passes the pre-check. Otherwise, determine that the pre-release installation package fails the quality check and send a check failure prompt message.

[0007] Optionally, the step of determining whether the system element meets a preset code building condition includes: Determine whether the current system element content is consistent with the system element content recorded when executing ST test. If consistent, determine that the system element meets the code building conditions. The system element content includes commit id, md5 of configuration file, and md5 of basic image configuration; If the current system element content is inconsistent with the system element content recorded when the ST test is executed, it is determined that the system element does not meet the code building conditions, code building is not allowed and returns to the ST test.

[0008] Optionally, the step of determining a pre-release installation package in combination with the system element and the code on the ST environment, and performing functional verification on the pre-release installation package includes: Selecting a four-bit version to deploy the pre-release installation package, and performing the functional verification on the pre-release installation package based on the four-bit version; A test report corresponding to the function verification is outputted using a four-digit version number corresponding to the four-digit version to determine whether the pre-release installation package passes the function verification.

[0009] Optionally, the method further includes: Based on the four-digit version number, upgrading the system elements of the pre-release installation package to the UAT acceptance environment; Determine whether the current system element content is consistent with the system element content recorded when the UAT test is executed. If they are consistent, determine that the system element meets the code building conditions.

[0010] Optionally, if the pre-release installation package passes the functional verification, before the step of performing UAT testing to upgrade the system element to the UAT acceptance environment, the method includes: Determine whether there is an in-transit version in the UAT acceptance environment; If the in-transit version exists in the UAT acceptance environment, all in-transit versions are removed.

[0011] Optionally, after the step of combining the system elements and the code on the UAT environment to obtain a final installation package, the method includes: Determining whether there is any content change in the final installation package; If the final installation package has the content change, the final installation package is determined as the next installation package to be tested.

[0012] In a second aspect, the present application provides a one-package-to-the-end device based on the main project, comprising: The ST test judgment module uses the dev branch of the main project to maintain the installation package to be tested after the update, and performs local development verification on the installation package to be tested. If the installation package to be tested passes the local development verification, ST test is executed to promote the system elements in the installation package to be tested to the ST test environment; An ST code building judgment module is used to judge whether the system element meets the preset code building conditions. If it meets the code building conditions, the code on the ST environment is the code of the installation package to be tested reconstructed in the ST test environment; An ST installation package determination module, used to determine a pre-release installation package in combination with the system elements and the code on the ST environment, use the release branch of the main project to maintain the pre-release installation package, and perform functional verification on the pre-release installation package; A UAT testing module is used to perform UAT testing to upgrade the system element to a UAT acceptance environment if the pre-release installation package passes the functional verification; A UAT code building module is used to determine whether the system element meets the code building conditions, and if so, to build the code on the UAT environment, where the code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment; The UAT installation package determination module is used to combine the system elements and the code on the UAT environment to obtain the final installation package, and use the master branch of the main project to maintain the final installation package.

[0013] In a third aspect, the present application provides an electronic device, comprising: at least one processor and at least one memory, wherein the memory stores computer-readable instructions; The computer-readable instructions are executed by one or more of the processors, so that the electronic device implements the above-mentioned one-package-to-the-end method based on the main project.

[0014] In a fourth aspect, the present application provides a storage medium, wherein the computer-readable instructions are executed by a processor to implement the above-mentioned one-package-to-the-end method based on the main project.

[0015] The beneficial effects of the present application are as follows: after modifying the installation package, an installation package to be tested is obtained, and the installation package to be tested first enters the development self-test environment (i.e., SE environment) for development local verification. After determining the development local verification, the system elements of the installation package to be tested are promoted to the ST test environment (i.e., ST environment) through ST promotion testing, and then the code in the installation package to be tested is rebuilt in the ST test environment and combined with the system elements to form a pre-release installation package, thereby performing functional verification in the ST test environment; If the pre-release installation package passes the functional verification, the system elements in the pre-release installation package are promoted to the UAT acceptance environment (i.e., the UAT environment), and a determination is made as to whether the code building conditions are met. If so, the code is reconstructed, and the code content is consistent with the code content at the beginning of the test and after the test verification. Finally, the code and the system elements of the UAT acceptance environment are combined to obtain the final installation package. In the embodiment of the present application, the code building conditions are similar to the code building conditions, that is, a determination is made as to whether the system elements recorded during the last test are consistent with the system elements in the current environment. If they are consistent, the building conditions are met.

[0016] Among them, the release branch of the main project is used to maintain all the products in the installation package to be tested in the development self-test environment, the release branch of the main project is used to maintain all the products in the pre-release installation package of the ST test environment, and the master branch of the main project is used to maintain all the products in the final installation package of the UAT acceptance environment. By adopting the above technical solution, the present application includes at least the following beneficial effects: 1. After modifying the installation package, the installation package to be updated is obtained. The upgrade path from the development self-test environment, ST test environment to the UAT acceptance environment is followed. In each upgrade, it is determined whether the system elements of the code to be built correspond to the system elements of the last test, so as to ensure that the final releasable installation package is consistent with the content of the installation package to be tested, thereby ensuring one package to the end.

[0017] 2. Since the corresponding installation packages in each environment (the installation packages include all products corresponding to each system version) are maintained, when there is a need to restore any version, the code of the corresponding version and the corresponding system elements can be obtained from the maintained content, and combined to obtain the corresponding installation package to quickly restore the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a flowchart of a one-package-to-the-end method based on the main project provided in an embodiment of the present application; Figure 2 This is a specific flow chart of the one-package-to-the-end method based on the main project provided in an embodiment of the present application; Figure 3 It is a schematic diagram of the ST test process of the one-package-to-the-end method based on the main project provided in the embodiment of the present application; Figure 4 It is a flowchart of the quality inspection of the one-package-to-the-end method based on the main project provided in the embodiment of the present application; Figure 5 This is a schematic diagram of the UAT testing process of the one-package-to-the-end method based on the main project provided in an embodiment of the present application; Figure 6 It is a virtual structural diagram of a one-pack-to-the-bottom device based on the main project provided by this application; Figure 7 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] The present application is further described below in conjunction with the accompanying drawings and embodiments.

[0020] The following will clearly and completely describe the concept, specific structure and technical effects of the present application in combination with the embodiments and drawings, so as to fully understand the purpose, characteristics and effects of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of them. Based on the embodiments of the present application, other embodiments obtained by technicians in this field without creative work are all within the scope of protection of the present application. In addition, all the connection / connection relationships involved in the patent do not simply refer to the direct connection of components, but refer to the formation of a better connection structure by adding or reducing connection accessories according to the specific implementation situation. The various technical features created in this application can be combined interactively without conflicting with each other.

[0021] Among them, when the version of the installation package is modified, the installation package with the modified content will be determined as the installation package to be tested and enter the SE environment used for development self-testing and joint debugging. The following steps also involve the ST test environment (ie ST environment) and the UAT acceptance environment (ie UAT environment). The SE environment is used to perform local development verification on the current version, the ST environment is used to perform a series of quality and functional verifications on the version that has been locally verified, and the UAT environment is used to accept all products of the version that has been verified in the SE environment, and obtain an installation package that can be released to production.

[0022] Reference Figure 1 , Figure 2 , Figure 1 is a flow chart of a one-package-to-the-end method based on the main project provided in an embodiment of the present application. Figure 2 : is a specific flow chart of the one-package-to-the-end method based on the main project provided in the embodiment of the present application. The one-package-to-the-end method based on the main project provided in the embodiment of the present application specifically includes the following steps, which are specifically described below: Step S1, use the dev branch of the main project to maintain the updated installation package to be tested, and perform local development verification on the installation package to be tested. If the installation package to be tested passes the local development verification, perform ST testing to promote the system elements in the installation package to be tested to the ST test environment.

[0023] Specifically, the main project stores artifacts, which include the results of code compilation and other data such as configuration; the dev branch of the main project is a branch used to develop new features or fix bugs. The development on the dev branch is usually experimental and not fully tested. Once the development is completed and verified, it is merged into other more stable branches of the main project (for example, in the embodiment of the present application, after completing the local development verification, the content of the dev branch is synchronized to the release branch of the main project); The installation package to be tested refers to an installation package that has been modified but not yet completed testing. It includes all the code and corresponding system elements corresponding to this version. The system elements refer to all the content except the code, such as configuration, engineering, SQL scripts, etc. corresponding to this version; local development verification refers to the testing and verification of the software in the local environment of the developer, usually to ensure that the basic functions and performance of the software meet expectations and have no obvious errors; ST (Software Testing) submission for testing refers to submitting the installation package that has been verified locally during development to software testing to ensure its functionality.

[0024] More specifically, for example, assuming that the product has function A, in the SE environment of development and self-testing, a three-digit version number corresponding to only function A will be generated, such as 1.0.0. If it is necessary to add function B on the basis of function A in the future, then for the content that has been developed but not yet tested, it has function A and function B, and a corresponding three-digit version number is generated, such as 1.0.1, to distinguish the historical versions of the product.

[0025] Step S2, determine whether the system element meets the preset code building conditions. If it meets the code building conditions, build the code on the ST environment. The code on the ST environment is the code of the installation package to be tested reconstructed in the ST test environment.

[0026] Among them, in the process of developing any three-digit version, there may be multiple changes and tests, and the bugs modified in each test are different. Based on this, a four-digit version number needs to be assigned for each modification (including but not limited to modifying code content, configuration files, etc.) to avoid the situation where the version number is not unique due to multiple modifications.

[0027] Specifically, in the embodiment of the present application, the step of determining whether the system element meets the preset code building condition includes: Determine whether the current system element content is consistent with the system element content recorded when executing ST test. If consistent, determine that the system element meets the code building conditions. The system element content includes commit id, md5 of configuration file, and md5 of basic image configuration; If the current system element content is inconsistent with the system element content recorded when the ST test is executed, it is determined that the system element does not meet the code building conditions, code building is not allowed and returns to the ST test.

[0028] Specifically, in the ST test environment, new functions may need to be tested multiple times before they can be implemented, and this period may involve multiple modifications. Therefore, the code building conditions need to ensure that the built code is completely consistent with the system content, and any change requires adjusting the version number of the installation package in the test. In layman's terms, assuming that a version with a three-digit version number of 1.0.0 is developed, there may be multiple modifications and tests, and the bugs modified in each test are different. The first test can generate a four-digit version number of 1.0.0.0, and the second test can generate a four-digit version number of 1.0.0.1. In these two tests, at least one content has changed.

[0029] More specifically, refer to Figure 2 , Figure 2 Code build verification in , including commit id verification, configuration file md5 verification, base image md5 verification, version selection and automatic update and upgrade, specifically: If any of the following contents are different between the commit id used in this test and the last test, the md5 of the configuration file used, the md5 of the base image configuration, and the four-digit version number, the code building condition is not met. Once the code building condition is not met, code building is not allowed, and the version number is adjusted accordingly. In the embodiment of the present application, if there is inconsistency, this part of the content is returned to the test, and an updated version number is generated compared to the last test version number, for example, from 1.0.0.0 to 1.0.0.1.

[0030] More specifically, for packages that rely on external systems, a four-digit version number must be selected by default. If it is the first time to test, you can select version number 1. If it is modified later, you need to re-test and re-select the four-digit version number. Specifically, packages that rely on external systems refer to third-party libraries or tools used in the development process. Once the external package is modified, whether it is directly modifying the source code or by configuring parameters, it needs to be re-tested and updated to a four-digit version number accordingly.

[0031] Step S3, determining a pre-release installation package in combination with the system elements and the code on the ST environment, using the release branch of the main project to maintain the pre-release installation package, and performing functional verification on the pre-release installation package.

[0032] Specifically, the code rebuilt in the ST test environment and the corresponding version of the system content combination can be combined to obtain an installation package for functional verification, that is, the pre-release installation package proposed in this application. Among them, for all product contents under the installation package corresponding to each version number, the release branch of the main project is used for unified maintenance. In the ST test environment, a series of functional verification and quality verification are also performed on the installation package functions obtained by combining the corresponding version of the system elements after the construction code. Among them, functional verification refers to whether the functions that the verification code needs to implement are feasible, and quality verification specifically includes: Reference Figure 3 , Figure 3 This is a schematic diagram of the ST test process of the one-package-to-the-end method based on the main project provided in the embodiment of the present application. When a version is tested by ST (such as Figure 3 After the ST test is submitted, a series of operations are performed, specifically: input parameter processing refers to the processing of input parameters, including verification, formatting or conversion, to ensure that they meet the requirements of subsequent steps; on-site test data is to apply the above input parameters; quality inspection is to detect the quality of input parameters; changing version status refers to adjusting the status of the version based on the results of quality inspection, including but not limited to under development, to be tested, to be released, released, etc.; product promotion refers to the promotion to the UAT environment mentioned below, and post-test extension refers to additional processing or optimization that may occur after the product is created to improve performance or add new features; returning test results refers to feeding back the test results to relevant personnel or systems for further analysis or decision-making.

[0033] The returned test results include: Figure 2 The operations shown include selecting four-bit version deployment, testing, and outputting test reports. Rotating the four-bit version deployment refers to using the four-bit version to deploy the installation package in the test system for testing, and the obtained test report returns the test results.

[0034] More specifically, the step of performing ST testing to upgrade the system elements in the installation package to be tested to the ST test environment includes: Conduct multiple pre-checks on the system elements to be promoted to the ST test environment, including code quality check, configuration quality check, package dependency check, code review check, file resource quality check and self-test check; Determine whether any of the pre-checks fails. If not, determine that the pre-release installation package passes the pre-check. Otherwise, determine that the pre-release installation package fails the quality check and send a check failure prompt message.

[0035] Specifically, refer to Figure 4 , Figure 4This is a flow chart of the quality inspection process of the one-package-to-the-end method based on the main project provided in the embodiment of the present application. Figure 4 It can be seen that for each of the multiple quality checks, a whitelist check is required to determine whether the corresponding quality meets the standard. If the standard is not met, the corresponding reasons for unqualified quality and the modification methods are displayed. Finally, only when all quality checks are passed, the quality inspection step of the system element will be determined to have passed. Otherwise, it is confirmed that the inspection has not passed. In this case, the corresponding inspection failure prompt message can be sent. In the embodiment of the present application, only system elements that have passed the quality inspection can enter the code building part, that is, enter the code building condition judgment. After the code is built, functional verification is performed to determine whether the version of the code and its system elements can normally realize the required functions, so as to determine whether it can be promoted to the product acceptance link UAT, thereby reducing the number of code builds and ensuring quality.

[0036] Step S4: If the pre-release installation package passes the functional verification, UAT testing is performed to upgrade the system element to the UAT acceptance environment.

[0037] Specifically, if the pre-release installation package passes the functional verification, it is confirmed that it can be promoted to the UAT acceptance environment. During the system testing phase, once it is determined that the software version corresponding to a four-digit version number has passed the necessary tests and is considered stable (i.e., passed the above functional verification), this version will be used for subsequent user acceptance to ensure that the UAT test is based on a fully tested and relatively stable software version, thereby improving effectiveness and reliability. In this application, similar to the aforementioned ST test section, the UAT test also promotes the system elements in the pre-release installation package of the corresponding version number to the UAT acceptance environment first.

[0038] The upgraded system elements then enter a series of quality verifications, referring to Figure 5 , Figure 5 This is a schematic diagram of the UAT test process of the one-package-to-the-end method based on the main project provided in the embodiment of the present application. It can be seen that after the input parameter processing, the in-transit version check needs to be performed first. Specifically: Determine whether there is an in-transit version in the UAT acceptance environment; If the in-transit version exists in the UAT acceptance environment, all in-transit versions are removed.

[0039] Specifically, in the UAT acceptance environment, only one version under test is allowed. When a new version enters the UAT environment for testing, the previous historical version (i.e., the in-transit version) must have completed testing and ended the UAT status, or has been removed from the UAT environment.

[0040] Furthermore, a series of quality checks are carried out, which are similar to the checks in the above ST test and will not be repeated here. It is worth noting that in branch processing, the corresponding version that passes the quality check will synchronize the contents of the r branch (ie, release branch) of each component involved to the master branch.

[0041] More specifically, when performing UAT testing, it is necessary to determine whether the content being tested is the latest content. In the embodiment of the present application, checkpoints are used for judgment. It will be checked whether the release branch of the corresponding version being promoted is pulled from the latest checkpoint in the master branch. If not, the latest checkpoint needs to be synchronized to the release branch. This is because if the current release branch is not pulled from the latest checkpoint of the master, it means that the release branch may contain an old version of the code or is out of sync with the master branch. In this case, the latest tag needs to be synchronized to the release branch first, so that the release branch will contain the latest code and can be safely submitted to the user for acceptance testing.

[0042] Furthermore, combined with Figure 2 It can be seen that after completing the code build in the UAT acceptance environment, the following steps need to be performed: Based on the four-digit version number, upgrading the system elements of the pre-release installation package to the UAT acceptance environment; Determine whether the current system element content is consistent with the system element content recorded when the UAT test is executed. If they are consistent, determine that the system element meets the code building conditions.

[0043] Step S5, determining whether the system element meets the code building conditions, and if so, building the code on the UAT environment, where the code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment.

[0044] Specifically, if the currently promoted system element meets the series of inspection criteria involved in step S4, then the code construction judgment similar to the above code construction conditions is entered. The code construction can refer to Figure 2 The ST test environment is shown in the ST code building section.

[0045] Step S6, combining the system elements and the code on the UAT environment to obtain a final installation package, and using the master branch of the main project to maintain the final installation package.

[0046] Specifically, by rebuilding the code in the UAT acceptance environment and step by step upgrading the system elements corresponding to the code in the environment, the final installation package that can be used for production can be obtained. Among them, the master branch of the main project is used to maintain all the contents of the installation package under this version. These product contents are uniformly built and output by the master branch and can be released to production. Among them, when different branches are used in each environment to maintain all the contents under each version, a preset directory is used for placement, and based on the execution logic of steps S1 to S6 above, each updated version is superimposed one by one into the directory. When it is necessary to restore to any version, the system can be quickly restored by gradually obtaining the products from the low version to the high version, and because all the data (including code and configuration) that the system deployment depends on are maintained in a unified manner, the integrity of the system recovery is also guaranteed.

[0047] Furthermore, once the final installation package is modified, it is necessary to return to ST for testing to ensure the consistency of the installation package of the test content and the released content. Specifically: Determining whether there is any content change in the final installation package; If the final installation package has the content change, the final installation package is determined as the next installation package to be tested.

[0048] Specifically, once the final installation package is updated or bugs are fixed, it is necessary to return to the above step S1, that is, follow the principle that any changes after ST testing need to be re-executed to ensure the whole package.

[0049] Reference Figure 6 , Figure 6 : is a virtual structural diagram of a one-package-to-the-end device based on the main project provided by the present application. The second aspect of the present application provides a one-package-to-the-end device based on the main project, including: An ST test determination module is used to perform a development local verification on the installation package to be tested obtained after the update. If the installation package to be tested passes the development local verification, ST test is performed to promote the system elements in the installation package to be tested to the ST test environment; The ST test judgment module uses the dev branch of the main project to maintain the installation package to be tested after the update, and performs local development verification on the installation package to be tested. If the installation package to be tested passes the local development verification, ST test is executed to promote the system elements in the installation package to be tested to the ST test environment; The ST code building judgment module 100 is used to judge whether the system element meets the preset code building conditions. If it meets the code building conditions, the code on the ST environment is the code of the installation package to be tested reconstructed in the ST test environment; The ST installation package determination module 200 is used to determine the pre-release installation package in combination with the system elements and the code on the ST environment, use the release branch of the main project to maintain the pre-release installation package, and perform functional verification on the pre-release installation package; A UAT testing module 300 is used to perform UAT testing to upgrade the system element to a UAT acceptance environment if the pre-release installation package passes the functional verification; The UAT code building module 400 is used to determine whether the system element meets the code building condition, and if so, to build the code on the UAT environment, where the code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment; The UAT installation package determination module 500 is used to combine the system elements and the code on the UAT environment to obtain a final installation package, and use the master branch of the main project to maintain the final installation package.

[0050] The one-package-to-the-end device based on the main project described in the embodiment of the present application can execute the one-package-to-the-end method based on the main project provided in the above embodiment. The one-package-to-the-end device based on the main project has the corresponding functional steps and beneficial effects of the one-package-to-the-end method based on the main project described in the above embodiment. Please refer to the above embodiment of the one-package-to-the-end method based on the main project for details. The embodiment of the present application will not be repeated here.

[0051] The present application also provides an electronic device. Figure 7 , Figure 7It is a structural diagram of an electronic device provided in an embodiment of the present application, and the electronic device may include a processor and a memory, wherein the processor and the memory may be connected by a bus or other means. The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components and other chips, or a combination of the above-mentioned various types of chips. The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs, non-transient computer executable programs and modules, such as the program instructions / modules corresponding to the one-package-to-the-end method based on the main project in the embodiment of the present application. The processor executes various functional applications and data processing of the processor by running the non-transient software programs, instructions and modules stored in the memory, that is, the one-package-to-the-end method based on the main project in the above method embodiment is realized.

[0052] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required by at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. The one or more modules are stored in the memory, and when executed by the processor, a one-package-to-the-end method based on the main project in the above-mentioned method embodiment is executed. The specific details of the above-mentioned electronic device can be understood by corresponding to the corresponding relevant descriptions and effects in the above-mentioned method embodiment, and will not be repeated here. Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium, and the program, when executed, may include the processes of the embodiments of the above-mentioned methods. Among them, the storage medium can be a read-only memory (ROM), a random access memory (RAM), a flash memory (Flash Memory), a hard disk drive (HDD) or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above types of memory.

[0053] In the description provided herein, a large number of specific details are described. However, it is understood that the embodiments of the present application can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0054] Similarly, it should be understood that in order to streamline the present disclosure and aid in understanding one or more of the various inventive aspects, in the above description of the exemplary embodiments of the present application, the various features of the present application are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting the following intention: the claimed application requires more features than the features explicitly recited in each claim. More specifically, as reflected in the claims, the inventive aspects lie in less than all the features of the individual embodiments disclosed above. Therefore, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, with each claim itself serving as a separate embodiment of the present application.

[0055] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims.

Claims

1. A one-stop method based on the main project, characterized in that: The method comprises: The dev branch of the main project is used to maintain the updated installation package to be tested, and the installation package to be tested is verified locally. If the installation package to be tested passes the local verification, ST testing is performed to promote the system elements in the installation package to be tested to the ST test environment. Determine whether the system element meets the preset code building conditions, and if so, build the code on the ST environment, where the code on the ST environment is the code of the installation package to be tested reconstructed in the ST test environment; Determine a pre-release installation package in combination with the system elements and the code on the ST environment, use the release branch of the main project to maintain the pre-release installation package, and perform functional verification on the pre-release installation package; If the pre-release installation package passes the functional verification, UAT testing is performed to upgrade the system element to the UAT acceptance environment; Determine whether the system element meets the code building condition, and if so, build the code on the UAT environment, where the code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment; The system elements and the code on the UAT environment are combined to obtain a final installation package, and the master branch of the main project is used to maintain the final installation package.

2. The one-package-to-the-end method based on main engineering according to claim 1 is characterized in that: The step of performing ST testing to upgrade the system elements in the installation package to be tested to the ST test environment includes: Conduct multiple pre-checks on the system elements to be promoted to the ST test environment, including code quality check, configuration quality check, package dependency check, code review check, file resource quality check and self-test check; Determine whether any of the pre-checks fails. If not, determine that the pre-release installation package passes the pre-check. Otherwise, determine that the pre-release installation package fails the quality check and send a check failure prompt message.

3. The one-package-to-the-end method based on main engineering according to claim 2 is characterized in that: The step of determining whether the system element meets the preset code building condition comprises: Determine whether the current system element content is consistent with the system element content recorded when executing ST test. If consistent, determine that the system element meets the code building conditions. The system element content includes commit id, md5 of configuration file, and md5 of basic image configuration; If the current system element content is inconsistent with the system element content recorded when the ST test is executed, it is determined that the system element does not meet the code building conditions, code building is not allowed and returns to the ST test.

4. The one-package-to-the-end method based on main engineering according to claim 3 is characterized in that: The step of determining a pre-release installation package in combination with the system element and the code on the ST environment, and performing functional verification on the pre-release installation package comprises: Selecting a four-bit version to deploy the pre-release installation package, and performing the functional verification on the pre-release installation package based on the four-bit version; A test report corresponding to the function verification is outputted using a four-digit version number corresponding to the four-digit version to determine whether the pre-release installation package passes the function verification.

5. The one-package-to-the-end method based on main engineering according to claim 3 is characterized in that: The method further comprises: Based on the four-digit version number, upgrading the system elements of the pre-release installation package to the UAT acceptance environment; Determine whether the current system element content is consistent with the system element content recorded when the UAT test is executed. If they are consistent, determine that the system element meets the code building conditions.

6. The one-package-to-the-end method based on main engineering according to claim 1 is characterized in that: If the pre-release installation package passes the functional verification, before the step of performing UAT testing to promote the system element to the UAT acceptance environment, the method includes: Determine whether there is an in-transit version in the UAT acceptance environment; If the in-transit version exists in the UAT acceptance environment, all in-transit versions are removed.

7. The one-package-to-the-end method based on main engineering according to claim 1 is characterized in that: After the step of combining the system elements and the code on the UAT environment to obtain a final installation package, the method includes: Determining whether there is any content change in the final installation package; If the final installation package has the content change, the final installation package is determined as the next installation package to be tested.

8. A one-pack device based on the main project, characterized in that: include: The ST test judgment module uses the dev branch of the main project to maintain the installation package to be tested after the update, and performs local development verification on the installation package to be tested. If the installation package to be tested passes the local development verification, ST test is executed to promote the system elements in the installation package to be tested to the ST test environment; An ST code building judgment module is used to judge whether the system element meets the preset code building conditions. If it meets the code building conditions, the code on the ST environment is the code of the installation package to be tested reconstructed in the ST test environment; An ST installation package determination module, used to determine a pre-release installation package in combination with the system elements and the code on the ST environment, use the release branch of the main project to maintain the pre-release installation package, and perform functional verification on the pre-release installation package; A UAT testing module is used to perform UAT testing to upgrade the system element to a UAT acceptance environment if the pre-release installation package passes the functional verification; A UAT code building module is used to determine whether the system element meets the code building conditions, and if so, to build the code on the UAT environment, where the code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment; The UAT installation package determination module is used to combine the system elements and the code on the UAT environment to obtain the final installation package, and use the master branch of the main project to maintain the final installation package.

9. An electronic device, characterized in that: include: at least one processor and at least one memory, wherein the memory has computer-readable instructions stored thereon; The computer-readable instructions are executed by one or more of the processors, so that the electronic device implements the one-package-to-the-bottom method based on the main project as described in any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that: The computer-readable instructions are executed by a processor to implement the one-package-to-the-bottom method based on the main project as claimed in any one of claims 1 to 7.

Citation Information

Patent Citations

  • Code detection method and device

    CN104598384A

  • Continuous integration and continuous delivery method and device, electronic equipment and storage medium

    CN112506525A

  • Code branch management method and device, equipment and storage medium

    CN113741948A

  • Software processing method and system based on DevSecOps platform

    CN114610322A

  • Smart tool for enterprise-wide software integration and deployment

    US20190243742A1