Batch automatic release and process optimization method and system

Abstract

The invention relates to a batch automatic release and process optimization method and system, and relates to the field of application release, and the method comprises the following steps: step 100: collecting a release version; step 101, calling a release item based on the release version; step 102, determining project dependence according to the published project; step 103, determining a release batch based on the project dependency; step 104, generating a publishing process in combination with the publishing batch and the publishing item; and step 105, releasing the application in response to the release process. The application has the effects of improving the convenience of application release and quickly releasing different types of items according to the sequence.

Description

Technical Field

[0001] This invention relates to the field of application deployment, and in particular to a method and system for batch automatic deployment and process optimization. Background Technology

[0002] Application deployment refers to the complete process of installing and running the developed and built software product into the target environment to make it usable.

[0003] In today's internet industry, rapid iteration and stable delivery of software applications are the core of business success. The release process is usually carried out manually on a project-by-project basis. In one version iteration of an application, multiple different types of projects are often involved (such as backend microservices, frontend web applications, mobile apps, cross-platform desktop clients, etc.). Release engineers need to select, configure, and click the release operation on the release platform of each of these projects one by one.

[0004] When a version iteration involves too many projects, relying on manual operation can easily lead to problems such as selecting the wrong project, missing the project, or getting the release order wrong, which can cause online service interruptions or functional failures and pose a serious threat to business stability. Summary of the Invention

[0005] To improve the ease of application deployment and enable the rapid and sequential deployment of different types of projects, this invention provides a batch automatic deployment and process optimization method and system.

[0006] In a first aspect, the present invention provides a method for batch automatic publishing and process optimization, which adopts the following technical solution: A method for batch automated deployment and process optimization includes: Step 100: Collect and release the version; Step 101: Retrieve the release project based on the release version; Step 102: Determine project dependencies based on the published project; Step 103: Determine the release batch based on the project dependencies; Step 104: Generate a release process by combining the release batches and release projects; Step 105: Publish the application in response to the publishing process.

[0007] By adopting the above technical solution, the release project is associated with the release version, so that the release project can be retrieved at once through the release version, and the release batch can be set for the release project according to the dependency relationship between the release projects, thereby quickly and sequentially releasing different types of projects and improving the convenience of application release.

[0008] Optional, also includes: Step 106: Determine the application type based on the release version; Step 107: If the application type matches the preset composite type, determine the transmission order according to the published item; Step 108: Determine the previous batch of items based on the transmission order and release batch; Step 109: Retrieve the project identifier based on the previous batch of projects; Step 110: Determine the version project by combining the published project and project identifier; Step 111: Respond to the version project update release process.

[0009] By adopting the above technical solution, when releasing composite applications, different departments need to release their respective release projects in sequence, and it is necessary to ensure that the release projects of each department are interconnected. This makes the release process of composite applications relatively complex. By replacing manual coordination with automated triggering between steps and automatic transfer of project identifiers, multiple discrete release sub-steps (especially steps involving different technology stacks or systems) are integrated into a unified automated task, thereby quickly and sequentially releasing different types of projects that constitute composite applications and improving the convenience of application release.

[0010] Optional, also includes: Step 112: Retrieve the release results based on the release process; Step 113: When the published result is consistent with the preset failure result, determine the failed item by combining the published process and the published result; Step 114: Generate and send an interruption command based on the failed projects, and determine the successful projects based on the release process and release results; Step 115: In response to the successful and failed projects, generate and display a publication failure message.

[0011] By adopting the above technical solution, the application deployment process is monitored. If any deployment project fails, the entire deployment process is immediately terminated and relevant personnel are notified. This prevents front-end functionality from being abnormal due to back-end service unavailability, achieving "fail fast" to avoid the spread of problems and improve the stability of application deployment.

[0012] Optionally, it also includes a project allocation method, which includes: Step 200: Determine the number of projects based on the release batch; Step 201: When the number of projects exceeds the preset congestion threshold, determine the business module based on the published projects; Step 202: Determine the business sequence based on the business modules; Step 203: Update and release batches based on the business sequence and business modules.

[0013] By adopting the above technical solution, when there are too many projects to release in the same batch, it is easy to cause the release process to be stuck and the queue time to be long, which will significantly extend the overall release time. By detecting the number of release projects in different batches, the application is released in the order of the business modules to which the different release projects belong, thereby reducing the situation where the application release efficiency is low due to too few batches and improving the stability of application release.

