Method and device for implementing one package to end method based on main project, equipment and storage medium

Abstract

The application relates to the technical field of product management, in particular to a one-package-to-end method, device and equipment based on a main project and a storage medium. The method comprises the following steps: adopting a dev branch to maintain a to-be-tested installation package, and performing development local verification; if the development local verification is passed, ST testing is performed; it is judged whether system elements meet code construction conditions; if yes, code on an ST environment is constructed; a pre-release installation package is determined in combination with the system elements and the code on the ST environment; a release branch is adopted to maintain the pre-release installation package, and function verification is performed; if the function verification is passed, UAT testing is performed; it is judged whether the code meets the code construction conditions; if yes, code on a UAT environment is constructed; a final installation package is obtained in combination with the system elements and the code on the UAT environment; and the master branch is adopted to maintain the final installation package. The application matches the code with the environment configuration for management, realizes quick system pulling up during deployment of the environment, and achieves the beneficial effect of quick recovery of the deployment system.

Description

Technical Field

[0001] This application relates to the technical field of product management, and in particular to a method, apparatus, equipment and storage medium based on a main project. Background Technology

[0002] Artifact management is a critical activity for ensuring the correctness, integrity, and security of each version and build during software delivery. Currently, the mainstream artifact management method involves centrally managing all artifacts in an artifact repository. However, when all artifacts are stored in the repository without effective version management, finding the complete artifact associated with a specific historical version of the system becomes difficult and time-consuming over time. In practice, different vendors may have different business needs and operating models, thus requiring different system functions and features to support their businesses. In other words, different vendors require different system versions. The lack of a system product that can be quickly retrieved based on historical versions can cause inconvenience. Therefore, artifact-based rapid recovery and deployment systems are crucial, allowing organizations to quickly restore to a known good state in the face of failures or disasters, thereby minimizing the impact of business interruption.

[0003] In conclusion, how to realize the function of rapid recovery and deployment system based on artifacts in artifact management is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, this application provides a method, apparatus, device and storage medium based on the main project, which adopts a one-stop solution to manage the code and the corresponding environment configuration, thereby achieving the beneficial effect of quickly restoring the system and corresponding data when deploying the environment, and achieving the effect of quickly restoring the deployed system based on the artifact.

[0005] The technical solution adopted by this application to solve its technical problem is:

[0006] Firstly, this application provides a method for implementing a single package based on the main project, the method comprising:

[0007] The updated installation package to be tested is maintained using the dev branch of the main project, and the installation package to be tested is verified locally in the development environment. If the installation package to be tested passes the local verification, ST test is executed to promote the system elements in the installation package to the ST test environment.

[0008] Determine whether the system element meets the preset code building conditions. If it meets the code building conditions, build the code in the ST environment. The code in the ST environment is the code of the installation package to be tested that has been reconstructed in the ST test environment.

[0009] The pre-release installation package, constructed by combining the system elements and the code on the ST environment, is maintained using the release branch of the main project, and its functionality is verified.

[0010] If the pre-release installation package passes the functional verification, then perform UAT testing to upgrade the system elements to the UAT acceptance environment;

[0011] Determine whether the system element meets the preset code building conditions. If it meets the code building conditions, build the code on the UAT environment. The code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment.

[0012] By combining the system elements and the code on the UAT environment, the final installation package is obtained, and the final installation package is maintained using the master branch of the main project.

[0013] Optionally, the step of performing ST testing to upgrade the system elements in the installation package to be tested to the ST test environment includes:

[0014] Multiple pre-tests are performed on the system elements to be promoted to the ST test environment, including code quality checks, configuration quality checks, package dependency checks, code review checks, file resource quality checks, and self-test checks.

[0015] Determine if any of the pre-release checks failed. If not, determine if the pre-release installation package passed the pre-release check; otherwise, determine if the pre-release installation package failed the quality check and send a check failure message.

[0016] Optionally, the step of determining whether the system element meets the preset code construction conditions includes:

[0017] Determine whether the current system element content is consistent with the system element content recorded when ST test is performed. If they are consistent, determine that the system element meets the code build conditions. The system element content includes commit id, configuration file md5, and base image configuration md5.

