A point deployment control method and related device

Abstract

A site deployment control method includes: receiving a pipeline execution request, the pipeline execution request including an identifier of a target pipeline to be executed, the target pipeline including at least one commit / release stage and at least one deployment stage; during the execution of the target pipeline, when execution reaches the first commit / release stage of the at least one commit / release stage, providing a decision interface to the user; receiving the first site and / or first node to be deployed selected by the user through the decision interface; and deploying the first site and / or first node. This method introduces a special pipeline stage, namely the commit / release stage, which allows adjustment of the deployment order based on the actual business scenario during pipeline execution. Specifically, it allows deployment of different sites and nodes according to the order of sites and nodes selected by the user, and also allows skipping unavailable sites, thereby improving deployment flexibility and fault tolerance.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a local deployment control method, deployment platform, computing device cluster, computer-readable storage medium, and computer program product. Background Technology

[0002] With the continuous development of cloud computing, more and more cloud services and enterprise applications are adopting multi-site deployment strategies to ensure high availability and disaster recovery capabilities. A site is the smallest deployment unit, which can be a single machine, a data center, or a region. Multi-site deployment distributes data centers across multiple geographical locations, ensuring that if a system fails at one site, it can automatically switch to other sites, thus avoiding the impact of single points of failure and ensuring business continuity.

[0003] At each site, multiple service nodes may be deployed to meet the business traffic demands of different services or applications. These service nodes can be horizontally scaled or load-balanced as needed to ensure stable service performance even during peak periods. Through flexible deployment and redundancy design, the multi-site architecture not only improves the system's fault tolerance but also optimizes resource allocation and network latency, enhancing the overall user experience.

[0004] In mainstream Continuous Integration / Continuous Delivery (CI / CD) deployment platforms, for multi-site deployments, users typically need to plan and orchestrate the deployment order and deployment strategy for each site in advance within a predefined pipeline, and then execute the deployment tasks one by one in sequence.

[0005] This approach requires users to consider the deployment needs, dependencies, and priorities of different sites during the pipeline design phase. It typically necessitates manually adjusting the deployment order across multiple sites and confirming relevant configurations at each pipeline stage. Once the pipeline starts, the execution steps are fixed and cannot be dynamically adjusted during operation. This results in an inflexible control over the release order of sites, batch deployment of all sites, or skipping specific steps when encountering problematic sites, making it difficult to meet business requirements. Summary of the Invention

[0006] This application provides a site deployment control method that dynamically generates pipeline stages and tasks that meet actual business needs based on different deployment scenarios and site requirements, thereby improving deployment flexibility and fault tolerance during pipeline execution. This application also provides a deployment platform, a computing device cluster, a computer-readable storage medium, and a computer program product.

[0007] Firstly, this application provides a site-specific deployment control method. This method is applied to a deployment platform, such as a Continuous Integration / Continuous Delivery (CI / CD) deployment platform. The deployment platform may include a pipeline execution engine for executing pipelines, thereby achieving multi-site deployment. The deployment platform may include a software system, which can be standalone software or integrated into other software as plugins, components, functional modules, services, etc. In some examples, the deployment platform may also include a hardware system; for example, the deployment platform may include a cluster of computing devices with site-specific deployment control capabilities. When the computing device cluster runs, it executes the site-specific deployment control method of this application.

[0008] In practice, the deployment platform can receive pipeline execution requests. These requests include an identifier for the target pipeline to be executed. The target pipeline includes at least one commit / release stage and at least one deployment stage. During the execution of the target pipeline, when execution reaches the first commit / release stage, the deployment platform can provide a decision interface to the user. This interface displays at least one of the deployable sites or nodes in the first deployment stage corresponding to the first commit / release stage. The deployment platform can receive the first site and / or first node selected by the user through the decision interface. The first site can be one or more deployable sites, and the first node can be one or more deployable nodes. Accordingly, the deployment platform can deploy the first site and / or first node.

[0009] In this method, users can dynamically generate pipeline stages and tasks that meet actual business needs based on different deployment scenarios and site requirements. Specifically, this method introduces a special pipeline stage, the "Submit Deployment" stage, which includes a special "Submit Deployment" checkpoint task that precedes the deployment stage. During pipeline execution, the deployment order can be adjusted based on the actual business scenario through these tasks. Specifically, different sites and nodes can be deployed according to the order selected by the user, thereby improving deployment flexibility and fault tolerance. Furthermore, for new or special deployment scenarios, this method does not require modifying existing pipelines or creating a new dedicated pipeline. Instead, through automated pipeline management, it efficiently executes deployment tasks across multiple sites and scenarios, ensuring the compliance, reliability, and efficiency of the deployment process while reducing pipeline maintenance costs and deployment risks.

[0010] In some possible implementations, when the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the deployment platform can also provide a decision interface to the user. The deployment platform receives a second site and / or a second node selected by the user through the decision interface, where the second site is one or more deployable sites, and the second node is one or more deployable nodes. Accordingly, the deployment platform can deploy the second site and / or the second node.

[0011] In this way, the first site / first node and the second site / second node can be deployed in batches according to business needs, improving deployment flexibility.

[0012] In some possible implementations, when the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the deployment platform can also provide a decision interface to the user. Accordingly, the deployment platform can also receive third sites and / or third nodes selected by the user through the decision interface, where the third site is one or more deployable sites, and the third node is one or more deployable nodes. For example, the third site may be a site that has failed and become unavailable, and the third node may be a node that has failed and become unavailable. Accordingly, the deployment platform may choose not to deploy the third site and / or third node.

[0013] This method supports skipping specified nodes in the pipeline. In this case, the pipeline execution will not be blocked and the pipeline can continue to run. This improves the efficiency of pipeline execution, as well as its flexibility and fault tolerance.

[0014] In some possible implementations, the deployment platform can generate dynamic deployment phases and deployment tasks corresponding to the first site and / or the first node, and insert these phases and tasks into the target pipeline. The deployment tasks are used to deploy the first site and / or the first node. When execution reaches the dynamic deployment phase, the deployment platform can execute the deployment tasks.

[0015] The deployment control method presented in this application is a multi-site deployment control method based on dynamic user interaction. This method allows users to dynamically generate deployment stages and tasks in a pipeline based on selected sites and nodes. This flexible mechanism enables the adjustment of task execution order and conditions according to user expectations. For example, when releasing patching vulnerabilities in the live network, deployment can be quickly completed on all live sites; while when releasing new features, deployment can be prioritized to some key sites, and then the update can be gradually rolled out to other sites. This ensures an efficient and unblocked deployment process.

[0016] In some possible implementations, the deployment platform can deploy the first site and / or the first node according to a configured deployment strategy. These deployment strategies include rolling deployment, blue-green deployment, canary release, or custom deployment strategies. This method also supports deployment based on the user-selected deployment strategy, offering high flexibility.

