Deployment strategy selection method and cloud server

Abstract

The invention discloses a deployment strategy selection method and a cloud server. The method is applied to a cloud service, and comprises the following steps: acquiring an environment type of a to-be-deployed environment; when the environment type is a production environment, acquiring a risk level of the to-be-deployed service, and determining a first deployment strategy based on the risk level; and when the environment type is the production environment and other environments except the pre-published environment, obtaining the service type of the to-be-deployed service, and confirming a second deployment strategy based on the service type. According to the method, intelligent shunting according to different environment types is realized, and the deployment strategy is selected by adopting the differential decision factor, so that the deployment efficiency and the resource utilization rate of the non-production environment are improved while the deployment safety of the core production environment is ensured, and the reliability and the efficiency of deployment are improved.

Description

Technical Field

[0001] This invention relates to the field of software deployment technology, and in particular to a deployment strategy selection method and a cloud server. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, the frequency and complexity of software deployments have increased significantly. Especially in SaaS platform environments (a platform that enables multiple deployment strategies), users have increasingly higher requirements for service availability.

[0003] In practical applications, the deployment strategies of related technologies are often singular and fixed, requiring significant manual effort and time to deploy, and often resulting in poor deployment effects that do not match the optimal deployment conditions. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a deployment strategy selection method that supports multiple deployment strategies and improves deployment reliability.

[0005] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A deployment strategy selection method, applied to a cloud server, the method comprising: Obtain the environment type of the environment to be deployed; When the environment type is a production environment, the risk level of the service to be deployed is obtained, and the first deployment strategy is confirmed based on the risk level. When the environment type is an environment other than the production environment and the pre-release environment, the service type of the service to be deployed is obtained, and a second deployment strategy is confirmed based on the risk level.

[0006] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A cloud server includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the deployment strategy selection method described above.

[0007] The beneficial effects of this invention are as follows: By acquiring the environment type of the environment to be deployed, instead of manual judgment, the influence of the environment on the judgment is eliminated; based on the intelligent routing according to the environment type, for production environments, the system focuses on the risk level as a core security factor to decide the deployment strategy, thereby ensuring the stability and controllability of core business changes. This allows high-risk production changes to be based on objective risk assessment, rather than subjective experience, automatically selecting the most prudent strategy to ensure the stability of core business; for non-production environments, the system shifts to optimizing the deployment strategy based on technical characteristics such as service type, so that the deployment strategy can match the end characteristics of the service, automatically selecting a more efficient update method and improving resource utilization. The operational experience for different environmental scenarios is solidified into automatically executable decision rules, realizing intelligent and scenario-based selection of deployment strategies without human intervention. This not only significantly reduces the deployment risk caused by differences in human experience, but also eliminates the need for significant manual effort in the deployment process, significantly saving time and manpower costs, and significantly improving deployment effectiveness, automatically matching and selecting the optimal deployment strategy. Attached Figure Description

[0008] Figure 1 A flowchart illustrating the steps of a deployment strategy selection method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the steps of a deployment strategy selection method and strategy selection model provided in this embodiment of the invention; Figure 3 A flowchart of a deployment instruction for a deployment strategy selection method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a cloud server provided in an embodiment of the present invention. Detailed Implementation

[0009] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0012] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0013] With the widespread adoption of cloud computing and microservice architectures, the frequency and complexity of software deployments have increased significantly. Especially in SaaS platform environments, users have increasingly higher demands for service availability, which places greater demands on the software deployment process. Currently, various deployment tools and platforms exist on the market, such as Jenkins, GitLab CI / CD, and Spinnaker, but these tools still have the following technical problems in practical applications: 1. Single and fixed deployment strategy: Most deployment tools only support a single deployment strategy, such as simple replacement deployment; even if they support multiple measurements, they cannot automatically select the most suitable deployment method according to different business scenarios, application characteristics and risk levels; they lack the ability to dynamically adjust the strategy according to real-time conditions during the deployment process.

[0014] 2. Insufficient observability of the deployment process: lack of fine-grained monitoring and recording of the entire deployment process; lack of clear state transitions and dependency management between deployment steps; imperfect handling mechanisms for abnormal situations, lacking automatic recovery capabilities; and difficulty in effectively utilizing historical deployment data, failing to provide experience for subsequent deployments.