[0018] If the current system element content is inconsistent with the system element content recorded when executing ST test, then the system element is determined to not meet the code construction conditions, code construction is not allowed, and ST test is returned.

[0019] Optionally, the step of determining the pre-release installation package by combining the system elements and the code on the ST environment, and performing functional verification on the pre-release installation package includes:

[0020] Select the four-bit version to deploy the pre-release installation package, and verify the functionality of the pre-release installation package based on the four-bit version;

[0021] The test report corresponding to the function verification is output using the four-digit version number corresponding to the four-digit version, in order to determine whether the pre-release installation package has passed the function verification.

[0022] Optionally, the method further includes:

[0023] Based on the four-digit version number, the system elements of the pre-release installation package are promoted to the UAT acceptance environment;

[0024] Determine whether the current system element content is consistent with the system element content recorded when performing UAT testing. If they are consistent, then the system element is determined to meet the code construction conditions.

[0025] Optionally, before the step of performing UAT testing to upgrade the system elements to the UAT acceptance environment if the pre-release installation package passes the functional verification, the method includes:

[0026] Determine if a version is in transit in the UAT acceptance environment;

[0027] If the in-transit version exists in the UAT acceptance environment, then remove all in-transit versions.

[0028] Optionally, after the step of combining the system elements and the code on the UAT environment to obtain the final installation package, the method includes:

[0029] Determine whether there are any changes to the content of the final installation package;

[0030] If the final installation package has any changes to its contents, then the final installation package will be selected as the next installation package to be tested.

[0031] Secondly, this application provides a one-stop solution device based on the main project, comprising:

[0032] The ST test decision module uses the dev branch of the main project to maintain the updated installation package to be tested and performs local development verification on the installation package to be tested. If the installation package to be tested passes the local development verification, the ST test is executed to promote the system elements in the installation package to the ST test environment.

[0033] The ST code building judgment module is used to determine whether the system element meets the preset code building conditions. If it meets the code building conditions, the code on the ST environment is built. The code on the ST environment is the code of the installation package to be tested that has been reconstructed in the ST test environment.

[0034] The ST installation package determination module is used to determine the pre-release installation package by combining the system elements and the code on the ST environment. It uses the release branch of the main project to maintain the pre-release installation package and to perform functional verification on the pre-release installation package.

[0035] The UAT testing module is used to perform UAT testing to upgrade the system elements to the UAT acceptance environment if the pre-release installation package passes the functional verification.

[0036] The UAT code building module is used to determine whether the system element meets the code building conditions. If it meets the code building conditions, it builds the code on the UAT environment. The code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment.

[0037] 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 maintain the final installation package using the master branch of the main project.

[0038] Thirdly, this application provides an electronic device, including: at least one processor and at least one memory, wherein computer-readable instructions are stored on the memory;

[0039] The computer-readable instructions are executed by one or more of the processors, causing the electronic device to implement the above-described main project-based one-package method.

[0040] Fourthly, this application provides a storage medium in which the computer-readable instructions are executed by a processor to implement the above-described method of wrapping everything from the main project.

[0041] The beneficial effects of this application are as follows: After modifying the installation package, a test installation package is obtained. The test installation package first enters the development self-test environment (i.e., SE environment) for local development verification. After confirming local development verification, the system elements of the test installation package are promoted to the ST test environment (i.e., ST environment) through ST test submission. Then, the code in the test installation package 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.

[0042] If the pre-release installation package passes functional verification, the system elements in the pre-release installation package are promoted to the UAT acceptance environment (i.e., the UAT environment), and it is determined whether they meet the code build conditions. If they do, the code is refactored, and the code content is consistent with the code content at the start of testing and after testing verification. Finally, the final installation package is obtained by combining the code and the system elements of the UAT acceptance environment. In this embodiment, the code build conditions are similar to the code build conditions, that is, it is determined whether the system elements recorded during the last test are consistent with the system elements in the current environment. If they are consistent, the build conditions are met.

[0043] Specifically, the release branch of the main project is used to maintain all artifacts in the test installation package of the development self-testing environment; the release branch of the main project is used to maintain all artifacts in the pre-release installation package of the ST test environment; and the master branch of the main project is used to maintain all artifacts in the final installation package of the UAT acceptance environment. By adopting the above technical solution, this application includes at least the following beneficial effects:

