Policy-based version compilation and deployment method and device

CN114489704BActive Publication Date: 2026-08-18INDUSTRIAL AND COMMERCIAL BANK OF CHINA
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202210134951.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-02-14
Publication Date
2026-08-18
Estimated Expiration
2042-02-14

AI Technical Summary

Technical Problem

[0003]然而这种容器化编译部署的方式,存在如下问题:1)基于jekins的部署流程中,由于工具之间缺乏连通性大量依赖人工配置,部署可靠性低且维护成本高;2)在修改代码量较少时进行全模块部署,编译时间长、生成的镜像文件大、传输和部署时间长,造成资源浪费,此时未发生修改的模块的测试工作也需要暂停,等待部署成功才能继续,增加迭代压力

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114489704B_ABST
    Figure CN114489704B_ABST
Patent Text Reader

Abstract

The disclosure provides a policy-based version compiling and deploying method, which can be applied to the technical field of cloud computing. The policy-based version compiling and deploying method comprises: in response to an input operation of a user, obtaining a to-be-deployed engineering module name and a module root directory; generating a compiling policy and a deploying policy according to the engineering module name and the module root directory; extracting new code information in a code management tool; compiling an incremental version package according to the new code information and the compiling policy; merging the incremental version package and a current version package to generate a delivery version package; and deploying the delivery version package according to the deploying policy. The disclosure also provides a policy-based version compiling and deploying device, equipment, a storage medium and a program product.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing, specifically to the field of version testing and deployment technology, and more specifically to a policy-based version compilation and deployment method, apparatus, device, storage medium, and program product. Background Technology

[0002] The existing typical build and deployment process is based on the development module build process. Configuration personnel manage the project in modules, developers commit modified code to the Git repository, configuration personnel analyze the module to which the code belongs, write the module's build and deployment strategy, then Jenkins builds the source code, downloads the dependency packages, calls the corresponding module's build strategy, and compiles to generate a new image. The deployment tool retrieves the image, calls the deployment strategy, and deploys it to the test environment.

[0003] However, this containerized compilation and deployment method has the following problems: 1) In the deployment process based on Jenkins, due to the lack of connectivity between tools, it relies heavily on manual configuration, resulting in low deployment reliability and high maintenance costs; 2) When deploying a full module with only a small amount of code modification, the compilation time is long, the generated image file is large, and the transmission and deployment time are long, resulting in wasted resources. At this time, the testing work of the modules that have not been modified also needs to be paused and wait for the deployment to succeed before it can continue, increasing the iteration pressure. Summary of the Invention

[0004] In view of the above issues, this disclosure provides policy-based version compilation and deployment methods, apparatus, devices, media, and program products.

[0005] According to the first aspect of this disclosure, a policy-based version compilation and deployment method is provided, comprising:

[0006] In response to user input, obtain the name of the module to be deployed and the module's root directory;

[0007] Generate compilation and deployment strategies based on the project module name and the module root directory;

[0008] Extract newly added code information from the code management tool;

[0009] An incremental version package is generated based on the newly added code information and the compilation strategy;

[0010] Merge the incremental version package and the current version package to generate the delivery version package; and

[0011] Deploy the delivery version package according to the deployment strategy described above.

[0012] According to embodiments of this disclosure, the step of compiling and generating an incremental version package based on the newly added code information and the compilation strategy includes:

[0013] The project category for modifying the root directory of the code is determined based on the newly added code information;

[0014] Once the project category is determined to be the basic project category, a full compilation is performed to generate the first incremental version package.

[0015] Once the project category is determined to be an application project, the newly added code is incrementally compiled to generate a second incremental version package; and

[0016] Once the project category is determined to be configuration information, the project to which the configuration file belongs is determined based on the configuration directory, and the compilation and deployment method corresponding to the project to which the configuration file belongs is called to generate the third incremental version package.

[0017] According to embodiments of this disclosure, it further includes:

[0018] Obtain historical deployment information and module dependency information for the module;

[0019] The module deployment path is determined based on the module's historical deployment information, module dependency information, and Dijkstra's pull-heap optimization algorithm; and

[0020] Deploy each module according to the module deployment path described above.

[0021] According to embodiments of this disclosure, the historical deployment information of the module includes the average deployment time of the module, the module deployment anomaly rate, and the average resource utilization rate of the module deployment. The step of determining the module deployment path based on the historical deployment information, the module dependency information, and the Dijkstra heap optimization algorithm includes:

[0022] Determine the dependency depth sequence based on the module dependency information;

[0023] The average module deployment cost is determined based on the average deployment time of the module, the module deployment anomaly rate, the average resource utilization rate of the module deployment, and the dependency depth sequence; and

[0024] The module deployment path is determined based on the average module deployment cost, current resource usage, and Dijkstra's stellar heap optimization algorithm.

[0025] According to embodiments of this disclosure, the method further includes:

[0026] Once deployment failure is confirmed, obtain the failure keywords;

[0027] The failure keywords are matched with keywords in the problem database.

[0028] If a match is successful, the email interface is invoked to send failure details, which include a failure code, a problem description, and detailed build logs; and

[0029] If a match fails, the deployment failure log will be sent via the email interface.

[0030] According to embodiments of this disclosure, the method further includes:

[0031] Once the deployment anomaly is confirmed and fixed, the breakpoint re-emergence mechanism is activated to continue the deployment process.

[0032] According to embodiments of this disclosure, the step of initiating the breakpoint re-emergence mechanism to continue the deployment process includes:

[0033] Retrieve the policy number and deployment program list corresponding to the deployment failure from the deployment failure log; and

[0034] Continue the deployment process based on the strategy number and deployment procedure list.

[0035] According to embodiments of this disclosure, it further includes:

[0036] Configure the server information for the test environment according to the configuration file.

[0037] A second aspect of this disclosure provides a policy-based version compilation and deployment apparatus, comprising: an acquisition module, configured to acquire, in response to user input, the name of the module to be deployed and the module root directory;

[0038] The strategy generation module is used to generate compilation and deployment strategies based on the project module name and the module root directory.

[0039] The extraction module is used to extract newly added code information from the code management tool;

[0040] The compilation module is used to compile and generate an incremental version package based on the newly added code information and the compilation strategy;

[0041] The packaging module is used to merge the incremental version package and the current version package to generate the delivery version package; and

[0042] The deployment module is used to deploy the delivery version package according to the deployment strategy.

[0043] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the policy-based version compilation and deployment method described above.

[0044] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the policy-based version compilation and deployment method described above.

[0045] The fifth aspect of this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described policy-based version compilation and deployment method. Attached Figure Description

[0046] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0047] Figure 1 The illustration schematically depicts an application scenario of a policy-based version compilation and deployment method, apparatus, device, storage medium, and program product according to embodiments of the present disclosure;

[0048] Figure 2 A flowchart illustrating a policy-based version compilation and deployment method according to an embodiment of the present disclosure is shown schematically.

[0049] Figure 3 A flowchart illustrating a compilation and deployment strategy generation method according to an embodiment of the present disclosure is shown schematically;

[0050] Figure 4 A flowchart illustrating an incremental version package generation method according to an embodiment of the present disclosure is shown schematically.

[0051] Figure 5 This schematically illustrates a flowchart for generating an optimal software deployment sequence according to embodiments of the present disclosure;

[0052] Figure 6 This schematically illustrates a deployment anomaly repair flowchart provided according to an embodiment of the present disclosure;

[0053] Figure 7 A schematic diagram illustrating a policy-based version compilation and deployment apparatus according to embodiments of the present disclosure is shown; and

[0054] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a policy-based version compilation and deployment method according to embodiments of the present disclosure. Detailed Implementation