[0015] For example, in the field of enterprise application deployment, especially for mission-critical systems, deployment failures or service outages can lead to severe economic losses and a decline in user experience. Industry survey data shows that over 60% of enterprises experience service outages exceeding 24 hours annually due to deployment issues; approximately 70% of deployment problem troubleshooting time is spent on log analysis and status tracking; and nearly 80% of enterprises indicate a need for smarter, more reliable deployment systems to improve service availability.

[0016] Therefore, there is a lack of methods in related technologies that can intelligently select decision paths based on the type of deployment environment and automatically adapt deployment strategies for different environmental scenarios, making precise selections. Related technical solutions often rely on human experience for strategy selection, resulting in inefficiency, inconsistent standards, and deployment risks due to misjudgments.

[0017] To address the aforementioned issues, this application provides a deployment strategy selection method and a cloud server. This method establishes an intelligent traffic distribution mechanism based on environment type and introduces differentiated core decision factors for different environment paths, thereby achieving automated, scenario-based, and precise selection of deployment strategies. The deployment strategy selection method of this application is described in detail below.

[0018] The following details the deployment strategy selection method of this invention, with reference to the appendix. Figure 1 This includes steps 110 to 130.

[0019] Step 110: Obtain the environment type of the environment to be deployed. For example, in a software release management scenario, the system receives a deployment request and obtains its environment type attribute by reading the configuration or analyzing the metadata of the deployment target. The environment type may include: production environment, pre-release environment, test environment, or development environment, etc.

[0020] Step 120: When the environment type is a production environment, the risk level of the service to be deployed is obtained, and the first deployment strategy is confirmed based on the risk level. For example, the system automatically determines the risk level of this update based on the scope of changes included in the deployment version, the stability of historical versions, etc., through predefined rules or risk assessment models. Subsequently, the system will further evaluate the current resource status. Based on this risk level and resource conditions, the first deployment strategy is intelligently selected and confirmed.

[0021] Step 130: When the environment type is other than production or pre-release, the system obtains the service type of the service to be deployed and confirms the second deployment strategy based on the service type. For example, for a test or development environment, the system identifies the service type of the service to be deployed by parsing the service deployment description file, such as distinguishing whether the service is a "stateful service" or a "stateless service". Based on this service type, the system confirms the second deployment strategy.

[0022] This approach achieves automatic identification by acquiring the environment type of the environment to be deployed, eliminating the subjectivity and risk of human judgment. By establishing intelligent routing based on environment type, a differentiated and scenario-based intelligent decision-making mechanism is formed, achieving automation and precision in deployment strategy selection. For production environments, risk classification is used as the core decision factor to automatically confirm the deployment strategy, ensuring that business changes are based on objective assessment rather than subjective experience. For non-production environments, service type is used as the core decision factor, optimizing the deployment strategy according to the service type to match the strategy with the service architecture and automatically selecting the more efficient update method. This differentiated decision-making mechanism not only ensures that the risks of core business changes are controllable and the transition is smooth, but also eliminates the risks of deployment failures and rollbacks caused by differences in human experience and subjective misjudgments, ensuring the predictability and reliability of the software delivery process. At the same time, the deployment process does not require a large amount of manual effort, significantly saving time and labor costs, significantly improving deployment effectiveness, and automatically matching and selecting the optimal deployment strategy.

[0023] In one embodiment of this application, step 120 includes steps 121 to 124.

[0024] Step 121: Obtain the risk level of the service to be deployed and the resource limitations of the current deployment environment. For example, the system determines the risk level of this deployment to be high-risk by calling the risk assessment interface or querying the change management database based on the deployment content. At the same time, the system checks the available resources of the current Kubernetes cluster or cloud resource pool (such as the number of nodes, CPU / memory balance) to determine whether the resource limitation is "sufficient resources" or "limited resources".

[0025] Step 122: If the risk level is high and the resource constraint is sufficient, then confirm the first deployment strategy as blue-green deployment. For example, for a high-risk version update of a core payment service, and if the current cluster has enough idle nodes to fully deploy a parallel environment, the system confirms the adoption of the blue-green deployment strategy.