[0044] 1. After modifying the installation package, the installation package to be updated is obtained. It follows the upgrade path from the development self-testing environment to the ST test environment to the UAT acceptance environment. In each upgrade, it is checked whether the system elements of the code to be built correspond to the system elements submitted for testing in the last test. This ensures that the final releaseable installation package is consistent with the content of the installation package to be tested in the test, thus ensuring that the package is consistent from start to finish.

[0045] 2. Because the installation package for each environment (which includes all artifacts for each system version) is maintained, when it is necessary to restore any version, the code and system elements of the corresponding version can be obtained from the maintained content, and the corresponding installation package can be obtained to quickly restore the system. Attached Figure Description

[0046] Figure 1 This is a flowchart illustrating the "one-package-to-the-end" method based on the main project provided in this application embodiment;

[0047] Figure 2 This is a schematic diagram of the specific process of the "one package to the end" method based on the main project provided in the embodiments of this application;

[0048] 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 embodiments of this application;

[0049] Figure 4 This is a flowchart illustrating the quality inspection process in the "one-package-to-the-end" method based on the main project provided in this application embodiment.

[0050] Figure 5This is a schematic diagram of the UAT testing process of the one-package-to-the-end method based on the main project provided in the embodiments of this application;

[0051] Figure 6 This is a schematic diagram of the virtual structure of the all-in-one device based on the main project provided in this application;

[0052] Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0053] The present application will be further described below with reference to the accompanying drawings and embodiments.

[0054] The following will clearly and completely describe the concept, specific structure, and resulting technical effects of this application in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of this application. Obviously, the described embodiments are only a part of the embodiments of this application, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this application can be combined interactively without contradicting each other.

[0055] When the installation package is modified, the modified installation package will be identified as the installation package to be tested and will enter the SE environment used for development, self-testing and integration debugging. The following steps also involve the ST test environment (i.e., ST environment) and the UAT acceptance environment (i.e., UAT environment). The SE environment is used to perform local development verification of the current version, the ST environment is used to perform a series of quality and functional verifications on the version that has been verified locally, and the UAT environment is used to accept all artifacts of the version after verification in the SE environment and obtain an installation package that can be released to production.

[0056] Reference Figure 1 , Figure 2 , Figure 1 This is a flowchart illustrating the "one-package-to-the-end" method based on the main project provided in this application embodiment. Figure 2 This is a schematic flowchart illustrating the comprehensive package method based on the main project provided in this application embodiment. The comprehensive package method based on the main project provided in this application embodiment specifically includes the following steps, which will be described in detail below:

[0057] Step S1: The updated installation package to be tested is maintained using the dev branch of the main project, and the installation package to be tested is verified locally in the development environment. If the installation package to be tested passes the local verification, ST test is executed to promote the system elements in the installation package to the ST test environment.

[0058] Specifically, the main project stores artifacts, including the results of code compilation and other data such as configurations; the dev branch of the main project is used to develop new features or fix bugs. Development on the dev branch is usually experimental and has not been fully tested. Once the development is completed and verified, it is merged into other more stable branches of the main project (for example, in this embodiment, after local development and verification are completed, the contents of the dev branch are synchronized to the release branch of the main project).

[0059] The installation package to be tested refers to a modified installation package that has not yet completed testing. It includes all the code and system elements corresponding to this version. System elements refer to all content other than code, such as configuration, project, and SQL scripts. Local development verification refers to the testing and verification of the software in the developer's local environment, usually to ensure that the basic functions and performance of the software meet expectations and that there are no obvious errors. Submission to Software Testing (ST) refers to submitting the installation package, which has been verified locally, to the software testing department to ensure its functionality.

[0060] More specifically, for example, suppose a product has feature A. In the SE environment for development and self-testing, a three-digit version number corresponding to only having feature A will be generated, such as 1.0.0. If feature B needs to be added to the product based on having feature A, then for the content that has been developed but not yet tested, having both feature A and feature B, a corresponding three-digit version number will be generated, such as 1.0.1, thereby distinguishing the historical versions of the product.

[0061] Step S2: Determine whether the system element meets the preset code building conditions. If it meets the code building conditions, build the code in the ST environment. The code in the ST environment is the code of the installation package to be tested that has been reconstructed in the ST test environment.