[0014] Optionally, the project allocation method further includes: Step 204: When the number of projects is not greater than the preset congestion threshold, determine the release consumption based on the release batch; Step 205: When the release consumption is greater than the preset pressure threshold, a pressure reduction batch is determined in response to the release consumption; Step 206: Determine the decompression consumption based on the decompression batch; Step 207: Determine the cooling duration based on the pressure reduction consumption; Step 208: Generate a decompression process by combining the decompression batch and cooling time; Step 209: Update the release process in response to the decompression process.

[0015] By adopting the above technical solution, when an application is released, a certain amount of resources are required. The release consumption of release items in different release batches is detected. When the release consumption is too high, the release items are sent in batches, and an appropriate cooling-off period is selected according to the release consumption. This reduces the situation where excessive release consumption leads to release failure or even system crash, thereby improving the stability of application release.

[0016] Optionally, the project allocation method further includes: Step 210: Collection and Release Strategy; Step 211: Determine the environmental requirements based on the release strategy; Step 212: Generate and send environment adjustment instructions based on the environment requirements, and generate a policy process in conjunction with the release strategy and release process; Step 213: Publish the application in response to the policy process.

[0017] By adopting the above technical solutions, staff can select appropriate release strategies for different business scenarios and project types, and then release applications according to the release strategies to balance the efficiency, stability and risk control of software version delivery, thereby improving the convenience of application release.

[0018] Optionally, it also includes a failure handling method, the failure handling method comprising: Step 300: When the published result is consistent with the preset failure result, determine the failure type based on the published result; Step 301: If the failure type falls into a preset temporary range, retrieve environmental parameters based on the failure type; Step 302: Determine the environmental coefficient based on the environmental parameters; Step 303: Determine the reconnection interval in response to the environmental coefficient, and collect the disconnection duration; Step 304: When the disconnection duration is consistent with the reconnection interval, update the environmental coefficient; Step 305: If the environmental coefficient falls within the preset stable range, determine the reconnection process based on the failed project and the release process; Step 306: Publish the application in response to the reconnection process.

[0019] By adopting the above technical solution, when a project deployment fails, the failure type is detected. When the failure type is a temporary problem such as network jitter or excessive resource consumption, network environment parameters are monitored, and an appropriate reconnection interval is selected according to the environment parameters to continue deploying the application, thereby improving the stability of application deployment.

[0020] Optionally, the failure handling method further includes: Step 307: If the failure type does not fall into the preset temporary interval, determine the affected project based on the failed project and project dependencies; Step 308: Identify individual projects based on the impacted projects and release process; Step 309: Determine independent batches based on the independent projects and project dependencies; Step 310: Combine the release process with the aforementioned independent projects and independent batches.

[0021] By adopting the above technical solution, when the failure type is a permanent problem such as version incompatibility or configuration error, independent projects that have no dependency relationship with the failed project in the release process can be screened out, and the application can be re-released according to the dependency relationship between independent projects, thereby improving the stability of application release.

[0022] Optionally, the failure handling method further includes: Step 311: If the failure type does not fall into the preset temporary range, determine the dependent items by combining the failed items and the project dependencies; Step 312: Retrieve the dependency identifier from the release process based on the dependent project; Step 313: Determine the compatibility identifier based on the dependent items and dependency identifiers; Step 314: Determine compatible items by combining the compatibility identifier, affected items, and failed items; Step 315: Respond to the compatibility project update release process.

[0023] By adopting the above technical solution, when the failure type is a permanent problem such as version incompatibility or configuration error, the dependency project that is located before the failed project and has a dependency relationship with the failed project is retrieved from the release process. The compatibility flag is selected according to the compatibility of the dependency project, and then the compatible project corresponding to the subsequent affected project that has a dependency relationship with the failed project is retrieved according to the compatibility flag. In this way, the application is rolled back to a stable version, improving the stability of application release.

[0024] Secondly, this application provides a batch automatic publishing and process optimization system, which adopts the following technical solution: A batch automated deployment and process optimization system, comprising: The data collection module is used to collect information on release versions, release strategies, and disconnection durations. The memory is used to store the program for any of the above-mentioned batch automatic release and process optimization methods; The processor is the unit of memory that allows programs to be loaded and executed by the processor.