[0026] Step 123: If the risk level is high and the resource constraint is limited, then the primary deployment strategy is confirmed as canary deployment. For example, for a high-risk update of the same core payment service, but the current production environment is resource-constrained and cannot bear the resource overhead required to run two complete environments simultaneously, the system confirms the adoption of the canary deployment strategy. This strategy will first deploy a small number of new version instances in the existing environment and redirect a small amount of user traffic to these new instances for verification. After confirmation, the proportion of new version instances will be gradually increased until they are completely replaced.

[0027] Step 124: If the risk level is low, confirm the primary deployment strategy as either rolling update or re-creation. For example, for a low-risk front-end service update that only modifies the front-end style, the system defaults to a rolling update strategy, updating the service by gradually replacing the old version container instance. This is imperceptible to users and consumes minimal resources. If the service is stateful, the system will choose a re-creation strategy, which involves completely creating a new instance after stopping the old one. This is suitable for backend processing services with low availability requirements.

[0028] In this way, by correlating risk levels with real-time resource status, the system enables refined strategy selection while ensuring deployment security. This not only ensures that the safest blue-green deployment is prioritized when resources allow, but also automatically downgrades to a manageable canary release when resources are limited, or directly selects the most efficient rolling update or re-creation when the risk is low. It dynamically balances stability requirements and resource constraints during the deployment process at the decision-making level, achieving a balance between security and economy.

[0029] In one embodiment of this application, step 130 includes steps 131 to 134.

[0030] Step 131: Obtain the service type and traffic importance of the service to be deployed. For example, the system identifies the service type of the service to be deployed by parsing the service's deployment description file. At the same time, the system determines the traffic importance of the service to be deployed based on its position in the business architecture or historically monitored traffic metrics.

[0031] Step 132: If the service type is stateless and its traffic importance is high, then confirm the second deployment strategy as blue-green deployment or canary deployment. For example, for a stateless API gateway service that handles user login authentication, its traffic importance is marked as high. Based on this, the system confirms that blue-green deployment or canary deployment can be used as the second deployment strategy. If resources allow and a zero-disruption experience is desired, blue-green deployment is chosen; if a more gradual observation of the new version's performance under real traffic is desired, canary deployment is chosen. This decision ensures that high-traffic, stateless core services can maintain service continuity while controlling potential risks during updates.

[0032] Step 133: If the service type is stateless and the traffic importance is low, then confirm that the second deployment strategy is rolling updates. For example, for an internally used data analysis report generation service, its service type is stateless and its traffic importance is low. The system confirms that rolling updates are adopted as the second deployment strategy. This strategy will gradually replace the old version of the container instance, updating one or a small batch at a time. The service remains available throughout the update process, and the resource requirements are the most economical, making it very suitable for this type of background service that is not sensitive to interruptions and has low traffic.

[0033] Step 134: If the service type is a stateful service, then confirm that the second deployment strategy is recreation. For example, for a stateful cache or database service that has deployed Redis or MySQL, the system identifies its service type as a stateful service. Since stateful services typically involve persistent data, they cannot be easily replaced by rolling instance replacement or run in parallel, so the system confirms recreation as the second deployment strategy.

[0034] In this way, by combining the service type of the service to be deployed with the importance of traffic for comprehensive decision-making, the system achieves intelligent optimization of deployment strategies in non-production environments and similar scenarios. This ensures alignment between technical strategies and business attributes: for critical stateless services, a more cautious release strategy is adopted to guarantee user experience; for non-critical or stateless services, an efficient and economical update method is used; and for stateful services, a secure and reliable update mode is adopted, respecting their data persistence characteristics. By addressing both technical implementation and business needs, the selection of deployment strategies is both scientifically sound and aligned with actual operational scenarios, improving the intelligence level and overall efficiency of the software release process.

[0035] In one embodiment of this application, step 140 is also included.

[0036] Step 140: When the environment type is a pre-release environment, obtain the service type of the service to be deployed, and confirm the third deployment strategy based on the service type and traffic importance. For example, for a service version that is about to be launched in the production environment, the system first deploys it to the pre-release environment for final integration verification. In this scenario, the system will obtain the service type and its traffic importance under simulated production traffic.

[0037] This approach, by establishing an independent deployment strategy decision path for the pre-release environment transition phase, improves end-to-end deployment governance from development to production. This design means that the pre-release environment no longer simply applies the strategies of the production or testing environment, but instead assumes the dual responsibility of production simulation and risk mitigation. By intelligently selecting strategies such as canary releases in this environment to perform verification close to real-world scenarios, performance and compatibility issues can be identified to the greatest extent possible before final deployment. This establishes a critical quality barrier at the end of the software delivery pipeline, further improving the success rate of production deployment.