[0062] In the development of any three-digit version, there may be multiple changes and tests. Each test may fix different bugs. Therefore, each change (including but not limited to changes in code content, configuration files, etc.) needs to be assigned a four-digit version number to avoid the situation where the version number is not unique due to multiple changes.

[0063] Specifically, in this embodiment of the application, the step of determining whether the system element meets the preset code construction conditions includes:

[0064] Determine whether the current system element content is consistent with the system element content recorded when ST test is performed. If they are consistent, determine that the system element meets the code build conditions. The system element content includes commit id, configuration file md5, and base image configuration md5.

[0065] If the current system element content is inconsistent with the system element content recorded when executing ST test, then the system element is determined to not meet the code construction conditions, code construction is not allowed, and ST test is returned.

[0066] Specifically, in the ST testing environment, new features may require multiple tests to implement, which may involve multiple modifications. Therefore, the code build conditions must 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 simpler terms, assuming development is for a three-digit version number 1.0.0, there may be multiple changes and test submissions. Each test submission will address different bugs. The first test submission might generate a four-digit version number 1.0.0.0, and the second might generate a four-digit version number 1.0.0.1. At least one aspect of these two test submissions will have changed.

[0067] More specifically, refer to Figure 2 , Figure 2 The code build verification in the system includes commit ID verification, configuration file MD5 verification, base image MD5 verification, version selection, and automatic updates and upgrades. Specifically:

[0068] If any of the following discrepancies exist between the current test submission and the previous test submission: a different commit ID, a different MD5 hash of the configuration file, a different MD5 hash of the base image configuration, or a different four-digit version number, then the code build conditions are not met. If the code build conditions are not met, code build is not allowed, and the version number is adjusted accordingly. In this embodiment, if there is a discrepancy, this discrepancy is returned to the test submission, and an updated version number is generated compared to the previous test submission version number, for example, from 1.0.0.0 to 1.0.0.1.

[0069] More specifically, for packages that depend on external systems, a four-digit version number is required by default. If this is the first time submitting for testing, version number 1 can be selected. Subsequent modifications require resubmission and a new four-digit version number. Specifically, packages that depend on external systems refer to third-party libraries or tools used during development. Once an external package is modified, whether by directly modifying the source code or through configuration parameters, testing must be performed again, and the version number must be updated accordingly to four digits.

[0070] Step S3: Combine the system elements and the code on the ST environment to determine the pre-release installation package, 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.

[0071] Specifically, by combining the code rebuilt in the ST testing environment with the corresponding version of system content, an installation package for functional verification can be obtained, namely the pre-release installation package proposed in this application. For each version number, all artifacts under the installation package are maintained uniformly using the release branch of the main project. In the ST testing environment, a series of functional and quality verifications are also performed on the installation package obtained by combining the system elements of the corresponding version after building the code. Functional verification refers to verifying whether the functions to be implemented by the code are feasible, while quality verification specifically includes:

[0072] Reference Figure 3 , Figure 3 This is a schematic diagram of the ST testing process based on the main project's end-to-end method provided in the embodiments of this application. When a version is tested using ST (e.g., Figure 3 After submitting the ST test (as shown), a series of operations are performed. Specifically: Input parameter processing refers to the processing of input parameters, including verification, formatting, or conversion, to ensure they meet the requirements of subsequent steps; Deploying test data involves applying the above input parameters; Quality checking involves detecting the quality of the input parameters; Changing the version status refers to adjusting the status of the version based on the results of the quality check, including but not limited to under development, pending testing, pending release, and released; Artifact advancement refers to the advancement to the UAT environment; Post-test extension refers to additional processing or optimization that may be performed after artifact creation 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.

[0073] The returned test results include Figure 2 The options shown include selecting the four-bit version for deployment, testing, and outputting test reports. Rotating the four-bit version for deployment refers to deploying the installation package in the test system using the four-bit version for testing, and returning the test report as the test result.

[0074] More specifically, the step of performing ST testing to upgrade system elements in the installation package under test to the ST test environment includes:

[0075] Multiple pre-tests are performed on the system elements to be promoted to the ST test environment, including code quality checks, configuration quality checks, package dependency checks, code review checks, file resource quality checks, and self-test checks.