[0025] By adopting the above technical solution, the release project is associated with the release version, so that the release project can be retrieved at once through the release version, and the release batch can be set for the release project according to the dependency relationship between the release projects, thereby quickly and sequentially releasing different types of projects and improving the convenience of application release.

[0026] In summary, this application includes at least one of the following beneficial technical effects: 1. Associate release projects with release versions, so that release projects can be retrieved all at once through release versions, and release batches can be set for release projects according to the dependencies between them, thereby quickly and sequentially releasing different types of projects and improving the convenience of application release; 2. When releasing composite applications, different departments need to release their respective projects in sequence, and the release projects of each department need to be interconnected. This makes the release process of composite applications more complex. By replacing manual coordination with automated triggering between steps and automatic transfer of project identifiers, multiple discrete release sub-steps (especially steps involving different technology stacks or systems) are integrated into a unified automated task. This enables the rapid and sequential release of different types of projects that make up the composite application, improving the convenience of application release. 3. Monitor the application deployment process. If any deployment project fails, immediately terminate the entire deployment process and notify relevant personnel. This prevents front-end functionality from being disrupted due to backend service unavailability, achieving "fail fast" to avoid the spread of problems and improve the stability of application deployment. Attached Figure Description

[0027] Figure 1 It is a method for batch automatic publishing and process optimization; Figure 2 It refers to the project allocation method; Figure 3 This is a failure handling method. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0029] Reference Figure 1 A method for batch automated deployment and process optimization, comprising: Step 100: Collect the release version.

[0030] A release version refers to the version of an application that needs to be released, that is, the result of a specific stage in the software development process. Software products usually fix bugs or add new features by continuously releasing new "versions". This process is called "version iteration". The release version is entered by the staff, which will not be elaborated here.

[0031] Step 101: Retrieve the release project based on the release version.

[0032] A release project refers to a software functional unit that constitutes an application and can be independently built, tested, and deployed. A complete software application is usually composed of multiple release projects. For example, an e-commerce system may include "user service project", "product service project", "order service project" and "front-end website project". The release project corresponding to the release version can be queried from the version relationship table, which is a data table that records different release versions and their corresponding release projects.

[0033] Step 102: Determine project dependencies based on the published project.

[0034] Project dependency refers to the dependency relationship between different released projects. In a software project, the normal operation of one component (A) requires another component (B) to be ready first, so A is said to depend on B. In this invention, it specifically refers to the dependency on the release order. For example, if a front-end project needs to call the interface of a back-end project, then during release, it must be ensured that the back-end project is released successfully first, so that the front-end project can be released and used normally. That is, the front-end project depends on the back-end project. The project dependencies corresponding to the released projects can be found from the dependency graph. The dependency graph is a graph that records the dependency relationship between different released projects. The dependency relationship of the released projects is represented by the connection relationship of the released projects in the dependency graph. The dependency graph is set in advance by the staff and will not be elaborated here.

[0035] Step 103: Determine the release batch based on the project dependencies.

[0036] Release batches refer to the order in which release projects are installed and run in the target environment. Generally, release projects are divided into two batches: "backend projects" and "frontend projects". "Backend projects" are released first, followed by "frontend projects". Release batch 1 corresponds to a release project belonging to "backend projects", and release batch 2 corresponds to a release project belonging to "frontend projects". The method for determining release batches is selected by staff based on the actual situation, and will not be elaborated here.

[0037] Step 104: Generate a release process by combining the release batches and release projects.

[0038] The release process refers to the process of releasing projects sequentially according to release batches. The method for generating the release process is common knowledge to those in the field and will not be elaborated here.

[0039] Step 105: Publish the application in response to the publishing process.

[0040] By associating release projects with release versions, release projects can be retrieved all at once through release versions. Release batches can be set for release projects according to their dependencies, thereby enabling the rapid and sequential release of different types of projects and improving the convenience of application release.

[0041] A batch automated deployment and process optimization method also includes: Step 106: Determine the application type based on the release version.

[0042] Application type is a classification label based on the software's technology stack, deployment form, functional architecture, and component composition, such as composite application, front-end application, back-end application, and embedded application. The application type corresponding to the release version can be queried from the type correspondence table, which is a data table that records different release versions and their corresponding application types.