[0038] In one embodiment of this application, step 140 includes steps 141 to 143.

[0039] Step 141: If the service type is stateless and the traffic importance is high, then confirm the third deployment strategy as blue-green deployment or canary release. For example, for a stateless user authentication service that will soon carry core transaction traffic in the production environment, its traffic importance in the pre-release environment is high. In this case, the system will prioritize blue-green deployment or canary release as the third deployment strategy. If blue-green deployment is adopted, the zero-downtime switchover process of the production environment can be fully simulated in the pre-release environment to verify the stability of the new version integration with the entire ecosystem; if canary release is adopted, simulated production traffic can be gradually imported into the new version instance to finely observe its performance indicators and error rate under real load, providing accurate data decision support for production release.

[0040] Step 142: If the service type is stateless and its traffic importance is low, then confirm that the third deployment strategy is rolling updates. For example, for a stateless service in an internal management backend, which is mainly used for functional acceptance in the pre-release environment and has low traffic importance, the system confirms that rolling updates are adopted as the third deployment strategy. This strategy can complete version updates without interrupting service, making it suitable for rapid, continuous, multi-round functional iteration verification in the pre-release environment. It focuses on ensuring the correctness of functions rather than high availability drills, thereby saving environmental resources and improving verification efficiency.

[0041] Step 143: If the service type is a stateful service, confirm that the third deployment strategy is recreation. For example, for a stateful data analytics service in a pre-release environment. Because stateful service instances are tightly bound to persistent data, it is difficult to achieve lossless traffic switching or gradual replacement. Therefore, the system confirms recreation as the third deployment strategy. This strategy will perform a data snapshot backup before deployment, then stop the old instance and completely create a new version instance. It is suitable for verifying the correctness of the startup, data loading, and migration processes of the new version of stateful applications.

[0042] In this way, by subdividing deployment strategies for the pre-release environment, a precise match between verification objectives and deployment methods is achieved. For high-traffic stateless services, blue-green or canary deployments are used to simulate real production change processes for release drills and risk identification. For low-traffic or stateless services, efficient rolling updates are used to accelerate the functional verification cycle. For stateful services, a prudent re-creation strategy is adopted according to their data characteristics to ensure the reliability of data consistency verification. This refined and differentiated pre-release environment deployment strategy management not only improves the effectiveness and authenticity of pre-release verification but also optimizes the resource utilization efficiency and operational complexity of the pre-release environment itself.

[0043] In one embodiment of this application, steps 150 and 151 are also included.

[0044] Step 150: Determine if a pre-specified deployment policy exists for the current deployment task. For example, before starting the automated deployment process, the system will first check whether the current deployment task is associated with a forced deployment policy explicitly configured by the operations administrator through the management interface, or whether it matches a predefined deployment policy template for a specific service or scenario in the system.

[0045] Step 151: If a pre-specified deployment policy is detected, the pre-specified deployment policy is directly adopted, and the subsequent policy confirmation process is terminated. For example, when an administrator knows that a major database version update must use a re-creation policy to ensure data migration security, this policy can be pre-specified in the task. After the system detects this specification, it will terminate the automatic analysis of factors such as environment type, risk level, and service type, and directly use the specified re-creation policy to perform the deployment. The subsequent policy confirmation process includes steps 110 to 143.

[0046] In this way, by introducing a policy-prioritized mechanism at the top of the intelligent decision-making chain, an effective balance between automation and controllability is achieved. This mechanism enables the automated system to operate intelligently in most scenarios, while smoothly and seamlessly transferring control to operations personnel when encountering known complex scenarios, executing specific operational instructions, or conducting policy testing. This not only enhances the system's adaptability to edge cases and special needs but also increases the operations team's trust in and sense of control over the automated processes, thereby constructing an efficient and reliable decision-making closed loop within a human-machine collaborative software delivery system.

[0047] In one embodiment of this application, steps 160 and 161 are also included.