[0076] Determine if any of the pre-release checks failed. If not, determine if the pre-release installation package passed the pre-release check; otherwise, determine if the pre-release installation package failed the quality check and send a check failure message.

[0077] Specifically, refer to Figure 4 , Figure 4 This is a flowchart illustrating the quality inspection process in the "one-package-to-the-end" method based on the main project provided in this application embodiment. Combined with... Figure 4 As can be seen, each of the multiple quality checks requires a whitelist check to determine whether the corresponding quality meets the standard. If the standard is not met, the corresponding reason for the quality failure and the modification method are displayed. Ultimately, only when all quality checks pass will the quality testing step of the system element be considered passed; otherwise, the test is confirmed to have failed, and a corresponding check failure message can be sent. In this embodiment, only system elements that pass the quality checks can enter the code building section, i.e., 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 implement the required functions, thereby determining whether it can advance to the product acceptance stage (UAT), thus reducing the number of code builds and ensuring quality compliance.

[0078] Step S4: If the pre-release installation package passes the functional verification, then perform UAT testing to upgrade the system elements to the UAT acceptance environment.

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

[0080] The upgraded system elements then underwent a series of quality verifications, referring to... Figure 5 , Figure 5 This is a schematic diagram of the UAT testing process for the "one-package-to-the-end" method based on the main project provided in this application embodiment. As can be seen, after the input parameter processing, the in-transit version check is first required. Specifically:

[0081] Determine if a version is in transit in the UAT acceptance environment;

[0082] If the in-transit version exists in the UAT acceptance environment, then remove all in-transit versions.

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

[0084] Further, a series of quality checks are performed, similar to those in the ST testing process described above, and will not be repeated here. It is worth noting that during branch processing, the corresponding version that passes the quality checks will synchronize the contents of the r branches (i.e., release branches) of each involved component to the master branch.

[0085] More specifically, when submitting UAT (User Acceptance Testing) code for testing, it's necessary to determine if the submitted content is up-to-date. In this embodiment, checkpoints are used for this determination. The system checks whether the release branch of the 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 isn't pulled from the latest checkpoint in master, it means the release branch might contain older code or be out of sync with the master branch. In this case, the latest tag needs to be synchronized to the release branch first. This ensures the release branch contains the latest code and can be safely submitted to users for acceptance testing.

[0086] Furthermore, combined Figure 2 As can be seen, after completing the code build in the UAT acceptance environment, the following steps need to be performed:

[0087] Based on the four-digit version number, the system elements of the pre-release installation package are promoted to the UAT acceptance environment;

[0088] Determine whether the current system element content is consistent with the system element content recorded when performing UAT testing. If they are consistent, then the system element is determined to meet the code construction conditions.

[0089] Step S5: Determine whether the system element meets the code building conditions. If it meets the code building conditions, build the code on the UAT environment. The code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment.

[0090] Specifically, if the currently promoted system element meets the series of check criteria involved in step S4, then it enters a code construction judgment process similar to the code construction conditions described above. The code construction can refer to... Figure 2 The code building section in the ST test environment is shown.

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

[0092] Specifically, by rebuilding the code in the UAT acceptance environment and progressively upgrading the corresponding system elements in that environment, a final production-ready installation package can be obtained. The master branch of the main project maintains all content of the installation package for that version. These artifacts are uniformly built and output from the master branch and can be deployed to production. When maintaining all content for each version using different branches in each environment, a preset directory is used, and based on the execution logic of steps S1 to S6, each updated version is added to the directory one by one. When it is necessary to restore to any version, the system can be quickly restored by progressively acquiring artifacts from lower to higher versions. Furthermore, because all data (including code and configuration) that the system deployment depends on is maintained uniformly, the integrity of the system restoration is also guaranteed.

[0093] Furthermore, any changes to the final installation package must be submitted back to ST for testing to ensure consistency between the test content and the released installation package. Specifically:

[0094] Determine whether there are any changes to the content of the final installation package;

[0095] If the final installation package has any changes to its contents, then the final installation package will be selected as the next installation package to be tested.

[0096] Specifically, if the final installation package is updated or bugs are fixed in the future, it is necessary to return to step S1 above. That is, the principle of re-running ST testing is required for any changes after ST testing, to ensure that the package is consistent from start to finish.