[0043] Step 107: If the application type is consistent with the preset composite type, determine the transmission order according to the published item.

[0044] Composite type refers to the application type of a composite application. When the application type and composite type are the same, it means that the currently released application belongs to the composite application. A composite application is a complete application composed of multiple components of different technology stacks or different types. These components usually need to be released and configured in a specific order. For example, the Electron desktop client combines "front-end web resources" (used to render the interface) and "main application" (a locally running container program used to manage windows and system resources).

[0045] The transmission order refers to the order in which the projects that make up a composite application are released. For example, the Electron desktop client needs to release the "front-end web resources" first, and then release the "main application" associated with the version of the "front-end web resources". The transmission order corresponding to the released projects can be found from the sequence graph. The sequence graph is a graph that records the release order of the components corresponding to different composite applications. The sequence graph is set in advance by the staff and will not be elaborated here.

[0046] Step 108: Determine the previous batch of items based on the transmission order and release batch.

[0047] The previous batch of projects refers to the projects sent in the previous batch. For example, if the project released in this batch is "main program application", then the previous batch of projects is "front-end web resources". The method for determining the previous batch of projects is selected by the staff according to the actual situation, which will not be elaborated here.

[0048] Step 109: Retrieve the project identifier based on the previous batch of projects.

[0049] A project identifier is a unique string used to uniquely identify a specific build or set of code. It is generally a version number (such as 1.2.3, which usually follows semantic versioning rules), a Git Commit Hash (a hash value generated by the version control system Git that uniquely corresponds to a certain code commit, such as a1b2c3d), or a build pipeline ID (a unique number generated by the continuous integration / continuous deployment system for each build task). The method for determining the project identifier is chosen by the staff according to the actual situation, and will not be elaborated here.

[0050] Step 110: Determine the version project by combining the published project and project identifier.

[0051] A version project refers to a software functional unit formed by injecting a project identifier as a build parameter or environment variable into a release project. The project identifier links the previous batch of projects with the version project, thereby ultimately building a complete client application package. The method for generating version projects is selected by the staff according to the actual situation, and will not be elaborated here.

[0052] Step 111: Respond to the version project update release process.

[0053] When deploying composite applications, different departments need to deploy their respective projects sequentially, ensuring that these projects are interconnected. This makes the deployment process complex. By automating the triggering of steps and automatically transferring project identifiers, manual coordination can be replaced. This integrates multiple discrete deployment sub-steps (especially those involving different technology stacks or systems) into a unified automated task, enabling the rapid and sequential deployment of different types of projects that constitute the composite application, thus improving the ease of application deployment.

[0054] A batch automated deployment and process optimization method also includes: Step 112: Retrieve the release results based on the release process.

[0055] The release results refer to the results of releasing each project in sequence according to the release process. The method for retrieving the release results is selected by the staff based on the actual situation, and will not be elaborated here.

[0056] Step 113: When the release result is consistent with the preset failure result, determine the failed item by combining the release process and the release result.

[0057] A failure result refers to a release result where the project failed to be released. If the release result and the failure result are the same, it means that the project has failed to be released. A failed project is a project that failed to be released. The method for determining a failed project is common knowledge to those in the field and will not be elaborated here.

[0058] Step 114: Generate and send an interrupt command based on the failed projects, and determine the successful projects based on the release process and release results.

[0059] An interrupt instruction is a command that terminates the publishing process. The method for generating interrupt instructions is common knowledge to those in the field and will not be elaborated here.

[0060] A successful project is a project that has been successfully released according to the release schedule. The method for determining a successful project is common knowledge to those in the field and will not be elaborated here.

[0061] Step 115: In response to the successful and failed projects, generate and display a publication failure message.

[0062] Publishing failure messages refers to displaying information about successful and failed projects to staff. The method for generating failure messages is common knowledge in this field and will not be elaborated here.

[0063] The system monitors the application deployment process. If any deployment project fails, the entire deployment process is immediately terminated and relevant personnel are notified. This prevents front-end functionality from being disrupted due to backend service unavailability, achieving "fail fast" to avoid the spread of problems and improve the stability of application deployment.

[0064] Reference Figure 2 Project allocation methods include: Step 200: Determine the number of projects based on the release batch.