[0055] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0056] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0057] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0058] When using expressions such as "at least one of A, B, and C", they should generally be interpreted in accordance with the meaning that is commonly understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B, and C, etc.).

[0059] First, the terminology appearing in the embodiments of this disclosure will be explained:

[0060] Compilation: The process of generating a target program from a source program, which is the process of translating "one language (usually a high-level language)" into "another language (usually a low-level language)".

[0061] Incremental compilation: Incremental compilation is a compilation technique used when recompiling a source program after it has already been compiled once. Incremental compilation reduces the time required for recompiling the source program, which is highly advantageous when only minor changes have been made to the source program and recompilation is required. It not only improves the efficiency of software development but also the efficiency of software testing personnel.

[0062] Compilation strategy: Different compilation strategies are used for different types of code, such as web, database, batch, etc.

[0063] Deployment Strategy: Deployment is a crucial part of continuous delivery. Software updates and iterations mean more frequent deployments, necessitating a deployment strategy to minimize the impact on site availability and customer experience, ensuring a smooth and rapid release of new versions to the environment. Common deployment strategies include big bang deployment, blue-green deployment, red-black deployment, A / B testing, and rolling deployment.

[0064] Embodiments of this disclosure provide a policy-based version compilation and deployment method, including: in response to user input, obtaining the name of the project module to be deployed and the module root directory; generating a compilation policy and a deployment policy based on the project module name and the module root directory; extracting new code information from a code management tool; compiling and generating an incremental version package based on the new code information and the compilation policy; merging the incremental version package and the current version package to generate a delivery version package; and deploying the delivery version package according to the deployment policy.

[0065] Figure 1 The illustration schematically depicts an application scenario of a policy-based version compilation and deployment method, apparatus, device, storage medium, and program product according to embodiments of the present disclosure.

[0066] like Figure 1 As shown, application scenario 100 according to this embodiment may include a version compilation and deployment scenario. Network 104 is used as a medium to provide a communication link between terminal devices 101, 102, 103 and server 105. Network 104 may include various connection types, such as wired, wireless communication links or fiber optic cables, etc.

[0067] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0068] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0069] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using terminal devices 101, 102, and 103 (this is just an example). The backend management server can analyze and process data such as received user requests. For example, it can generate a compilation strategy by calling a strategy template based on information such as the project module name, module root directory, and code management tool address entered by the user on the front end. It can also generate a deployment strategy by calling a strategy template based on information such as the project module name, module test environment root directory, test server address, test server login information, and code execution user entered by the user on the front end.

[0070] It should be noted that the policy-based version compilation and deployment method provided in this disclosure embodiment can generally be executed by server 105. Correspondingly, the policy-based version compilation and deployment apparatus provided in this disclosure embodiment can generally be located in server 105. The policy-based version compilation and deployment method provided in this disclosure embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the policy-based version compilation and deployment apparatus provided in this disclosure embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0071] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0072] The following will be based on Figure 1 The described scene, through Figures 2-6 The policy-based version compilation and deployment method of the disclosed embodiments is described in detail.

[0073] Figure 2 A flowchart illustrating a policy-based version compilation and deployment method according to an embodiment of the present disclosure is shown.

[0074] like Figure 2 As shown, the policy-based version compilation and deployment method of this embodiment includes operations S210 to S260.

[0075] To address the similarities between different engineering modules, a one-click tool for generating compilation and installation strategies is built to generate standardized deployment strategies, reducing manual operations and improving deployment reliability. Automated incremental deployment of code and modules is achieved, generating relatively small image files and improving build efficiency. A version merging mechanism is established to generate delivery versions, and Dijkstra's heap optimization algorithm is used to dynamically distribute resources, improving resource utilization. An exception handling process is added; when a deployment exception occurs, the exception handling process is first accessed to determine if a pre-defined exception handling solution can be matched. If no match is found, the deployment failure handling process then proceeds.