[0048] Step 160: Based on historical deployment success rate data, verify whether the confirmed deployment strategy's success rate under the current risk level and service type combination is higher than the success rate threshold. For example, after determining to adopt the "canary deployment" strategy for a high-risk, stateless service, the system will query the deployment history database. The system will filter out all historical deployment records using the "canary deployment" strategy under the combination of "high-risk level" and "stateless service type," and calculate its average success rate (e.g., 95%). Subsequently, the system compares this historical success rate with a preset threshold (e.g., 98%) to verify whether the historical performance of this strategy selection meets the expected standards.

[0049] Step 161: If the success rate falls below the threshold, trigger a strategy reselection or alert. For example, if the calculated historical success rate (95%) is lower than the threshold (98%), it indicates that choosing the canary deployment strategy may not be optimal or may pose potential risks under the current risk and service type combination. In this case, the system will automatically trigger a strategy reselection process, such as re-evaluating and recommending a deployment strategy with a higher historical success rate as an alternative strategy. Alternatively, the system may send an alert notification, indicating that "the historical success rate of the currently recommended strategy is 95%, which is lower than the safety threshold of 98%. Please evaluate carefully."

[0050] In this way, by introducing a post-decision verification mechanism based on historical data, the automated deployment decision-making system gains crucial experience feedback and risk warning capabilities. It can not only make decisions based on real-time rules but also learn from past successes and failures, using data to quantitatively assess the reliability of decisions. When the system identifies a decision as performing poorly in similar historical scenarios, it can proactively question itself and provide better alternatives, effectively avoiding repetitive errors that automation might cause. This enhances the maturity and credibility of the intelligent decision-making system, evolving it from a simple rule-executing system into a decision-making partner with continuous learning and risk perception capabilities. Ultimately, while improving the level of deployment automation, it also strengthens the last intelligent line of defense for production stability.

[0051] In one embodiment of this application, steps 170 and 171 are also included.

[0052] Step 170: During the deployment process according to the confirmed deployment strategy, the system monitors preset system performance metrics in real time. For example, when executing a rolling update strategy, the system continuously monitors the key metrics of the new version and compares these real-time metrics with preset baseline thresholds.

[0053] Step 171: In response to monitoring information indicating abnormal system performance metrics, switch the current deployment strategy to an alternative deployment strategy. For example, during a rolling update, if the system detects that the error rate of newly deployed instances rapidly increases to 5% and triggers the alarm threshold, it will immediately interrupt the current rolling update process. The system will gradually roll back the updated new version instances to the old version. If blue-green deployment is used and serious performance issues are found in the new environment, the system may perform a strategy switch, changing the strategy from dynamic blue-green deployment to canary deployment. This means that only a very small portion of traffic is diverted to the new environment for problem diagnosis, rather than performing a full switch, thereby minimizing the impact of the failure.

[0054] In this way, by deeply integrating dynamic strategy switching mechanisms with real-time monitoring, a closed-loop system of awareness and response is achieved in the deployment process. This transforms the deployment system from a rigid process of executing preset instructions into an intelligent agent capable of adaptively adjusting based on runtime states. When potential risks or actual failures are detected, the system can proactively switch from one deployment strategy to a safer, more conservative one, thus intervening before the problem escalates. This dynamic self-healing capability greatly enhances the resilience and availability of complex distributed systems during changes, transforming deployment activities from high-risk operations into a controllable, observable, and recoverable routine process, ultimately providing a solid technical guarantee for the continuous and stable operation of business.

[0055] In one embodiment of this application, steps 180 and 181 are also included.

[0056] Step 180: Acquire and analyze historical execution data. For example, the system continuously collects and stores all historical execution data to build a deployment data center. Each piece of historical execution data includes: task identifier, environment type, initial risk level derived from automation rules, initial service type, final confirmed deployment strategy, key indicators of the deployment process, and the final success or failure status of the deployment.

[0057] Step 181: Based on historical execution data, calibrate the initial judgment results of the risk level of the first deployment strategy or the service type of the second deployment strategy to generate calibrated input information for determining the first or second deployment strategy. For example, the system uses data analysis tools to perform periodic or trigger-based batch analysis of historical execution data and finds that for a specific query service, when the change is only a front-end interface adjustment, 90% of deployments were initially judged as high-risk by the rules, but the actual deployment success rate was as high as 99.9%. This indicates that the initial risk judgment rule is too conservative for such scenarios. Based on this, the system automatically generates a calibration rule: when the service is deployed again and the change type is a front-end interface adjustment, calibrate its initial risk level from high risk to low risk. When a similar deployment task is initiated next time, the system will apply this calibration rule, using the calibrated low-risk level as input, and enter the decision-making process of step 120, thereby potentially selecting a more efficient deployment strategy and avoiding unnecessary security redundancy and resource consumption.