[0065] The number of projects refers to the number of projects included in the same batch. Multiple batches correspond to multiple project numbers. The method for determining the number of projects is common knowledge in the field and will not be elaborated here.

[0066] Step 201: When the number of projects exceeds the preset congestion threshold, determine the business module based on the published projects.

[0067] The congestion threshold refers to the minimum number of projects that can easily cause the release process to stall. This threshold is selected by staff based on actual conditions and will not be elaborated upon here. A number of projects exceeding the congestion threshold indicates that there are too many release projects within at least one release batch. Deploying according to the current release schedule is likely to cause stalls. A business module refers to the business function modules built by a release project. Each business module typically consists of multiple release projects. For example, a payment module includes backend payment services, a frontend payment page, and database scripts. The business module corresponding to a release project can be queried from the module mapping table, which records different business modules and their corresponding release projects.

[0068] Step 202: Determine the business sequence based on the business modules.

[0069] Business sequence refers to the dependency and priority order at the business level. For example: User module (responsible for login and identity verification) → Product module (dependent on user identity query permissions) → Order module (dependent on product data and user information). The business sequence corresponding to the business modules can be found from the business graph. The business graph is a graph that records the business sequence between different business modules. The business graph is preset by the staff and will not be elaborated here.

[0070] Step 203: Update and release batches based on the business sequence and business modules.

[0071] Update the release batches according to the business sequence. For example, the release batch corresponding to the release project belonging to the user module is 1, the release batch corresponding to the release project belonging to the product module is 2, and the release batch corresponding to the release project belonging to the order module is 3.

[0072] When too many projects are released in the same batch, it can easily lead to delays in the release process and long queue times, resulting in a significant increase in the overall release time. By detecting the number of release projects in different batches, the application can be released in the order of the business modules to which the different release projects belong. This reduces the situation where too few batches lead to low application release efficiency and improves the stability of application release.

[0073] Project allocation methods also include: Step 204: When the number of projects is not greater than the preset congestion threshold, determine the release consumption based on the release batch.

[0074] A number of projects not exceeding the congestion threshold indicates fewer concurrent projects. Release consumption refers to the CPU / memory resource usage of releasing projects within the same release batch simultaneously. Different release projects can be retrieved from the release batch, and the project consumption corresponding to each release project can be retrieved from the consumption mapping table. Finally, the sum of the project consumption is calculated as the release consumption. The consumption mapping table is a data table that records different release projects and their corresponding project consumption.

[0075] Step 205: When the release consumption is greater than the preset pressure threshold, a pressure reduction batch is determined in response to the release consumption.

[0076] The stress threshold refers to the minimum release cost that is likely to cause a release failure. The stress threshold is selected by the staff based on the actual situation and will not be elaborated here. A release cost greater than the stress threshold means that releasing the application in batches will consume too much CPU / memory resources, which may easily lead to sending failures or even system crashes. A de-stressing batch refers to a batch after splitting the release batch with release cost greater than the stress threshold. That is, a release batch that ensures that no release cost is greater than the stress threshold. For example, a release batch with a stress threshold of 5 and a release cost of 10 corresponds to two de-stressing batches with a release cost of 5. The method for determining the de-stressing batch is common knowledge in the field and will not be elaborated here.

[0077] Step 206: Determine the decompression consumption based on the decompression batch.

[0078] Decompression consumption refers to the CPU / memory resource usage of release projects within the same decompression batch when they are released simultaneously. The method for determining decompression consumption is the same as the release consumption in step 204 above, and will not be repeated here.

[0079] Step 207: Determine the cooling time based on the pressure reduction consumption.

[0080] Cooling time refers to the time interval required to deploy the next batch of projects after deploying projects in the decompression batch. Cooling time reduces the instantaneous pressure on the underlying infrastructure caused by application deployment. The greater the decompression consumption, the longer the cooling time. The cooling time corresponding to the decompression consumption can be found in the cooling correspondence table, which is a data table that records different decompression consumption and their corresponding cooling times.

[0081] Step 208: Generate a decompression process by combining the decompression batch and cooling time.

[0082] The decompression process refers to the process of deploying and releasing projects sequentially according to decompression batches and cooling durations. The method for generating the decompression process is common knowledge to those in the field and will not be elaborated here.