[0076] Before compiling and deploying the software, the server information of the test environment needs to be configured according to the configuration file, including the server, user, password and other information required for each project.

[0077] In operation S210, in response to user input, the name of the project module to be deployed and its root directory are obtained. In operation S220, a compilation strategy and a deployment strategy are generated based on the project module name and the module root directory.

[0078] In one example, the user enters information such as the project module name and module root directory on the front end. Based on keyword matching, the system extracts the corresponding strategy template to generate the project compilation method and installation process. This operation does not need to be executed every time; before the process begins, it needs to be checked whether the module root directory has been added. If the module root directory is confirmed, the generated strategy is saved in the background; otherwise, the build and deployment process of the execution version is directly invoked from the background. For the specific process of generating the compilation strategy, please refer to [link to documentation]. Figure 3 Operations S221 to S223 are included.

[0079] In operation S230, the newly added code information is extracted from the code management tool. In operation S240, an incremental version package is generated based on the newly added code information and the compilation strategy.

[0080] In one example, if a full module deployment is used for each deployment after adding new code, it leads to long compilation times, large generated image files, and long transmission and deployment times, resulting in wasted resources. Therefore, this disclosure identifies incremental code and enables incremental deployment of code and modules. Code can be directly pulled from the code management tool for compilation and packaging to obtain a version package. The version package is then transferred to the deployment environment host to invoke the installation process (i.e., deployment strategy) for version deployment. The process for generating incremental version packages can be found in [link to documentation]. Figure 4 Operations S241 to S244.

[0081] When operating S250, the incremental version package and the current version package are merged to generate the delivery version package.

[0082] All packages generated during S240 operations are incremental versions, which need to be merged to generate a delivery package. Specifically, the merge task is configured so that the merge process, based on the build pipeline, can skip the compilation process and merge all images generated that day from the image repository to produce the delivery package. The package is named with the version number + (current date + 1) + the first build number of the day. The generated delivery package is then saved to the image repository. A merge interface is provided; the merge task can be set as a scheduled task or manually controlled during version development.

[0083] In operation S260, the delivery version package is deployed according to the deployment strategy.

[0084] In one example, the delivery version package is deployed according to the installation process determined by operation S220. Since the current version deployment requires manually configured parallel group numbers and group order, when the project is large and has many modules, the allocation of deployment execution sequences by humans can easily lead to confusion and deployment problems. Additionally, too many parallel group numbers can cause resource contention, and deployment anomalies in intermediate group numbers can slow down the deployment progress. Some modules sometimes have dependencies that require a fixed deployment order. For example, installing database scripts sometimes requires executing table creation scripts first, then initializing data in the new tables, and finally installing stored procedures. Currently, this process is set as a fixed dependency. However, this dependency does not always exist. Subsequently, if the table creation script fails, the data initialization and stored procedure installation processes will both stop. To solve the above problems, this embodiment uses the Dijkstra heap optimization algorithm to calculate the optimal software deployment sequence and performs deployment according to the calculated optimal software deployment sequence. The specific calculation method can be found in [link to specific calculation method]. Figure 5 Operations S310 to S330 are shown.

[0085] The policy-based version compilation and deployment method provided in this disclosure generates a compilation and deployment strategy based on the user-input project module name and module root directory. This standardized strategy reduces manual intervention, thereby reducing maintenance pressure and improving deployment efficiency. Based on the compilation strategy, newly added code information is compiled to generate incremental version packages, shortening compilation time and reducing the size of the generated image file, thus shortening transmission and deployment time. The incremental version packages are merged to generate a delivery version package, further reducing compilation time and image package size, alleviating iteration pressure. The module deployment path is determined using the Dijkstra heap optimization algorithm, reducing system overhead during module deployment. The module is then deployed to the test environment according to the deployment strategy and the module deployment path, reducing manual operations, improving deployment reliability, and increasing deployment efficiency.