[0058] In this way, by establishing a closed loop of experience learning and feedback calibration for deployment decisions, the system acquires the ability to continuously self-optimize. It no longer relies on unchanging static rules, but instead extracts knowledge from massive amounts of real-world deployment results, identifying biases, overfitting, or missing contextual relationships in the initial judgment rules. By transforming these data insights into dynamic calibration of core decision factors, the system can continuously correct its cognitive model, making subsequent automated decisions more accurate and realistic. This not only improves the accuracy and cost-effectiveness of strategy selection but also fundamentally enhances the adaptability of automated processes to complex and dynamic business scenarios.

[0059] The following is in conjunction with the appendix Figure 2 This application provides specific implementation examples, demonstrating how the above solutions can be applied to software release and continuous deployment scenarios in various cloud-native environments, particularly in scenarios where large enterprises release versions of their core online services. Taking an e-commerce platform's core payment service version upgrade as an example, the steps include: S1. During the version preparation phase, the development team generates deployment tasks for the payment service to be updated using the continuous deployment platform. The system receives version information and associated deployment context from the code repository through the deployment management interface, including key parameters such as environment type, service identifier, and changes. This is equivalent to step 110 above.

[0060] S2. The deployment platform initiates a decision-making process, first checking if a manually specified deployment strategy exists. If the deployment administrator has explicitly specified the "canary release" strategy in the task, the system will directly adopt this strategy, skipping subsequent rule engine analysis. If not manually specified, the system queries the configuration template library to find a predefined template matching the current deployment task. If a matching template is found and the conditions are met, the template configuration is executed; if no template is found or the conditions are not met, the system enters the rule engine analysis stage. The deployment platform initiates an intelligent strategy decision-making process based on the received environment type information. For example, for a payment service deployment task targeting a "production environment," the system automatically obtains the risk assessment level of that version; for a backend service deployment task targeting a "test environment," the system identifies its service type. This is equivalent to steps 120 and 130 above. This step realizes the transformation from a general deployment request to a specific strategy decision, laying the foundation for subsequent differentiated deployment execution and demonstrating the invention's ability to perceive the environment and intelligently distribute resources.

[0061] S3. Based on decision factors obtained under different environmental paths, the system confirms the deployment strategy through preset strategy mapping rules. For example, for high-risk payment service updates in the production environment, and when sufficient resources are detected, the system determines to adopt a "blue-green deployment" strategy; for stateless backend services in the test environment, the system determines to adopt a "rolling update" strategy. This is equivalent to step 140 above. This process embodies the intelligent decision-making mechanism of risk and efficiency synergy of the present invention, effectively solving the problems of single strategy selection and insufficient protection of key services in traditional solutions, ensuring the security of core business deployment and the efficiency of non-core service deployment, and improving the reliability of software delivery and the rationality of resource allocation from a mechanism perspective.

[0062] S4. Based on the deployment strategy decision, the system drives the corresponding deployment engine to execute specific operations. For example, for a blue-green deployment strategy, the system first fully deploys the new version of the payment service in an isolated environment, establishing a parallel running environment; for a rolling update strategy, the system gradually replaces the running instances of the backend service in batches. This is equivalent to steps 150, 151, and 152 above. This mechanism ensures that deployment tasks of different risk levels and service types can obtain the most suitable execution method, reflecting the deployment advantages of this invention that balance stability and efficiency, and effectively solving the problem of excessive risk or resource waste in a single deployment scheme.

[0063] S5. During deployment, the system continuously monitors the service status and supports dynamic policy adjustments. If anomalies are detected in key metrics of the new version service, the system can automatically interrupt the current policy and switch to a safe rollback policy; if deployment is successful, traffic switching or instance updates are completed, and a complete deployment history is recorded. This is equivalent to steps 160 to 164 above. This closed-loop process ensures that problematic versions can be quickly isolated and rolled back, fundamentally eliminating the risk of online spread of faulty versions, demonstrating the self-healing capability and security assurance of this invention during deployment.