[0017] In some possible implementations, before receiving pipeline execution requests, the deployment platform may also provide a pipeline configuration page to receive metadata about the target pipeline configured through the pipeline configuration page. This metadata includes metadata for at least one submission / release stage and metadata for at least one deployment stage. The deployment platform can then generate the target pipeline based on this metadata.

[0018] This method supports setting a commit / release phase for the deployment stage in the pipeline during pipeline configuration. When the commit / release phase is reached, it provides dynamic adjustment capabilities, allowing users to dynamically select the deployment sites, nodes, etc., to be deployed, thus improving deployment flexibility. The pipeline can automatically adjust the task execution order according to the actual deployment environment and requirements, ensuring that the deployment process is both flexible and efficient in multi-site deployment and continuous release scenarios, thereby improving the stability and adaptability of the software development and delivery process.

[0019] In some possible implementations, the deployment platform receives task group information for at least one deployment stage configured via a pipeline page and task information for at least one deployment task in the task group. The task group information includes at least one of the following: task deployment location, task deployment node, and task execution order. The task information includes at least one of the following: task type, task name, environment, and deployment strategy.

[0020] This method allows users to edit the deployment phase when defining a pipeline, adding deployment sites and deployment tasks under those sites, laying the foundation for subsequent dynamic adjustments to the pipeline.

[0021] In some possible implementations, the deployment platform can receive task information for a submission and release task configured through at least one submission and release stage via the pipeline page. The task information includes at least one of the following: task type, task name, and checkpoint validity period.

[0022] This method allows users to edit the commit and release phase when defining the pipeline, adding commit and release tasks, laying the foundation for subsequent dynamic adjustments to the pipeline.

[0023] Secondly, this application provides a deployment platform. The deployment platform includes:

[0024] An interaction module is used to receive pipeline execution requests, wherein the pipeline execution request includes an identifier of a target pipeline to be executed, and the target pipeline includes at least one submission and release phase and at least one deployment phase;

[0025] The interaction module is also used to provide a decision interface to the user when the execution of the target pipeline reaches the first submission and release stage in the at least one submission and release stage during the execution of the target pipeline. The decision interface is used to display at least one of the deployable sites or deployable nodes in the first deployment stage corresponding to the first submission and release stage.

[0026] The interaction module is further configured to receive the first deployment site and / or the first node selected by the user through the decision interface, wherein the first deployment site is one or more deployment sites among the deployable sites, and the first node is one or more nodes among the deployable nodes;

[0027] An execution module is used to deploy the first site and / or the first node.

[0028] In some possible implementations, the interaction module is also used for:

[0029] If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user.

[0030] Receive the second site and / or second node selected by the user through the decision interface, wherein the second site is one or more sites among the deployable sites, and the second node is one or more nodes among the deployable nodes;

[0031] The execution module is also used for:

[0032] Deploy the second site and / or the second node.

[0033] In some possible implementations, the interaction module is also used for:

[0034] If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user.

[0035] The system receives the third location and / or third node selected by the user through the decision interface, wherein the third location is one or more of the deployable locations and the third node is one or more of the deployable nodes.

[0036] The execution module is also used for:

[0037] The third location and / or the third node shall not be deployed.

[0038] In some possible implementations, the execution module is specifically used for:

[0039] Generate dynamic deployment phases and deployment tasks corresponding to the first site and / or the first node;

[0040] The dynamic deployment phase and the deployment task are inserted into the target pipeline, and the deployment task is used to deploy the first site and / or the first node.

[0041] When the process reaches the dynamic deployment phase, the deployment task is executed.

[0042] In some possible implementations, the execution module is specifically used for:

[0043] According to the configured deployment strategy, the first site and / or the first node are deployed, and the deployment strategy includes rolling deployment, blue-green deployment, canary release or custom deployment strategy.

[0044] In some possible implementations, the interaction module is also used for:

[0045] Before receiving the pipeline execution request, a pipeline configuration page is provided;

[0046] Receive metadata of the target pipeline configured through the pipeline configuration page, the metadata including metadata of the at least one submission and release stage and metadata of the at least one deployment stage;

[0047] The platform also includes:

[0048] The generation module is used to generate the target pipeline based on the metadata of the target pipeline.

[0049] In some possible implementations, the interaction module is specifically used for:

[0050] The system receives task group information for at least one deployment stage configured through the pipeline page, and task information for at least one deployment task in the task group. The task group information includes at least one of the following: task deployment location, task deployment node, and task execution order. The task information includes at least one of the following: task type, task name, environment, and deployment strategy.

[0051] In some possible implementations, the interaction module is specifically used for:

[0052] Receive task information for the submission and release task in the at least one submission and release stage configured through the pipeline page, wherein the task information includes at least one of the following: task type, task name, and checkpoint validity period.

[0053] Thirdly, this application provides a computing device cluster. The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory to cause the computing device or the computing device cluster to perform the local deployment control method as described in the first aspect or any implementation thereof.

[0054] Fourthly, this application provides a computer-readable storage medium storing instructions that instruct a computing device or a cluster of computing devices to execute the local deployment control method described in the first aspect or any implementation thereof.

[0055] Fifthly, this application provides a computer program product containing instructions that, when run on a computing device or a cluster of computing devices, causes the computing device or cluster of computing devices to execute the local deployment control method described in the first aspect or any implementation thereof.

[0056] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0057] To more clearly illustrate the technical methods of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below.

[0058] Figure 1 A flowchart of a pipeline configuration is provided in this application;

[0059] Figure 2 A configuration interface diagram for a pipeline stage provided in this application;

[0060] Figure 3 A schematic diagram of an assembly line provided in this application;

[0061] Figure 4 A schematic diagram of the structure of a deployment platform provided in this application;

[0062] Figure 5A A flowchart of a local deployment control method provided in this application;

[0063] Figure 5B A schematic diagram of a target pipeline provided in this application;

[0064] Figure 6 A schematic diagram of a decision interface for the first stage of submission and publication provided in this application;

[0065] Figure 7 A schematic diagram illustrating a deployment at a single location provided in this application;

[0066] Figure 8 A schematic diagram illustrating the insertion of newly generated stages and tasks into a pipeline, as provided in this application;

[0067] Figure 9 A schematic diagram illustrating the changes in different stages of pipeline execution provided in this application;

[0068] Figure 10 This application provides a schematic diagram of the stages and tasks executed in the actual pipeline after the dynamic generation of the task stage.

[0069] Figure 11 A flowchart illustrating the process of generating and executing deployment tasks provided in this application;

[0070] Figure 12 A flowchart illustrating a pipeline configuration provided in this application;

[0071] Figure 13 A schematic diagram of a task group configuration interface provided in this application;

[0072] Figure 14 A schematic diagram of a deployment task configuration interface provided in this application;

[0073] Figure 15 A schematic diagram of a task submission and deployment configuration interface provided for this application;

[0074] Figure 16 A schematic diagram of the structure of a computing device provided in this application;

[0075] Figure 17 This application provides a schematic diagram of the structure of a computing device cluster;