[0086] Figure 3 A flowchart illustrating a compilation and deployment strategy generation method according to an embodiment of this disclosure is shown schematically. Figure 3 As shown, operation S220 includes operations S221 to S223.

[0087] In operation S221, a strategy template is determined based on the project module name and the module root directory. The strategy template includes a compilation strategy template and a deployment strategy template. In operation S222, the compilation strategy template is invoked to generate a compilation strategy. In operation S223, the deployment strategy template is invoked to generate a deployment strategy.

[0088] In one example, a large-scale information project comprises multiple modules, which are isolated from each other but interconnected internally. Due to the similarity of business development logic, strategies can be generated by calling pre-written strategy templates. First, a unified directory structure is established for the program committed to the version control repository and the deployed test environment. The directory contains keywords such as compilation type (front-end, back-end, database type, etc.) and project name. These keywords are extracted to match the corresponding strategy templates and generate the project compilation method and installation process.

[0089] For different types of code (web, database, batch, etc.), corresponding compilation strategy templates are written. The compilation strategy templates perform tasks including, but not limited to: determining if code modifications have occurred in the code management tool, pulling the code and compiling it using a specified mode, and packaging the code into an image stored in an image repository. Users only need to enter the project module name, module root directory, code management tool address, and compilation mode information on the front end to call the strategy template and generate the compilation strategy. Similarly, for different types of code (web, database, batch, etc.), corresponding deployment strategy templates are written. The deployment templates perform tasks including, but not limited to: detecting if a new image has been added, pulling the image, unpacking the image, deploying the version to the test environment, replacing configuration files, and executing the code. Users only need to enter the project module name, module test environment root directory, test server address, test server login information, and code execution user information on the front end to call the strategy template and generate the deployment strategy.

[0090] Figure 4 A flowchart illustrating an incremental version package generation method according to an embodiment of this disclosure is shown schematically. Figure 4 As shown, operation S240 includes operations S241 to S244. To avoid deploying the entire module every time, this embodiment of the disclosure generates an incremental version package by identifying the modified code.

[0091] In operation S241, the project category of the modified code root directory is determined based on the newly added code information. In operation S242, when the project category is determined to be a basic project class, a full compilation is performed to generate a first incremental version package. In operation S243, when the project category is determined to be an application project class, the newly added code is incrementally compiled to generate a second incremental version package. In operation S244, when the project category is determined to be a configuration information class, the project to which the configuration file belongs is determined based on the configuration directory, and the compilation and deployment method corresponding to the project to which the configuration file belongs is called to generate a third incremental version package.

[0092] In one example, the default project root directory includes a base project, an application project, and configuration information. The base project retrieves all code from the project root directory during compilation, calling the corresponding compilation methods and installation processes for version building and installation. The application project retrieves a portion of the code from the project root directory for compilation and deployment. Configuration information refers to the project configuration files. The code management tool extracts project modification information and determines whether a modified project directory belongs to the base project or the application project. Modifications to the base project directory require a full compilation and deployment. Application projects only retrieve newly added code submitted between the most recent build and the current build for incremental compilation and deployment. Modifications to configuration information require determining the project to which the configuration file belongs based on the configuration directory before compilation, and then calling the corresponding configuration file's compilation and deployment method for that project.

[0093] The build tool pulls code from the code management tool and compiles it into a version package using the compilation methods saved in the build tool. Each build generates a flag, which is saved to the code management tool as the starting reference point for the next version build. The version package is named with the version number + production date + number of compilations that day and saved to the image repository. The build tool retrieves the latest version image from the image repository and deploys it to various test environments according to the installation process saved in the build tool. The versions built above are all incremental version packages; to generate a delivery version, version merging is required. A version merging task is set up. The version merging process can skip the compilation work on top of the build pipeline, merging all images generated that day from the image repository to generate a delivery version package, named with the version number + (current date + 1) + first compilation number of the day. The generated delivery version package is saved to the image repository. A version merging interface is provided; the version merging task can be set as a scheduled task or manually controlled during version development.