[0064] Through the above application examples, this invention implements a deployment strategy selection method, completing closed-loop management of the entire process from environment identification, intelligent decision-making, strategy execution to process monitoring. This solution effectively addresses the differentiated deployment issues of services with different environments and risk levels in complex cloud-native environments. While improving the security and success rate of core business deployments, it significantly optimizes overall software delivery efficiency and resource utilization.

[0065] The following is in conjunction with the appendix Figure 3 This document details the deployment instruction process for the deployment strategy selection method described in this application. Taking an e-commerce platform's implementation of the selected "blue-green deployment" strategy for its core payment service as an example, the process includes the following steps: S11. The system receives a deployment request from the policy decision module and initiates the deployment instruction process. This request includes the determined deployment policy, target service information, version image, etc. The system first verifies the legality and status of the release record to ensure that it will not be executed repeatedly or conflict. After successful verification, the release status is updated to "In Progress," and a deployment start notification is sent to relevant system components and personnel. This is equivalent to step 110 above.

[0066] S12. Based on the policy identifier in the deployment request, the system calls the corresponding deployment policy implementation module. Taking the blue-green deployment policy as an example, the system selects the deployment logic corresponding to this policy and creates the required deployment instance. Then, it executes the policy-specific deploy method, which generates a detailed list of steps for this deployment, including resource preparation, image retrieval, configuration injection, and service registration. This is equivalent to steps 120 to 130 above.

[0067] S13. The system executes each step in the deployment step list sequentially. For each step, the system saves the command to be executed, grants necessary permissions, and then executes the corresponding Shell command or API call. For example, executing the Shell command to "create a namespace" or calling the cloud platform API to "create a load balancer". If a step fails, the system will catch the exception, update the step status to failure, and decide whether to continue execution or terminate immediately based on policy settings. If all steps execute successfully, the step status is updated to success. This process repeats until all steps are completed. This is equivalent to steps 140 to 150 above.

[0068] S14. After all deployment steps have successfully completed, the system enters the deployment completion check phase. This phase performs deployment completion checks and confirms the execution results. For example, the system checks whether all resources in the newly created green environment are ready, whether all service instances have started successfully, and confirms that there are no unhandled exceptions during the deployment process. If the checks pass, the release status is updated, and the final deployment result is returned, marking the completion of a deployment cycle. This is equivalent to steps 160 to 161 above.

[0069] S15. After successful traffic switching and confirmation of stable operation in the new environment, the system updates the deployment status to "Completed" and sends a deployment success notification to relevant parties. If an anomaly occurs during the check or switching process, the system will automatically trigger a rollback process according to the policy and update the deployment status to "Failed." Finally, the system returns a complete deployment result report, including execution details, time consumption, and final status for each step. Logs and metrics throughout the process are persistently stored for auditing and analysis. This is equivalent to steps 170 to 180 above.

[0070] The aforementioned deployment command process achieves a seamless transition from policy decision-making to physical execution. Through rigorous step-by-step execution, real-time status tracking, and health verification, this process ensures the controllability and reliability of deployment operations. This not only achieves full automation of the deployment process but also significantly improves transparency and problem diagnosis efficiency through clear step divisions and status management, providing solid technical support for secure and efficient software delivery in complex cloud-native environments.

[0071] In summary, this invention constructs a deployment strategy selection method. By employing differentiated decision paths and core decision factors in different deployment environments, a dynamic strategy selection model is built based on deployment tasks, achieving closed-loop intelligent management of software deployment from decision-making to execution. The system can automatically adapt corresponding decision logic and strategy mapping rules according to different environment types. For deployment tasks with different risk levels and service types, the system can output differentiated deployment strategies.

[0072] Simultaneously, based on the context information of the deployment task, the system obtains a strategy template that matches the specific scenario and aligns with business objectives as the core decision-making basis, thereby generating dynamic strategy selection rules adapted to actual deployment needs. In terms of deployment strategy decision-making, the system comprehensively considers multiple dimensions such as environment type, risk level, service type, traffic importance, and resource constraints, and performs collaborative analysis and weight calculation through a pre-set rule engine to derive the final target deployment strategy.