[0083] Step 209: Update the release process in response to the decompression process.

[0084] Deploying an application requires consuming certain resources. By monitoring the deployment costs of deployment items within different deployment batches, deployment items can be sent out in batches when deployment costs are too high. An appropriate cooldown period can be selected based on deployment costs, thereby reducing the possibility of deployment failures or even system crashes due to excessive deployment costs and improving the stability of application deployment.

[0085] Project allocation methods also include: Step 210: Collection and Release Strategy.

[0086] A release strategy refers to a set of standardized release rules designed to balance the efficiency, stability, and risk control of software version delivery for different business scenarios and project types. Examples include full release: deploying the new version to all target instances / environments at once; canary release: releasing a small number of instances first for verification before full release; and blue-green release: switching the entire environment (such as all backend services) as an atomic batch. Release strategies can be entered by staff, and the collection method for release strategies is selected by staff according to the actual situation, which will not be elaborated here.

[0087] Step 211: Determine the environmental requirements based on the release strategy.

[0088] Environment requirements refer to the environment required for deploying applications using a release strategy. For example, a blue-green release requires deploying two completely identical environments (blue = old version, green = new version). After verification, traffic is switched. The method for determining environment requirements is common knowledge among those in the field and will not be elaborated here.

[0089] Step 212: Generate and send environment adjustment instructions based on the environment requirements, and generate a policy process in conjunction with the release strategy and release process.

[0090] An environmental adjustment directive is an instruction to adjust the environment in accordance with environmental requirements. The method for generating an environmental adjustment directive is common knowledge to those skilled in the art and will not be elaborated here.

[0091] The policy process refers to the process of deploying applications according to the release policy. The method for generating the policy process is common knowledge to those in the field and will not be elaborated here.

[0092] Step 213: Publish the application in response to the policy process.

[0093] Staff members select appropriate release strategies for different business scenarios and project types, and then release applications according to the release strategies to balance the efficiency, stability and risk control of software version delivery, and improve the convenience of application release.

[0094] Reference Figure 3 Failure handling methods include: Step 300: When the published result is consistent with the preset failure result, determine the failure type based on the published result.

[0095] Failure type refers to the reasons that cause the release to fail, such as network jitter, temporary unavailability of dependent services, version incompatibility, and configuration errors. The method for determining the failure type is common knowledge to those in the field and will not be elaborated here.

[0096] Step 301: If the failure type falls into a preset temporary range, retrieve environmental parameters based on the failure type.

[0097] The temporary range refers to failure types that are temporary, such as network jitter, brief unavailability of dependent services, or sudden high resource usage. The temporary range is selected by staff based on the actual situation and will not be elaborated here. A failure type falling into the temporary range means that a reconnection attempt can be made for that failure. Environment parameters refer to the parameters that caused the project deployment failure. For example, if the failure type is network jitter, the environment parameters are network parameters; if the failure type is sudden high resource usage, the environment parameters are resource parameters. The method for retrieving environment parameters is selected by staff based on the actual situation and will not be elaborated here.

[0098] Step 302: Determine the environmental coefficient based on the environmental parameters.

[0099] The environmental coefficient is a numerical value used to show the stability of the environment. The larger the environmental coefficient, the more the environmental parameter deviates from the normal value, and the more difficult it is for the environmental parameter to return to stability. The environmental coefficient corresponding to the environmental parameter can be found in the coefficient correspondence table, which is a data table that records different environmental parameters and their corresponding environmental coefficients.

[0100] Step 303: Determine the reconnection interval in response to the environmental coefficient, and collect the disconnection duration.

[0101] The reconnection interval refers to the time interval at which reconnection attempts are made. The larger the environment coefficient, the larger the reconnection interval is used. The reconnection interval corresponding to the environment coefficient can be found in the interval correspondence table, which is a data table that records different environment coefficients and their corresponding reconnection intervals.

[0102] Disconnection duration refers to the elapsed time after a project deployment failure. Disconnection duration can be collected using a timer. The method for collecting disconnection duration is selected by the staff based on the actual situation and will not be elaborated here.

[0103] Step 304: When the disconnection duration is consistent with the reconnection interval, update the environmental coefficient.

[0104] If the disconnection duration and reconnection interval are the same, it means that the environmental parameters may have returned to stability. You can try to reconnect and continue sending the project. At this time, update the environmental coefficients to determine the environmental situation.