[0094] After generating the delivery version package, it needs to be deployed. In this embodiment, the deployment overhead of each module is first modeled, and the Dijkstra heap optimization algorithm is used to calculate the module deployment path, that is, the deployment scheme with the minimum deployment overhead. Figure 5 A flowchart illustrating the generation of an optimal software deployment sequence according to an embodiment of this disclosure is shown schematically. Figure 5 As shown, this includes operations S310 to S330.

[0095] When operating S310, obtain historical deployment information and module dependency information of the modules.

[0096] In one example, a module dependency graph can be drawn. The deployment order of modules is maintained. The initial quantization value is 0; for each additional depth, the dependency sequence is incremented by one, traversing until all modules are marked. Historical deployment information of modules is collected, primarily including the average deployment time (time). aveModule usage percentage of project deployment time rat Module deployment anomaly rate ave Average resource utilization rate (res) of module deployment ave Depends on depth sequence layers; current resource usage (res). now The final deployment cost of the module is weight. ave It can be represented as:

[0097] weight ave =αtime ave +βerror ave +γres ave +λlayer

[0098] For module deployment, to ensure that overhead weights remain at the same level, four influencing factors—α, β, γ, and λ—need to be set. Deployment speed is often prioritized during deployment, therefore βerror is set to 10. ave With αtime ave γres ave They should be on the same order of magnitude. Furthermore, deeply dependent modules should be installed later than shallowly dependent modules. β = 10, λ=1

[0099] In operation S320, the module deployment path is determined based on the module's historical deployment information, the module's dependency information, and the Dijkstra heap optimization algorithm.

[0100] According to embodiments of this disclosure, the historical deployment information of the module includes the average deployment time of the module, the module deployment anomaly rate, and the average resource utilization rate of the module deployment. The step of determining the module deployment path based on the historical deployment information, the module dependency information, and the Dijkstra heap optimization algorithm includes: determining a dependency depth sequence based on the module dependency information; determining the average module deployment cost based on the average deployment time, the module deployment anomaly rate, the average resource utilization rate of the module deployment, and the dependency depth sequence; and determining the module deployment path based on the average module deployment cost, the current resource utilization, and the Dijkstra heap optimization algorithm.

[0101] The Dijkstra heap optimization algorithm is used to calculate the time required to complete the deployment process based on the current resource usage and average module deployment cost, and the module deployment path is output.

[0102] D(s,t)={weight now (s)…weight now (i)…weight now (j)…weight now (t)}

[0103] Where S represents the first deployment module and t represents the last deployment module.

[0104] In operation S330, each module is deployed according to the module deployment path.

[0105] In one example, the deployment process follows the order calculated by operation S320, records the deployment log, extracts the deployment duration, deployment results, deployment resource utilization, and updates the overhead formula parameters.

[0106] The current process lacks a deployment exception handling mechanism. Once deployment fails, manual intervention is required to find the cause of the failure and restart the build process. In actual build processes, deployment failures are usually caused by two types of issues: development problems and environment problems. Development problems require developers to check for issues in the submitted program, make corrections, submit them to the code management repository, and restart the build process. Environment problems are mostly fixable; once the environment is fixed, the deployment process can continue. This disclosure provides a deployment exception repair process for restarting the deployment process when software deployment exceptions occur.

[0107] Figure 6 A schematic diagram illustrating a deployment anomaly repair flowchart provided according to an embodiment of this disclosure is shown.

[0108] like Figure 6 As shown, this includes operations S410 to S430.

[0109] When operating S410, if deployment failure is confirmed, obtain the failure keywords.

[0110] In operation S420, the failure keywords are matched with keywords in the problem database.

[0111] According to embodiments of this disclosure, if a match is successful, a failure details message is sent via an email interface. This failure details message includes a failure code, a problem description, and detailed build logs. If a match fails, a deployment failure log is sent via an email interface.