[0076] Figure 18 This application provides a schematic diagram of another computing device cluster structure.

[0077] Figure 19 This is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0078] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0079] First, some technical terms involved in the embodiments of this application will be introduced.

[0080] Continuous Integration (CI) is a method that allows developers to integrate their development code into a shared code repository multiple times. Using a continuous integration strategy helps developers detect problems in their code and discover errors as early as possible.

[0081] Continuous Delivery (CD) builds upon Continuous Integration by deploying integrated code to a pre-release environment, preparing it for deployment to the production environment (also known as the release environment). The production environment is the system environment used in production, i.e., the online environment and the environment used by users. The pre-release environment serves as a transition between the testing and production environments, periodically synchronizing with the production environment to maintain consistency in settings and data. The final decision to deploy to the production environment is reviewed by the quality team or users. If the review is approved, the code will be deployed to the actual production environment.

[0082] A pipeline service is an automated task scheduling platform that needs to be used in conjunction with automated tasks such as building, code inspection, testing, and deployment during the software development and delivery process. Typically, pipelines can be configured according to the specific use case, such as configuring a continuous deployment pipeline. Once the pipeline is configured, it can be automatically triggered and executed with a single click.

[0083] Considering availability and disaster recovery capabilities, an increasing number of cloud services and applications are adopting multi-site deployment strategies. At each site, multiple service nodes may be deployed to meet the business traffic needs of different services or applications. A site is the smallest deployment unit, such as a single machine, a data center, or a region. Multi-site deployment, by distributing data centers across multiple geographical locations, ensures that the system can automatically switch to other sites in the event of a failure at one site, thereby avoiding the impact of single-point failures and ensuring business continuity.

[0084] In mainstream CI / CD deployment platforms, for multi-site deployments, users typically need to pre-plan and orchestrate the deployment order and strategies for each site within a predefined pipeline, and then execute the deployment tasks sequentially. For example, to achieve batch deployment of different sites, related technologies provide methods for sequential deployment based on different stages. Users can configure different sites under multiple stages, and the runtime pipeline will deploy them sequentially. Specific pipeline configurations are as follows... Figure 1 As shown, on the pipeline configuration page, users can see the tasks at each stage of the pipeline, and there are "Add" buttons on the connecting lines between the stages. Users can add other deployment tasks or other pipeline tasks (such as build tasks, inspection tasks, and checkpoint tasks) between pipelines for pre-release checkpoint review or verification checks.

[0085] The setup of the pipeline stages is as follows: Figure 2 As shown, after a user selects a deployment phase, the existing deployment tasks for that phase are displayed sequentially below it. Users can also add deployment tasks to that phase. When configuring deployment tasks, users can edit the execution parameters required by the task, such as task type, task name, and task parameters, and set the deployment strategy.

[0086] After configuring all pipeline stages, users can view the statically deployed pipeline on the interface. For example... Figure 3 As shown, this pipeline includes a predefined deployment order and deployment strategy. When the pipeline is run, the pipeline engine will execute the pipeline sequentially according to the above configuration information.

[0087] The above solutions require users to consider the deployment needs, dependencies, and priorities of different deployment sites during the pipeline design phase. This typically necessitates manually adjusting the deployment order across multiple deployment sites and confirming relevant configurations at each pipeline stage. Once the pipeline starts, the execution steps are fixed and cannot be dynamically adjusted during operation. For example, when some deployment sites become unavailable or users wish to skip the deployment of specific deployment sites, the pipeline often gets blocked and cannot continue. In other words, the static pipeline solution does not support dynamically skipping specific deployment sites during pipeline operation, causing the entire deployment process to stall, wasting time and resources. Users also cannot flexibly choose appropriate deployment strategies (such as rolling deployment, canary releases, etc.) based on different deployment scenarios, and can only rely on pre-set fixed strategies, increasing the risk during deployment, especially in scenarios requiring rapid response to issues or adjustments to deployment plans based on environmental changes. The inability to flexibly control the deployment order of deployment sites, batch deploy all deployment sites, or skip specific steps when encountering problematic deployment sites results in a lack of flexibility for different deployment scenarios, making it difficult to meet business needs. When faced with new or special deployment scenarios, users often need to modify existing pipelines or create a new dedicated pipeline to adapt to the changes, which increases the complexity of maintenance and configuration.

[0088] In view of this, this application provides a site deployment control method. This method can be applied to a deployment platform, such as a CI / CD deployment platform. The deployment platform may include a pipeline execution engine for executing pipelines, thereby achieving multi-site deployment. The deployment platform may include a software system, which can be standalone software or integrated into other software as a plugin, component, functional module, service, etc. In some examples, the deployment platform may also include a hardware system; for example, the deployment platform may include a cluster of computing devices with site deployment control capabilities. When the computing device cluster is running, it executes the site deployment control method of this application.

[0089] In practice, the deployment platform can receive pipeline execution requests. These requests include an identifier for the target pipeline to be executed. The target pipeline includes at least one commit / release stage and at least one deployment stage. During the execution of the target pipeline, when execution reaches the first commit / release stage, the deployment platform can provide a decision interface to the user. This interface displays at least one of the deployable sites or nodes in the first deployment stage corresponding to the first commit / release stage. The deployment platform can receive the first site and / or first node selected by the user through the decision interface. The first site can be one or more deployable sites, and the first node can be one or more deployable nodes. Accordingly, the deployment platform can deploy the first site and / or first node.

[0090] In this method, users can dynamically generate pipeline stages and tasks that meet actual business needs based on different deployment scenarios and site requirements. Specifically, this method introduces a special pipeline stage, the "Submit Deployment" stage, which includes a special "Submit Deployment" checkpoint task that precedes the deployment stage. During pipeline execution, the deployment order can be adjusted based on the actual business scenario through these tasks. Specifically, different sites and nodes can be deployed according to the order selected by the user, and unavailable sites can be skipped, thereby improving deployment flexibility and fault tolerance. Furthermore, for new or special deployment scenarios, this method does not require modifying existing pipelines or creating a new dedicated pipeline. Instead, through automated pipeline management, it efficiently executes deployment tasks across multiple sites and scenarios, ensuring the compliance, reliability, and efficiency of the deployment process while reducing pipeline maintenance costs and deployment risks.

[0091] To make the technical solution of this application clearer and easier to understand, the system architecture of the deployment platform is described below.

[0092] See Figure 4 The diagram shows the architecture of a deployment platform 400, which includes an interaction module 402 and an execution module 404. The functions of each module are described in detail below.

[0093] The interaction module 402 is used to receive pipeline execution requests. The pipeline execution request includes the identifier (ID) of the target pipeline to be executed. The identifier of the target pipeline is used to uniquely identify the target pipeline. In some examples, the identifier of the target pipeline may include the name or code of the target pipeline. The target pipeline includes at least one commit / release stage and at least one deployment stage. Each commit / release stage may correspond to one deployment stage.