[0097] Reference Figure 6 , Figure 6This is a virtual structural diagram of the all-in-one package device based on the main project provided in this application. A second aspect of this application provides an all-in-one package device based on the main project, comprising:

[0098] The ST test evaluation module is used to perform local development verification on the updated installation package to be tested. If the installation package to be tested passes the local development verification, ST test is executed to upgrade the system elements in the installation package to the ST test environment.

[0099] The ST test decision module uses the dev branch of the main project to maintain the updated installation package to be tested and performs local development verification on the installation package to be tested. If the installation package to be tested passes the local development verification, the ST test is executed to promote the system elements in the installation package to the ST test environment.

[0100] ST code building judgment module 100 is used to determine whether the system element meets the preset code building conditions. If it meets the code building conditions, the code on the ST environment is built. The code on the ST environment is the code of the installation package to be tested that has been reconstructed in the ST test environment.

[0101] ST installation package determination module 200 is used to determine the pre-release installation package by combining the system elements and the code on the ST environment, maintain the pre-release installation package using the release branch of the main project, and perform functional verification on the pre-release installation package;

[0102] UAT testing module 300 is used to perform UAT testing to upgrade the system elements to the UAT acceptance environment if the pre-release installation package passes the functional verification.

[0103] UAT code building module 400 is used to determine whether the system element meets the code building conditions. If it meets the code building conditions, it builds the code on the UAT environment. The code on the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment.

[0104] The UAT installation package determination module 500 is used to combine the system elements and the code on the UAT environment to obtain the final installation package, and maintain the final installation package using the master branch of the main project.

[0105] The "one-package-to-the-end" device based on the main project described in this application embodiment 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. For details, please refer to the embodiments of the "one-package-to-the-end" method based on the main project described above. The embodiments of this application will not be repeated here.

[0106] This application also provides an electronic device, please refer to... Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include a processor and a memory, which can be connected via 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 (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips. The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory 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 embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the "one-package-to-the-end" method based on the main project in the above method embodiments.

[0107] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. One or more modules are stored in the memory and, when executed by the processor, perform the "one-package-to-the-end" method based on the main project as described in the above method embodiments. Specific details of the above electronic device can be understood by referring to the corresponding descriptions and effects in the above method embodiments, and will not be repeated here. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium may be a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), etc.; the storage medium may also include a combination of the above types of memory.

[0108] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0109] Similarly, it should be understood that, in order to streamline this disclosure and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together in a single embodiment, figure, or description thereof. However, this approach to disclosure should not be construed as reflecting an intention that the claimed application requires more features than expressly recited in each claim. Rather, as reflected in the claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0110] It should be noted that the above embodiments are illustrative of this application and not restrictive of this application, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims.

Claims

1. A method based on the main project, characterized in that: The method includes: The updated installation package to be tested is maintained using the dev branch of the main project, and the installation package to be tested is verified locally in development. If the installation package to be tested passes the local verification, ST testing is executed to promote the system elements in the installation package to the ST test environment. The installation package to be tested includes all the code and system elements corresponding to the version. The system elements refer to all the content other than the code corresponding to the version, including configuration, project and SQL script. Determine whether the system element meets the preset code building conditions. If it meets the code building conditions, build the code in the ST environment. The code in the ST environment is the code of the installation package to be tested that has been reconstructed in the ST test environment. The pre-release installation package is determined by combining the system elements and the code on the ST environment. The pre-release installation package is maintained by the release branch of the main project, and the pre-release installation package is functionally verified. If the pre-release installation package passes the functional verification, then perform UAT testing to upgrade the system elements to the UAT acceptance environment; Determine whether the system element meets the code building conditions. If it does, build the code in the UAT environment. The code in the UAT environment is the code of the pre-release installation package reconstructed in the UAT acceptance environment. By combining the system elements and the code on the UAT environment, the final installation package is obtained, and the final installation package is maintained using the master branch of the main project; In this process, different branches are used in each environment to maintain all content under each version. When it is necessary to restore to any version, artifacts are obtained step by step from the lower version to the higher version. Prior to the step of performing ST testing to advance the system elements in the installation package to be tested to the ST test environment, the following are included: Multiple pre-tests are performed on the system elements to be promoted to the ST test environment, including code quality checks, configuration quality checks, package dependency checks, code review checks, file resource quality checks, and self-test checks. Determine if any of the pre-release checks fails. If not, determine if the pre-release installation package passes the pre-release check. Otherwise, determine if the pre-release installation package fails the quality check and send a check failure message. The step of determining whether the system element meets the preset code construction conditions includes: Determine whether the current system element content is consistent with the system element content recorded when ST test is performed. If they are consistent, determine that the system element meets the code build conditions. The system element content includes commit id, configuration file md5, and base image configuration md5. If the current system element content is inconsistent with the system element content recorded when executing ST test, then the system element is determined to not meet the code construction conditions, code construction is not allowed, and ST test is returned.