[0112] In one example, historical failure scenarios caused by environmental factors are summarized beforehand, build failure keywords are extracted, and an exception issue database is generated. This database includes fields such as failure codes, problem descriptions, and failure keywords. After a deployment failure, the extracted failure keywords are matched against the keywords stored in the database. If a match is found, it indicates that the deployment failure was due to an environmental issue requiring remediation. In this case, an email API is called to send the build failure keywords, problem description, and detailed build logs to the developers, informing them of the failure details. If no match is found, it indicates that the deployment failure was due to a problem in the development program, requiring code modification. In this case, the deployment is confirmed as a failure, and an email API is called to generate a deployment failure log.

[0113] When operating S430, once the deployment anomaly is confirmed and repaired, the breakpoint re-emergence mechanism is activated to continue the deployment process.

[0114] According to an embodiment of this disclosure, the policy number and deployment procedure list corresponding to the deployment failure are obtained from the deployment failure log; the deployment process continues to be executed according to the policy number and deployment procedure list.

[0115] In one example, to improve deployment efficiency and avoid restarting the deployment process, a script is written to extract the policy number and deployment program list involved in the deployment failure from the deployment failure log. A breakpoint re-release interface is set in the front end. When the environment is manually repaired, the breakpoint is re-released, the script is called, and the deployment process continues from where it failed. This way, there is no need to restart the deployment process, saving deployment time.

[0116] Based on the above-described policy-based version compilation and deployment method, this disclosure also provides a policy-based version compilation and deployment apparatus. The following will combine... Figure 7 The device is described in detail.

[0117] Figure 7 A schematic block diagram of a policy-based version compilation and deployment apparatus according to an embodiment of the present disclosure is shown.

[0118] like Figure 7 As shown, the policy-based version compilation and deployment apparatus 700 of this embodiment includes an acquisition module 810, a policy generation module 820, an extraction module 830, a compilation module 840, a packaging module 850, and a deployment module 860.

[0119] The acquisition module 810 is used to obtain the name of the project module to be deployed and the module root directory in response to user input. In one embodiment, the acquisition module 810 can be used to perform the operation S210 described above, which will not be repeated here.

[0120] The strategy generation module 820 is used to generate compilation and deployment strategies based on the project module name and the module root directory. In one embodiment, the strategy generation module 820 can be used to perform the operation S220 described above, which will not be repeated here.

[0121] The extraction module 830 is used to extract newly added code information from the code management tool. In one embodiment, the extraction module 830 can be used to perform the operation S230 described above, which will not be repeated here.

[0122] The compilation module 840 is used to compile and generate an incremental version package based on the newly added code information and the compilation strategy. In one embodiment, the compilation module 840 can be used to perform the operation S240 described above, which will not be repeated here.

[0123] The packaging module 850 is used to merge the incremental version package and the current version package to generate a delivery version package. In one embodiment, the packaging module 850 can be used to perform the operation S250 described above, which will not be repeated here.

[0124] The deployment module 860 is used to deploy the delivery version package according to the deployment strategy. In one embodiment, the deployment module 860 can be used to perform the operation S260 described above, which will not be repeated here.

[0125] According to embodiments of this disclosure, any multiple modules among the acquisition module 810, policy generation module 820, extraction module 830, compilation module 840, packaging module 850, and deployment module 860 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functionality of one or more of these modules can be combined with at least some of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the acquisition module 810, policy generation module 820, extraction module 830, compilation module 840, packaging module 850, and deployment module 860 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 810, strategy generation module 820, extraction module 830, compilation module 840, packaging module 850, and deployment module 860 may be implemented at least partially as a computer program module that can perform corresponding functions when the computer program module is run.

[0126] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing a policy-based version compilation and deployment method according to embodiments of the present disclosure.