[0094] The interaction module 402 is also used to provide a decision interface to the user during the execution of the target pipeline, when the execution reaches the first submission and release stage of at least one submission and release stage, and to receive the first deployment site and / or first node selected by the user through the decision interface. The decision interface is used to display at least one of the deployable sites or deployable nodes in the first deployment stage corresponding to the first submission and release stage. A deployable node refers to a service node that can be deployed in a site. The first site is one or more of the deployable sites, and the first node is one or more of the deployable nodes.

[0095] Execution module 404 is used to deploy the first site and / or the first node. Specifically, execution module 404 generates dynamic deployment stages and deployment tasks corresponding to the first site and / or the first node, inserts these stages and tasks into the target pipeline, and executes the deployment tasks to deploy the first site and / or the first node. When the execution reaches the dynamic deployment stage, the aforementioned deployment tasks are executed. It should be noted that when deploying the first site and / or the first node, execution module 404 can deploy the first site and / or the first node according to a configured deployment strategy. These deployment strategies include rolling deployment, blue-green deployment, canary release, or a custom deployment strategy.

[0096] The following examples illustrate different deployment strategies.

[0097] Rolling deployment is a strategy that gradually replaces running application instances, rather than updating them all at once. For example, if a web application has 10 instances, rolling deployment updates only 1-2 instances at a time. Once these instances are updated and running stably, the next batch is updated, and so on, until all instances are updated. Rolling deployment does not interrupt service during the update process, minimizing the impact on users, who are virtually unaware of the changes.

[0098] Blue-green deployment involves maintaining two identical production environments: a "blue" environment and a "green" environment. Typically, one environment provides services while the other is idle or running an older version. When deploying a new application, it is first deployed and tested in the green environment. Once confirmed to be working correctly, traffic is switched from the blue environment to the green environment. At this point, the green environment becomes the production environment, while the blue environment can be used for subsequent deployments or as a backup. Blue-green deployment allows for rapid switching. If the new environment tests successfully, traffic can be quickly switched to enable rapid deployment of new features. If problems occur in the new environment, traffic can be quickly switched back to the old environment to restore normal service.

[0099] Canary release, also known as phased rollout, is a deployment strategy where new features or updates are gradually rolled out to a small group of users to gather feedback. Once feedback is confirmed to be positive, the rollout is gradually expanded until all users are using the new feature or update. For example, a new feature might be released to 1% of users initially, observed for a period, and then the rollout percentage increased based on user feedback and system performance. Canary releases allow for testing in real-world user environments, enabling the timely identification of potential problems and minimizing the impact on a large number of users.

[0100] A custom deployment strategy is a deployment strategy that allows users to customize the number of deployment batches or the number of nodes deployed per batch. For example, a custom deployment strategy could include deploying in n batches, with m nodes deployed in each batch. Custom deployment strategies can meet personalized business needs and offer high flexibility.

[0101] The above provides an example of a deployment within a deployment phase. The interaction module 402 is also used to provide a decision interface to the user when the first deployment phase includes undeployed sites, undeployed nodes, or unskipped sites or nodes, receiving the second site and / or second node selected by the user through the decision interface. Similar to the first site and first node, the second site is one or more deployable sites, and the second node is one or more deployable nodes. Correspondingly, the execution module 404 is also used to deploy the second site and / or second node. The deployment process of the second site and second node can refer to the deployment process of the first site and first node, and will not be repeated here.

[0102] This application also supports skipping specified sites or nodes. For example, if a site or node is unavailable, the user can choose to skip that site or stage. Detailed explanation follows.

[0103] The interaction module 402 is further configured to provide the user with the decision interface when the first deployment phase includes undeployed sites, undeployed nodes, or unskipped sites or nodes, and to receive the third site and / or third node selected by the user through the decision interface. Here, the third site is one or more of the deployable sites, and the third node is one or more of the deployable nodes. Correspondingly, the execution module 404 may choose not to deploy the third site and / or third node. This achieves skipping the third site or third node.

[0104] based on Figure 4 The deployment platform 400 shown in this application also provides a local deployment control method. The local deployment control method of this application will be described in detail below with reference to the accompanying drawings.

[0105] See Figure 5A The flowchart shown illustrates a local deployment control method applied to deployment platform 400, which specifically includes the following steps:

[0106] S502, Deployment platform 400 receives pipeline execution request. During the execution of the target pipeline, when execution reaches the first commit / release stage of at least one commit / release stage, S504 is executed.

[0107] The pipeline execution request includes the identifier of the target pipeline to be executed, used to request the execution of the target pipeline. The identifier of the target pipeline can be the name or code of the target pipeline. The target pipeline includes at least one commit / release stage and at least one deployment stage. Each commit / release stage corresponds to a deployment stage, used to dynamically adjust the nodes and points within the deployment stage corresponding to that commit / release stage, such as adjusting the deployment order, deployment strategy, and deciding whether to skip nodes or points.

[0108] In practice, after the target pipeline is configured, the user can click the "Run" control to trigger the execution of the target pipeline. Correspondingly, the deployment platform 400 can receive the pipeline execution request. The deployment platform 400 executes the target pipeline based on the identifier of the target pipeline in the execution request. The target pipeline includes multiple pipeline stages, and the deployment platform 400 can execute the pipeline tasks in each stage sequentially according to their orchestration order. When execution reaches the submission / release stage, for example, the first submission / release stage, step S504 is executed.

[0109] S504 and Deployment Platform 400 provide a decision interface to the user, which is used to display at least one of the deployable sites or deployable nodes in the first deployment phase corresponding to the first submission and release phase.

[0110] On the decision-making interface, users can view deployable sites and nodes. For deployable nodes, users can also view available deployment strategies (or release strategies). These strategies can include rolling deployment, blue-green deployment, canary deployment, or custom deployment strategies. This allows users to choose to execute or skip specific sites or nodes based on their actual needs.

[0111] To facilitate understanding, an example will be used as an illustration below.

[0112] like Figure 5B As shown, the target pipeline may include the following pipeline stages: Build, Release 1, Deployment Stage 1, Release 2, and Deployment Stage 2. Release 1 corresponds to Deployment Stage 1, and Release 2 corresponds to Deployment Stage 2. When the deployment platform 400 executes the target pipeline up to Release 1, it can provide a decision-making interface to the user. Figure 6A schematic diagram of the decision interface for submitting and releasing in Phase 1 is shown. This decision interface 600 displays deployable sites 602 and deployable nodes 604. Deployable sites 602 include Site 1 and Site 2. For Site 1, deployable nodes 604 include Node 1 and Node 2, denoted as Site 1 Node 1 and Site 1 Node 2. For Site 2, deployable nodes 604 include Node 1 and Node 2, denoted as Site 2 Node 1 and Site 2 Node 2. For deployable nodes 604, the decision interface 600 can also provide a node configuration component 606, which includes a strategy configuration control 6062, a release method configuration control 6064, a release pause method configuration control 6066, and a release batch configuration control 6068. The strategy configuration control 6062 can display selectable deployment strategies, allowing users to select the deployment strategy to apply when deploying nodes through this decision interface. Users can select any site or node for deployment (release) or skip it on the decision interface 600. For example, after selecting a location or node, a user can trigger "Publish Control 608" to initiate a deployment or publication operation. Alternatively, after selecting a location or node, a user can trigger "Skip Control 609" to skip that location or node.