2. The method of using a single package based on the main project according to claim 1, characterized in that, The steps of determining the pre-release installation package by combining the system elements and the code on the ST environment, and performing functional verification on the pre-release installation package include: Select the four-bit version to deploy the pre-release installation package, and verify the functionality of the pre-release installation package based on the four-bit version; The test report corresponding to the function verification is output using the four-digit version number corresponding to the four-digit version, in order to determine whether the pre-release installation package has passed the function verification.

3. The method of using a single package based on the main project according to claim 2, characterized in that, The method further includes: Based on the four-digit version number, the system elements of the pre-release installation package are promoted to the UAT acceptance environment; Determine whether the current system element content is consistent with the system element content recorded when performing UAT testing. If they are consistent, then the system element is determined to meet the code construction conditions.

4. The method of using a single package based on the main project according to claim 1, characterized in that, Before the step of performing UAT testing to upgrade the system elements to the UAT acceptance environment if the pre-release installation package passes the functional verification, the method includes: Determine if a version is in transit in the UAT acceptance environment; If the in-transit version exists in the UAT acceptance environment, then remove all in-transit versions.

5. The method of using a single package based on the main project according to claim 1, characterized in that, After the step of combining the system elements and the code on the UAT environment to obtain the final installation package, the method includes: Determine whether there are any changes to the content of the final installation package; If the final installation package has any changes to its contents, then the final installation package will be selected as the next installation package to be tested.

6. A one-package-to-the-end device based on the main project, characterized in that, include: The ST test evaluation module uses the dev branch of the main project to maintain the updated installation package to be tested 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 installation package to be tested includes all the code and system elements corresponding to the version. The system elements refer to all the content of the version except for the code, including configuration, project and SQL script. The ST code building judgment module is used to determine whether the system element meets the preset code building conditions. If it meets the code building conditions, the code on the ST environment is built. The code on the ST environment is the code of the installation package to be tested that has been reconstructed in the ST test environment. The ST installation package determination module is used to determine the pre-release installation package by combining the system elements and the code on the ST environment. The pre-release installation package is maintained by the release branch of the main project, and the pre-release installation package is functionally verified. The UAT testing module is used to perform UAT testing to upgrade the system elements to the UAT acceptance environment if the pre-release installation package passes the functional verification. The UAT code building module is used to determine whether the system element meets the code building conditions. If it meets the code building conditions, it builds the code on the UAT environment. 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 maintain the final installation package using the master branch of the main project; In this process, different branches are used in each environment to maintain all content under each version. When it is necessary to restore to any version, artifacts are obtained step by step from the lower version to the higher version. Prior to the step of performing ST testing to advance the system elements in the installation package to be tested to the ST test environment, the following are included: Multiple pre-tests are performed on the system elements to be promoted to the ST test environment, including code quality checks, configuration quality checks, package dependency checks, code review checks, file resource quality checks, and self-test checks. Determine if any of the pre-release checks fails. If not, determine if the pre-release installation package passes the pre-release check. Otherwise, determine if the pre-release installation package fails the quality check and send a check failure message. The step of determining whether the system element meets the preset code construction conditions includes: Determine whether the current system element content is consistent with the system element content recorded when ST test is performed. If they are consistent, determine that the system element meets the code build conditions. The system element content includes commit id, configuration file md5, and base image configuration md5. If the current system element content is inconsistent with the system element content recorded when executing ST test, then the system element is determined to not meet the code construction conditions, code construction is not allowed, and ST test is returned.

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

8. 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-end method based on the main project as described in any one of claims 1 to 5.

Images