[0105] Step 305: If the environmental coefficient falls within the preset stable range, determine the reconnection process based on the failed project and the release process.

[0106] The stable range refers to the environmental coefficient range within which a release is unlikely to fail. The stable range is selected by staff based on actual conditions and will not be elaborated upon here. When the environmental coefficient falls within the stable range, it means that reconnection is possible and the project can continue to be sent according to the release schedule. The reconnection process refers to the process of sending the failed project and subsequent releases according to the release schedule. The method for determining the reconnection process is common knowledge in this field and will not be elaborated upon here.

[0107] Step 306: Publish the application in response to the reconnection process.

[0108] When a project deployment fails, the failure type is detected. If the failure type is a temporary issue such as network jitter or excessive resource consumption, network environment parameters are monitored. Based on these parameters, an appropriate reconnection interval is selected to continue deploying the application, thereby improving the stability of application deployment.

[0109] Failure handling methods also include: Step 307: If the failure type does not fall into the preset temporary interval, determine the affected project based on the failed project and project dependencies.

[0110] Failure types that do not fall into the temporary range mean that it is impossible to continue sending the project. Affected projects refer to all released projects that directly or indirectly depend on the failed project. Affected projects can be found in the dependency graph.

[0111] Step 308: Identify independent projects based on the impact projects and release process.

[0112] Independent projects refer to other release projects in the release process besides those affecting the project. The method for identifying independent projects is common knowledge among those in the field and will not be elaborated here.

[0113] Step 309: Determine the independent batch based on the independent project and project dependencies.

[0114] Independent batches refer to the order in which independent projects are installed and run in the target environment. The method for determining independent batches can refer to the method for determining release batches in step 103 above, and will not be repeated here.

[0115] Step 310: Combine the release process with the aforementioned independent projects and independent batches.

[0116] When the failure type is a permanent issue such as version incompatibility or configuration error, independent projects that have no dependency relationship with the failed project are selected in the release process. The application is then redeployed according to the dependency relationship between the independent projects, thereby improving the stability of the application release.

[0117] Failure handling methods also include: Step 311: If the failure type does not fall into the preset temporary range, determine the dependent items by combining the failed items and the project dependencies.

[0118] Dependency projects refer to the released projects that a failed project directly depends on, and can be found in the dependency graph.

[0119] Step 312: Retrieve the dependency identifier from the release process based on the dependent project.

[0120] Dependency identifiers refer to the project identifiers corresponding to dependent projects. The method for determining dependency identifiers is selected by staff based on the actual situation and will not be elaborated here.

[0121] Step 313: Determine the compatibility identifier based on the dependent items and dependency identifiers.

[0122] A compatibility identifier refers to the project identifier of other failed projects that can be associated with a dependency project. The compatibility identifier can be retrieved from the compatibility data table, which records different dependency projects and dependency identifiers and their corresponding compatibility identifiers.

[0123] Step 314: Determine the compatible items by combining the compatibility identifier, affected items, and failed items.

[0124] A compatible project is a software functional unit that incorporates compatibility identifiers as build parameters or environment variables that affect and prevent failed projects. The method for determining compatible projects is selected by the staff based on the actual situation and will not be elaborated here.

[0125] Step 315: Respond to the compatibility project update release process.

[0126] When the failure type is a permanent issue such as version incompatibility or configuration error, the dependency project that is located before the failed project and has a dependency relationship with the failed project is retrieved from the release process. The compatibility flag is selected according to the compatibility of the dependency project. Then, the compatible project corresponding to the affected project that has a dependency relationship with the failed project is retrieved according to the compatibility flag, and the application is rolled back to a stable version, thereby improving the stability of the application release.

[0127] Based on the same inventive concept, embodiments of the present invention provide a batch automatic publishing and process optimization system, including: The data collection module is used to collect information on release versions, release strategies, and disconnection durations. The memory is used to store the program for any of the above-mentioned batch automatic release and process optimization methods; The processor is the unit of memory that allows programs to be loaded and executed by the processor.