[0113] S506, Deployment platform 400 receives the first deployment site and / or first node selected by the user through the decision interface.

[0114] The first deployment point is one or more deployment points among the deployable deployment points, and the first node is one or more deployable nodes among the deployable nodes. Figure 6 As an example, a user can select site one node one and then trigger "publish control 608". In this way, the deployment platform 400 can receive the first site and / or the first node to be deployed selected by the user through the decision interface, specifically site one node one.

[0115] S508, Deployment Platform 400 deploys the first site and / or the first node. If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, execute S510.

[0116] Specifically, deployment platform 400 can generate dynamic deployment phases and deployment tasks corresponding to the first site and / or the first node. Then, deployment platform 400 inserts the dynamic deployment phases and deployment tasks into the target pipeline; the deployment tasks are used to deploy the first site and / or the first node. When execution reaches the dynamic deployment phase, deployment platform 400 can execute the deployment tasks.

[0117] During deployment, the deployment platform 400 can execute the aforementioned deployment tasks in conjunction with the user-selected deployment strategy. Specifically, the deployment platform 400 can deploy the first site and / or the first node according to the configured deployment strategy. The deployment strategy can include rolling deployment, blue-green deployment, canary release, or a custom deployment strategy.

[0118] like Figure 7 As shown, if a user selects site one for deployment, the deployment platform 400 automatically generates deployment tasks for corresponding nodes one and two at that site, adapting them to the user's chosen deployment strategy. Specifically, the deployment platform 400 can dynamically generate corresponding deployment stages and tasks based on requirements, and insert these stages and tasks into the currently running target pipeline. When generating deployment tasks, the deployment platform 400 also verifies the compliance of the corresponding site's publication, such as whether the publisher has the authority to publish, whether the site is healthy, or whether it is within the site's permitted publication time.

[0119] Furthermore, the deployment platform 400 can also generate new commit / release phases and commit / release tasks. After deployment, the pipeline will pause in the newly generated commit / release phase to allow for subsequent selection of other deployment sites and execution of inserted tasks and phases, such as... Figure 8 As shown.

[0120] It should be noted that, to avoid user confusion regarding dynamically generated stages, the deployment platform 400 can handle dynamic stages in a special way. Specifically, in the user-visible pipeline user interface (UI), the deployment operation is only displayed for "Deployment Stage One," and the hidden dynamic stages will not be displayed on the page to prevent user misunderstanding.

[0121] Once the first site and the first node are deployed, the deployment platform 400 can detect whether the first deployment phase includes undeployed sites, undeployed nodes, or unskipped sites and nodes. If so, it means that the first deployment phase has not been completed, and the deployment platform 400 can execute S510.

[0122] S510 and deployment platform 400 provide a decision-making interface to the user. Then, S512 and S514 are executed, or S516 and S518 are executed.

[0123] Specifically, users can continue to select a site or node for deployment or skip it on the decision interface. When the user selects a site or node for deployment, S516 is executed; when the user selects a site or node to skip, S516 and S518 are executed.

[0124] S512, Deployment Platform 400 receives the second site and / or second node to be deployed selected by the user through the decision interface.

[0125] S514, Deployment Platform 400 deploys the second site and / or the second node.

[0126] The second site is one or more of the deployable sites. The second node is one or more of the deployable nodes.

[0127] For ease of understanding, Figure 9 Example Explanation. When the target pipeline reaches the "Submit and Release" stage, the user selects to deploy site one, and site one is deployed. Subsequently, the target pipeline returns to the Submit and Release stage, where the user can continue to select deployable sites and nodes on the UI. If the user selects to deploy node one under site one, and node one is deployed, the pipeline will return to the Submit and Release stage again because there are still undeployed or skipped sites in the current stage, allowing the user to make selections.

[0128] S516, Deployment Platform 400 receives the third point and / or third node to be skipped selected by the user through the decision interface.

[0129] S518, Deployment Platform 400 does not deploy a third site and / or a third node.

[0130] The third site is one or more of the deployable sites, and the third node is one or more of the deployable nodes.

[0131] by Figure 9 Example Explanation. The deployment platform 400 continuously receives user-selected sites and nodes to be deployed and deploys the corresponding sites and nodes. When site two and node one are deployed successfully, the target pipeline returns to the submission and release phase. The deployment platform 400 provides a decision interface to the user. If the user chooses to skip site two and node two, the deployment platform 400 can choose not to execute the deployment task for site two and node two. All tasks in this pipeline phase have been processed. The deployment platform 400 can then continue to execute subsequent phases. Figure 10 This demonstrates the stages and tasks executed in a real pipeline after the dynamically generated task stages. Each time a deployment is submitted, the deployment platform 400 can dynamically generate the corresponding stages and tasks based on the user's selected location and strategy to meet the user's deployment needs.

[0132] It should be noted that S510 to S514 or S510, S516, S518 are optional steps in the embodiments of this application. The local deployment control method of this application may also omit S510 to S518.

[0133] Based on the above description, this application provides a site deployment control method. This method introduces a "checkpoint mechanism." During pipeline operation, when a checkpoint task (such as a submission / release task) in the "submission / release phase" is reached, pipeline operators can choose to execute the deployment task multiple times. During each deployment, the user selects the site to be deployed and the application's deployment strategy (such as rolling deployment, canary release, etc.) based on current needs. After each deployment is completed, if there are still undeployed or skipped sites in that phase, the pipeline will return to the submission / release phase, allowing the user to select the next deployment site and deployment strategy, until all deployment tasks in that phase are completed or skipped. This method allows users to dynamically select deployment sites or nodes. After the site or node deployment is completed, the user can return to the checkpoint to select again. This allows for dynamic adjustment of pipeline phases based on actual business scenarios during pipeline operation. Users can flexibly decide on the deployment strategy and order of sites or nodes in the pipeline phase, increasing pipeline flexibility, reducing pipeline maintenance costs in diverse business scenarios, and improving deployment efficiency.

[0134] Figure 4 The illustrated embodiment provides an overall overview of the target pipeline execution process. The task generation and execution process in the target pipeline execution process are described below with reference to the accompanying drawings.

[0135] See Figure 11 The diagram illustrates a process for generating and executing deployment tasks, which includes the following steps:

[0136] (1) The deployment platform 400 registers the environment based on the site, environment tags, and resources corresponding to the environment selected by the user. Once registration is complete, the deployment platform 400 adds the deployment strategy for the environment application.

[0137] The environment label indicates whether the environment is a development environment, a testing environment, a pre-release environment, or a production environment. It should be noted that step (1) is a preprocessing step and can be performed before the pipeline is executed.