[0127] like Figure 8As shown, an electronic device 900 according to an embodiment of the present disclosure includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0128] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 902 and / or RAM 903. It should be noted that the programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in said one or more memories.

[0129] According to embodiments of this disclosure, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0130] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0131] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0132] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the policy-based version compilation and deployment method provided in embodiments of this disclosure.

[0133] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0134] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0135] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0136] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0137] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0138] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0139] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A policy-based version compilation and deployment method, characterized by, include: In response to user input, obtain the name of the module to be deployed and the module's root directory; Generate compilation and deployment strategies based on the project module name and the module root directory; Extract newly added code information from the code management tool; An incremental version package is generated based on the newly added code information and the compilation strategy; The incremental version package and the current version package are merged to generate the delivery version package; as well as Deploy the delivery version package according to the deployment strategy described above; Determine the dependency depth sequence based on the module's historical deployment information and module dependency information, and calculate the average module deployment cost for each module. Based on the current resource usage and the average module deployment cost, the time required to complete the deployment process is calculated using the Dijkstra heap optimization algorithm to determine the module deployment path; Deploy each module according to the module deployment path described above.

2. The method according to claim 1, characterized in that, The process of generating compilation and deployment strategies based on the project module name and the module root directory includes: The strategy template is determined based on the project module name and the module root directory. The strategy template includes a compilation strategy template and a deployment strategy template. The compilation strategy is generated by calling the compilation strategy template; and The deployment strategy is generated by calling the deployment strategy template.

3. The method according to claim 2, characterized in that, The process of compiling and generating an incremental version package based on the newly added code information and the compilation strategy includes: The project category for modifying the root directory of the code is determined based on the newly added code information; Once the project category is determined to be the basic project category, a full compilation is performed to generate the first incremental version package. Once the project category is determined to be an application project, the newly added code is incrementally compiled to generate a second incremental version package; and Once the project category is determined to be configuration information, the project to which the configuration file belongs is determined based on the configuration directory, and the compilation and deployment method corresponding to the project to which the configuration file belongs is called to generate the third incremental version package.

4. The method according to claim 1, characterized in that, The method further includes: Once deployment failure is confirmed, obtain the failure keywords; The failure keywords are matched with keywords in the problem database. If a match is successful, the email interface is invoked to send failure details, which include a failure code, a problem description, and detailed build logs; and If a match fails, the deployment failure log will be sent via the email interface.

5. The method according to claim 4, characterized in that, The method further includes: Once the deployment anomaly is confirmed and fixed, the breakpoint re-emergence mechanism is activated to continue the deployment process.

6. The method according to claim 5, characterized in that, The mechanism for resuming deployment by triggering breakpoints includes: Retrieve the policy number and deployment program list corresponding to the deployment failure from the deployment failure log; and Continue the deployment process based on the strategy number and deployment procedure list.

7. The method according to any one of claims 1 to 6, characterized in that, Also includes: Configure the server information for the test environment according to the configuration file.

8. A policy-based version build and deployment apparatus, comprising: The module for obtaining information is used in response to user input to retrieve the name of the module to be deployed and its root directory. The strategy generation module is used to generate compilation and deployment strategies based on the project module name and the module root directory. The extraction module is used to extract newly added code information from the code management tool; The compilation module is used to compile and generate an incremental version package based on the newly added code information and the compilation strategy; The packaging module is used to merge the incremental version package and the current version package to generate the delivery version package; as well as The deployment module is used to deploy the delivery version package according to the deployment strategy; The deployment module also determines the dependency depth sequence and calculates the average module deployment cost for each module based on the module's historical deployment information and module dependency information; based on the current resource usage and the average module deployment cost, it uses the Dijkstra heap optimization algorithm to calculate the time required to complete the deployment process, so as to determine the module deployment path; and deploys each module according to the module deployment path.

9. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

11. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • Jenkinsfile-based user-defined compiling and deploying method and system

    CN112558981A