[0073] Furthermore, during the deployment strategy execution process, the system also considers the continuity of deployment anomalies and establishes a dynamic strategy adjustment mechanism based on historical data verification and runtime monitoring. When poor strategy execution performance or abnormal system metrics are detected, the system can trigger a strategy reselection or strategy switching process based on the real-time status, ensuring that critical business deployments are always under control, thereby achieving a balance between security and efficiency in the deployment process.

[0074] By constructing a complete intelligent selection and management system for deployment strategies, this system effectively improves the automation level and scientific nature of the software delivery process, enhances the system's ability to cope with different business risks, and optimizes the efficiency of computing resource utilization and operation and maintenance costs.

[0075] Please refer to Figure 4 The present invention also provides a cloud server 300, including a memory 301 and a processor 302, and a computer program stored on the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the various steps in the deployment strategy selection method described above.

[0076] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0077] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A deployment strategy selection method, characterized in that, Applied to cloud servers, the method includes: Obtain the environment type of the environment to be deployed; When the environment type is a production environment, the risk level of the service to be deployed is obtained, and the first deployment strategy is confirmed based on the risk level. When the environment type is an environment other than the production environment and the pre-release environment, the service type of the service to be deployed is obtained, and the second deployment strategy is confirmed based on the service type.

2. The deployment strategy selection method according to claim 1, characterized in that, When the environment type is a production environment, the risk level of the service to be deployed is obtained, and a first deployment strategy is determined based on the risk level, including: Obtain the risk level of the service to be deployed and the resource limitations of the current deployment environment; If the risk level is high risk and the resource constraint is sufficient resources, then the first deployment strategy is confirmed to be blue-green deployment; If the risk level is high risk and the resource restriction condition is resource-limited, then the first deployment strategy is confirmed as canary release; If the risk level is low, then the first deployment strategy is confirmed to be rolling update or re-creation.

3. The deployment strategy selection method according to claim 1, characterized in that, When the environment type is an environment other than the production environment and pre-release environment, the service type of the service to be deployed is obtained, and a second deployment strategy is confirmed based on the risk level, including: Obtain the service type and traffic importance of the service to be deployed; If the service type is a stateless service and the traffic importance is high, then the second deployment strategy is confirmed to be blue-green deployment or canary release; If the service type is a stateless service and the traffic importance is low, then the second deployment strategy is confirmed to be rolling update; If the service type is a stateful service, then the second deployment strategy is confirmed to be recreate.

4. The deployment strategy selection method according to claim 1, characterized in that, Also includes: When the environment type is a pre-release environment, the service type of the service to be deployed is obtained, and a third deployment strategy is confirmed based on the service type and traffic importance.

5. The deployment strategy selection method according to claim 4, characterized in that, The third deployment strategy, determined based on the service type and traffic importance, includes: If the service type is a stateless service and the traffic importance is high, then the third deployment strategy is confirmed to be blue-green deployment or canary release; If the service type is a stateless service and the traffic importance is low, then the third deployment strategy is confirmed to be rolling update; If the service type is a stateful service, then the third deployment strategy is confirmed to be recreate.

6. The deployment strategy selection method according to claim 1, characterized in that, Also includes: Determine if a deployment strategy pre-specified for the currently deployed task exists; If the pre-specified deployment policy is detected, the pre-specified deployment policy is directly adopted, and the subsequent policy confirmation process is terminated.

7. The deployment strategy selection method according to claim 1, characterized in that, Also includes: Based on historical deployment success rate data, verify whether the deployment success rate of the confirmed deployment strategy under the current combination of risk level and service type is higher than the success rate threshold. If the success rate falls below the threshold, a strategy reselection or alarm will be triggered.

8. The deployment strategy selection method according to claim 1, characterized in that, Also includes: During the deployment process based on the confirmed deployment strategy, preset system performance indicators are monitored in real time. In response to the detection of abnormal system performance indicators, the current deployment strategy is switched to another alternative deployment strategy.

9. The deployment strategy selection method according to claim 1, characterized in that, Also includes: Acquire and analyze historical execution data; Based on the historical execution data, the initial judgment results of the risk level of the first deployment strategy or the service type of the second deployment strategy are calibrated to generate calibrated input information for determining the first deployment strategy or the second deployment strategy.

10. A cloud server, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement a deployment strategy selection method as described in any one of claims 1 to 9.

Images