[0138] (2): When the deployment platform 400 is executing the pipeline to the submission and release stage, it provides the user with a decision interface so that the user can select the deployment site and deployment strategy according to the needs.

[0139] (3): Deployment platform 400 performs compliance verification on deployment tasks.

[0140] Specifically, the deployment platform 400 can verify whether the submitter has the authority to deploy to the selected site, check whether the deployment site is within a valid release time window, and whether the site status is healthy. If the verification fails, the release cannot proceed.

[0141] (4): The deployment platform 400 automatically adapts to the corresponding deployment scheme according to the deployment strategy selected by the user.

[0142] (5): The deployment platform 400 dynamically generates corresponding deployment tasks and deployment stages based on the user's selection.

[0143] It should be noted that users can also choose to skip tasks at certain locations, and the deployment platform 400 will automatically skip the corresponding location deployments.

[0144] (6): Deployment platform 400 determines whether all tasks in the original deployment phase have been completed or skipped. If there are unfinished site deployments, deployment platform 400 can return to step (2) to continue execution. After all tasks are completed, deployment platform 400 will continue to execute the subsequent phases.

[0145] Figure 4 The illustrated embodiment mainly describes the execution process of the target pipeline. The configuration process of the target pipeline will be described in detail below.

[0146] See Figure 12 The diagram shows a flow chart of a pipeline configuration. The method includes the following steps:

[0147] S1202 and Deployment Platform 400 provide a pipeline configuration page.

[0148] The pipeline configuration interface is used to configure pipelines. Specifically, during the pipeline configuration phase of Development & Operations (DevOps), the deployment platform 400 can provide a pipeline configuration page. Users can configure the deployment stages of the DevOps pipeline and add submission and release tasks based on the pipeline configuration page, so as to flexibly adjust the deployment tasks of each deployment stage according to actual needs.

[0149] DevOps is a culture, movement, and practice that emphasizes communication and collaboration between software developers (Dev) and IT operations professionals (Ops). It automates the processes of software delivery and architecture change to make building, testing, and releasing software faster, more frequent, and more reliable.

[0150] S1204, Deployment platform 400 receives the metadata of the target pipeline configured through the pipeline configuration page.

[0151] Meta-information includes metadata from at least one submission / release phase and metadata from at least one deployment phase. Specifically, metadata from the submission / release phase may include task information or attributes of the submission / release task within that phase. Meta-information from the deployment phase may include task information or attributes of the deployment task within that phase.

[0152] Specifically, on the pipeline configuration page, users can add multiple deployment stages, and each stage can configure multiple deployment sites and their corresponding node tasks. In addition, users can add a "Submit Release Stage" (or Submit Release Task) before the deployment stage, so that the execution of tasks can be dynamically adjusted according to the actual deployment scenario and business needs during pipeline operation.

[0153] When defining a pipeline, users can edit deployment stages, add deployment sites and deployment tasks under those sites. Sites can be configured through pipeline task groups. Within a task group, users can set the group name and the execution method of the tasks (e.g., serial or parallel). Multiple task groups can be configured for each pipeline stage. See also Figure 13 The diagram illustrates a task group configuration interface. For site one, the user can configure task deployment nodes and task execution order (e.g., serial or parallel) through the task group configuration interface. Correspondingly, the deployment platform 400 receives task group information configured through the pipeline page for at least one deployment stage. The task group information includes at least one of the following: task deployment site, task deployment node, and task execution order.

[0154] After configuring the task group, users can then configure corresponding deployment tasks for that task group. The deployment task attributes include the task type, task name, deployment environment, and deployment strategy. Multiple pipeline tasks can be configured within each task group. See also... Figure 14 The diagram illustrates a deployment task configuration interface. Users can configure task information for a node at a specific location (node ​​1). This task information includes at least one of the following: task type, task name, environment, or deployment strategy. In this example, the task type can be a deployment task, the task name can be "location 1, node 1," the environment can be "node 1," and the deployment strategy can be rolling deployment. Correspondingly, the deployment platform 400 receives task information for at least one deployment task from the task group configured via the pipeline page.

[0155] After the deployment phase configuration is complete, users can configure and submit the release task before the deployment phase. When the pipeline reaches the release submission stage, users can select the deployment sites and corresponding deployment strategies. See also Figure 15 The diagram illustrates a submission and release task configuration interface, through which users can configure task information for at least one submission and release stage. Correspondingly, the deployment platform 400 receives the task information for at least one submission and release stage configured via the pipeline page. This task information may include at least one of the following: task type, task name, and checkpoint validity period. The checkpoint validity period controls the execution and termination of the pipeline. If the release is not completed before the checkpoint validity period, the pipeline automatically terminates.

[0156] S1206, Deployment platform 400 generates the target pipeline based on the metadata of the target pipeline.

[0157] Based on the above description, this application provides a dynamic multi-site deployment pipeline applicable to the configuration and operation phases of DevOps pipelines. During the pipeline configuration phase, configuration personnel can set a decision-making stage where pipeline operators can dynamically adjust the deployment order and strategy of each site based on real-time operational status. Through this mechanism, users can flexibly select deployment strategies for each site, such as rolling deployments or canary deployments, and flexibly skip or retry the deployment of certain sites as needed.

[0158] Based on the aforementioned site deployment control method, this application also provides a deployment platform 400. The deployment platform 400 provided in this application will be described below from the perspective of functional modularity.

[0159] See Figure 4 The diagram shows a structural schematic of a deployment platform 400, which includes:

[0160] Interaction module 402 is used to receive pipeline execution requests, the pipeline execution requests including the identifier of the target pipeline to be executed, the target pipeline including at least one submission and release stage and at least one deployment stage;

[0161] The interaction module 402 is further configured to provide a decision interface to the user when the execution of the target pipeline reaches the first submission and release stage in the at least one submission and release stage during the execution of the target pipeline. The decision interface is configured to display at least one of the deployable sites or deployable nodes in the first deployment stage corresponding to the first submission and release stage.

[0162] The interaction module 402 is further configured to receive the first deployment site and / or the first node selected by the user through the decision interface, wherein the first deployment site is one or more deployment sites among the deployable sites, and the first node is one or more nodes among the deployable nodes;

[0163] Execution module 404 is used to deploy the first site and / or the first node.

[0164] For example, the interaction module 402 and the execution module 404 described above can be implemented in hardware or in software.