[0128] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0129] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for batch automatic publishing and process optimization, characterized in that, include: Step 100: Collect and release the version; Step 101: Retrieve the release project based on the release version; Step 102: Determine project dependencies based on the published project; Step 103: Determine the release batch based on the project dependencies; Step 104: Generate a release process by combining the release batches and release projects; Step 105: Publish the application in response to the publishing process.

2. The batch automatic publishing and process optimization method according to claim 1, characterized in that, Also includes: Step 106: Determine the application type based on the release version; Step 107: If the application type matches the preset composite type, determine the transmission order according to the published item; Step 108: Determine the previous batch of items based on the transmission order and release batch; Step 109: Retrieve the project identifier based on the previous batch of projects; Step 110: Determine the version project by combining the published project and project identifier; Step 111: Respond to the version project update release process.

3. The batch automatic publishing and process optimization method according to claim 2, characterized in that, Also includes: Step 112: Retrieve the release results based on the release process; Step 113: When the published result is consistent with the preset failure result, determine the failed item by combining the published process and the published result; Step 114: Generate and send an interruption command based on the failed projects, and determine the successful projects based on the release process and release results; Step 115: In response to the successful and failed projects, generate and display a publication failure message.

4. The batch automatic publishing and process optimization method according to claim 3, characterized in that, It also includes a project allocation method, which includes: Step 200: Determine the number of projects based on the release batch; Step 201: When the number of projects exceeds the preset congestion threshold, determine the business module based on the published projects; Step 202: Determine the business sequence based on the business modules; Step 203: Update and release batches based on the business sequence and business modules.

5. The batch automatic publishing and process optimization method according to claim 4, characterized in that, The project allocation method also includes: Step 204: When the number of projects is not greater than the preset congestion threshold, determine the release consumption based on the release batch; Step 205: When the release consumption is greater than the preset pressure threshold, a pressure reduction batch is determined in response to the release consumption; Step 206: Determine the decompression consumption based on the decompression batch; Step 207: Determine the cooling duration based on the pressure reduction consumption; Step 208: Generate a decompression process by combining the decompression batch and cooling time; Step 209: Update the release process in response to the decompression process.

6. The batch automatic publishing and process optimization method according to claim 5, characterized in that, The project allocation method also includes: Step 210: Collection and Release Strategy; Step 211: Determine the environmental requirements based on the release strategy; Step 212: Generate and send environment adjustment instructions based on the environment requirements, and generate a policy process in conjunction with the release strategy and release process; Step 213: Publish the application in response to the policy process.

7. The batch automatic publishing and process optimization method according to claim 6, characterized in that, It also includes a failure handling method, which includes: Step 300: When the published result is consistent with the preset failure result, determine the failure type based on the published result; Step 301: If the failure type falls into a preset temporary range, retrieve environmental parameters based on the failure type; Step 302: Determine the environmental coefficient based on the environmental parameters; Step 303: Determine the reconnection interval in response to the environmental coefficient, and collect the disconnection duration; Step 304: When the disconnection duration is consistent with the reconnection interval, update the environmental coefficient; Step 305: If the environmental coefficient falls within the preset stable range, determine the reconnection process based on the failed project and the release process; Step 306: Publish the application in response to the reconnection process.

8. The batch automatic publishing and process optimization method according to claim 7, characterized in that, The failure handling method further includes: Step 307: If the failure type does not fall into the preset temporary interval, determine the affected project based on the failed project and project dependencies; Step 308: Identify individual projects based on the impacted projects and release process; Step 309: Determine independent batches based on the independent projects and project dependencies; Step 310: Combine the release process with the aforementioned independent projects and independent batches.

9. The batch automatic publishing and process optimization method according to claim 8, characterized in that, The failure handling method further includes: Step 311: If the failure type does not fall into the preset temporary range, determine the dependent items by combining the failed items and the project dependencies; Step 312: Retrieve the dependency identifier from the release process based on the dependent project; Step 313: Determine the compatibility identifier based on the dependent items and dependency identifiers; Step 314: Determine compatible items by combining the compatibility identifier, affected items, and failed items; Step 315: Respond to the compatibility project update release process.

10. A batch automatic publishing and process optimization system, characterized in that, include: The data collection module is used to collect information on release versions, release strategies, and disconnection durations. A memory for storing a program of a batch automatic release and process optimization method as described in any one of claims 1 to 9; The processor is the unit of memory that allows programs to be loaded and executed by the processor.

Images