[0165] When implemented in software, the interaction module 402 and execution module 404 can be applications running on computing devices, such as computing engines. These applications can also be virtualized and provided to users as virtualization services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, or container services. Specifically, a VM service can be a service that uses virtualization technology to create a pool of virtual machine (VM) resources on multiple physical hosts, providing VMs to users on demand. A BMS service is a service that uses virtualization technology to create a pool of BMS resources on multiple physical hosts, providing BMS services to users on demand. A container service is a service that uses virtualization technology to create a pool of container resources on multiple physical hosts, providing containers to users on demand. A VM is a simulated virtual computer, that is, a logical computer. A BMS is a scalable, high-performance computing service with computing performance indistinguishable from traditional physical machines, featuring secure physical isolation. A container is a kernel virtualization technology that provides lightweight virtualization to isolate user space, processes, and resources. It should be understood that the VM service, BMS service, and container service mentioned above are merely specific examples. In practical applications, virtualization services can also include other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0166] When implemented in hardware, the interaction module 402 and execution module 404 may include at least one computing device, such as a server. Alternatively, the interaction module 402 and execution module 404 may also be devices implemented using application-specific integrated circuits (ASICs) or programmable logic devices (PLDs). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0167] In some possible implementations, the interaction module 402 is further configured to:

[0168] If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user.

[0169] Receive the second site and / or second node selected by the user through the decision interface, wherein the second site is one or more sites among the deployable sites, and the second node is one or more nodes among the deployable nodes;

[0170] The execution module 404 is further configured to:

[0171] Deploy the second site and / or the second node.

[0172] In some possible implementations, the interaction module 402 is further configured to:

[0173] If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user.

[0174] The system receives the third location and / or third node selected by the user through the decision interface, wherein the third location is one or more of the deployable locations and the third node is one or more of the deployable nodes.

[0175] The execution module 404 is further configured to:

[0176] The third location and / or the third node shall not be deployed.

[0177] In some possible implementations, the execution module 404 is specifically used for:

[0178] Generate dynamic deployment phases and deployment tasks corresponding to the first site and / or the first node;

[0179] The dynamic deployment phase and the deployment task are inserted into the target pipeline, and the deployment task is used to deploy the first site and / or the first node.

[0180] When the process reaches the dynamic deployment phase, the deployment task is executed.

[0181] In some possible implementations, the execution module 404 is specifically used for:

[0182] According to the configured deployment strategy, the first site and / or the first node are deployed, and the deployment strategy includes rolling deployment, blue-green deployment, canary release or custom deployment strategy.

[0183] In some possible implementations, the interaction module 402 is further configured to:

[0184] Before receiving the pipeline execution request, a pipeline configuration page is provided;

[0185] Receive metadata of the target pipeline configured through the pipeline configuration page, the metadata including metadata of the at least one submission and release stage and metadata of the at least one deployment stage;

[0186] The platform 400 also includes:

[0187] Generate module ( Figure 4 (Not shown in the image), used to generate the target pipeline based on the metadata of the target pipeline.

[0188] Similar to execution module 404, the above generation module can be implemented in hardware or in software.

[0189] When implemented in software, the generation module can be an application running on a computing device, such as a computing engine. This application can also be virtualized and provided to users as a virtualization service such as a BMS, VM, or container. When implemented in hardware, the generation module can include at least one computing device, such as a server. Alternatively, the generation module can also be a device implemented using an ASIC or a PLD.

[0190] In some possible implementations, the interaction module 402 is specifically used for:

[0191] The system receives task group information for at least one deployment stage configured through the pipeline page, and task information for at least one deployment task in the task group. The task group information includes at least one of the following: task deployment location, task deployment node, and task execution order. The task information includes at least one of the following: task type, task name, environment, and deployment strategy.

[0192] In some possible implementations, the interaction module 402 is specifically used for:

[0193] Receive task information for the submission and release task in the at least one submission and release stage configured through the pipeline page, wherein the task information includes at least one of the following: task type, task name, and checkpoint validity period.

[0194] This application also provides a computing device 1600. For example... Figure 16 As shown, the computing device 1600 includes a bus 1602, a processor 1604, a memory 1606, and a communication interface 1608. The processor 1604, the memory 1606, and the communication interface 1608 communicate with each other via the bus 1602. The computing device 1600 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 1600.

[0195] The 1602 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 16 The bus 1602 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1602 may include a path for transmitting information between various components of the computing device 1600 (e.g., memory 1606, processor 1604, communication interface 1608).

[0196] Processor 1604 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0197] Memory 1606 may include volatile memory, such as random access memory (RAM). Memory 1606 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD). Memory 1606 stores executable program code, which processor 1604 executes to implement the aforementioned site deployment control method. Specifically, memory 1606 stores instructions for deployment platform 400 to execute the site deployment control method. For example, memory 1606 may store instructions for implementing the functions of interaction module 402 and execution module 404. Furthermore, memory 1606 may also store instructions for implementing the functions of generation module.

[0198] The communication interface 1608 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 1600 and other devices or communication networks.

[0199] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0200] like Figure 17 As shown, the computing device cluster includes at least one computing device 1600. The memory 1606 of one or more computing devices 1600 in the computing device cluster may store instructions from the same deployment platform 400 for executing local deployment control methods.

[0201] In some possible implementations, one or more computing devices 1600 in the computing device cluster can also be used to execute some of the instructions used by the deployment platform 400 to execute the local deployment control method. In other words, a combination of one or more computing devices 1600 can jointly execute the instructions used by the deployment platform 400 to execute the local deployment control method.

[0202] It should be noted that the memory 1606 in different computing devices 1600 in the computing device cluster can store different instructions for executing some functions of the deployment platform 400.

[0203] Figure 18 One possible implementation is shown. For example... Figure 18 As shown, two computing devices 1600A and 1600B are connected via a communication interface 1608. The memory in computing device 1600A stores instructions for executing the functions of the interaction module 402. The memory in computing device 1600B stores instructions for executing the functions of the execution module 404. Furthermore, the memory of computing device 1600A may also store instructions for executing the functions of the generation module. In other words, the memory 1606 of computing devices 1600A and 1600B jointly stores instructions for the deployment platform 400 to execute the deployment control method.

[0204] Figure 18 The connection method between the computing device clusters shown can be considered because the local deployment control method provided in this application requires a lot of resources for local deployment and node deployment. Therefore, it is considered that the functions implemented by the interaction module 402 and the execution module 404 are executed by different computing devices. For example, the functions implemented by the interaction module 402 can be executed by computing device 1600A, and the functions implemented by the execution module 404 can be executed by computing device 1600B. Furthermore, when the deployment platform 400 also includes a generation module, the functions implemented by the generation module are executed by computing device 1600A.

[0205] It should be understood that Figure 18 The functions of computing device 1600A shown can also be performed by multiple computing devices 1600. Similarly, the functions of computing device 1600B can also be performed by multiple computing devices 1600.

[0206] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 19 One possible implementation is shown. For example... Figure 19 As shown, the two computing devices 1600C and 1600D are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 1606 in computing device 1600C stores instructions for executing the functions of the interaction module 402. Simultaneously, the memory 1606 in computing device 1600D stores instructions for executing the functions of the execution module 404. Furthermore, the memory of computing device 1600C may also store instructions for executing the functions of the generation module.

[0207] Figure 19 The connection method between the computing device clusters shown can be considered because the local deployment control method provided in this application requires a large amount of resources for local deployment and node deployment. Therefore, the functions implemented by the execution module 404 can be performed by separate computing devices. For example, the functions implemented by the interaction module 402 can be performed by computing device 1600C, and the functions implemented by the execution module 404 can be performed by computing device 1600D. In addition, when the deployment platform 400 also includes a generation module, the functions implemented by the generation module can be performed by computing device 1600C.

[0208] It should be understood that Figure 19 The functions of the computing device 1600C shown can also be performed by multiple computing devices 1600. Similarly, the functions of the computing device 1600D can also be performed by multiple computing devices 1600.

[0209] This application embodiment also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the aforementioned site deployment control method applied to the deployment platform 400.

[0210] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product runs on at least one computing device, it causes the at least one computing device to perform the aforementioned site deployment control method.

[0211] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A local deployment control method, characterized in that, Applied to a deployment platform, the method includes: Receive a pipeline execution request, the pipeline execution request including an identifier of a target pipeline to be executed, the target pipeline including at least one submission and release phase and at least one deployment phase; During the execution of the target pipeline, when the execution reaches the first submission and release stage of the at least one submission and release stage, a decision interface is provided to the user. The decision interface is used to display at least one of the deployable sites or deployable nodes in the first deployment stage corresponding to the first submission and release stage. Receive the first deployment site and / or first node selected by the user through the decision interface, wherein the first deployment site is one or more deployment sites and the first node is one or more deployment nodes. Deploy the first site and / or the first node.

2. The method according to claim 1, characterized in that, The method further includes: If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user. Receive the second site and / or second node selected by the user through the decision interface, wherein the second site is one or more sites among the deployable sites, and the second node is one or more nodes among the deployable nodes; Deploy the second site and / or the second node.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user. The system receives the third location and / or third node selected by the user through the decision interface, wherein the third location is one or more of the deployable locations and the third node is one or more of the deployable nodes. The third location and / or the third node shall not be deployed.

4. The method according to any one of claims 1 to 3, characterized in that, The deployment of the first site and / or the first node includes: Generate dynamic deployment phases and deployment tasks corresponding to the first site and / or the first node; The dynamic deployment phase and the deployment task are inserted into the target pipeline, and the deployment task is used to deploy the first site and / or the first node. When the process reaches the dynamic deployment phase, the deployment task is executed.

5. The method according to any one of claims 1 to 3, characterized in that, The deployment of the first site and / or the first node includes: According to the configured deployment strategy, the first site and / or the first node are deployed, and the deployment strategy includes rolling deployment, blue-green deployment, canary release or custom deployment strategy.

6. The method according to any one of claims 1 to 5, characterized in that, Before receiving the pipeline execution request, the method further includes: Provides a pipeline configuration page; Receive metadata of the target pipeline configured through the pipeline configuration page, the metadata including metadata of the at least one submission and release stage and metadata of the at least one deployment stage; The target pipeline is generated based on the metadata of the target pipeline.

7. The method according to claim 6, characterized in that, The step of receiving the metadata of the target pipeline configured through the pipeline configuration page includes: The system receives task group information for at least one deployment stage configured through the pipeline page, and task information for at least one deployment task in the task group. The task group information includes at least one of the following: task deployment location, task deployment node, and task execution order. The task information includes at least one of the following: task type, task name, environment, and deployment strategy.

8. The method according to claim 6 or 7, characterized in that, The step of receiving the metadata of the target pipeline configured through the pipeline configuration page includes: Receive task information for the submission and release task in the at least one submission and release stage configured through the pipeline page, wherein the task information includes at least one of the following: task type, task name, and checkpoint validity period.

9. A deployment platform, characterized in that, The deployment platform includes: An interaction module is used to receive pipeline execution requests, wherein the pipeline execution request includes an identifier of a target pipeline to be executed, and the target pipeline includes at least one submission and release phase and at least one deployment phase; The interaction module is also used to provide a decision interface to the user when the execution of the target pipeline reaches the first submission and release stage in the at least one submission and release stage during the execution of the target pipeline. The decision interface is used to display at least one of the deployable sites or deployable nodes in the first deployment stage corresponding to the first submission and release stage. The interaction module is further configured to receive the first deployment site and / or the first node selected by the user through the decision interface, wherein the first deployment site is one or more deployment sites among the deployable sites, and the first node is one or more nodes among the deployable nodes; An execution module is used to deploy the first site and / or the first node.

10. The deployment platform according to claim 9, characterized in that, The interaction module is also used for: If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user. Receive the second site and / or second node selected by the user through the decision interface, wherein the second site is one or more sites among the deployable sites, and the second node is one or more nodes among the deployable nodes; The execution module is also used for: Deploy the second site and / or the second node.

11. The platform according to claim 9 or 10, characterized in that, The interaction module is also used for: If the first deployment phase also includes undeployed sites, undeployed nodes, or unskipped sites or nodes, the decision interface is provided to the user. The system receives the third location and / or third node selected by the user through the decision interface, wherein the third location is one or more of the deployable locations and the third node is one or more of the deployable nodes. The execution module is also used for: The third location and / or the third node shall not be deployed.

12. The platform according to any one of claims 9 to 11, characterized in that, The execution module is specifically used for: Generate dynamic deployment phases and deployment tasks corresponding to the first site and / or the first node; The dynamic deployment phase and the deployment task are inserted into the target pipeline, and the deployment task is used to deploy the first site and / or the first node. When the process reaches the dynamic deployment phase, the deployment task is executed.

13. The platform according to any one of claims 9 to 12, characterized in that, The execution module is specifically used for: According to the configured deployment strategy, the first site and / or the first node are deployed, and the deployment strategy includes rolling deployment, blue-green deployment, canary release or custom deployment strategy.

14. The platform according to any one of claims 9 to 13, characterized in that, The interaction module is also used for: Before receiving the pipeline execution request, a pipeline configuration page is provided; Receive metadata of the target pipeline configured through the pipeline configuration page, the metadata including metadata of the at least one submission and release stage and metadata of the at least one deployment stage; The platform also includes: The generation module is used to generate the target pipeline based on the metadata of the target pipeline.

15. The platform according to claim 14, characterized in that, The interaction module is specifically used for: The system receives task group information for at least one deployment stage configured through the pipeline page, and task information for at least one deployment task in the task group. The task group information includes at least one of the following: task deployment location, task deployment node, and task execution order. The task information includes at least one of the following: task type, task name, environment, and deployment strategy.

16. The platform according to claim 14 or 15, characterized in that, The interaction module is specifically used for: Receive task information for the submission and release task in the at least one submission and release stage configured through the pipeline page, wherein the task information includes at least one of the following: task type, task name, and checkpoint validity period.

17. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the operational steps of the method as described in any one of claims 1 to 8.

18. A computer storage medium, characterized in that, The computer storage medium stores instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method according to any one of claims 1 to 8.

19. A computer program product, characterized in that, The computer program product stores instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method described in any one of claims 1 to 8.

Images