Software automatic distribution and deployment method oriented to cloud edge collaboration

Abstract

The invention discloses an automatic software distribution and deployment method and system oriented to cloud edge collaboration, and belongs to the technical field of distributed computing and continuous software delivery. The method comprises the following steps: a cloud creates a task based on a declarative deployment description unit and a release strategy; the intelligent scheduler constructs a hybrid distribution network according to the dynamic context of the node to carry out differential scheduling; the edge agent instantiates a description unit through environment injection, executes deployment through atomized transactions after pre-verification, and decides traffic switching or fast rollback according to a multi-stage health probe verification result; and the cloud side converges the global state through a bidirectional channel to realize strategy-based closed-loop management and control. According to the method, the problems of low software distribution efficiency, tedious deployment adaptation, poor reliability and difficulty in collaborative management and control of massive heterogeneous edge nodes in a weak network environment are solved, and efficient, intelligent and high-reliability cloud edge collaborative software delivery is realized.

Description

Technical Field

[0001] This invention relates to the fields of distributed computing, edge computing, and continuous software delivery technology, and in particular to a method and system for the automated, intelligent, and highly reliable distribution and deployment of software applications, service components, or artificial intelligence models to large-scale, heterogeneous, resource-constrained, and network-unstable edge computing nodes in a computing architecture that works collaboratively in the cloud and at the edge. Background Technology

[0002] With the widespread application of IoT, industrial internet, 5G, and artificial intelligence technologies, the computing paradigm is evolving from centralized cloud computing to collaborative computing across the cloud, edge, and device. In this architecture, the cloud center is responsible for global data aggregation, complex model training, and business orchestration; while the edge consists of a massive number of computing nodes distributed in the near field of the physical world, responsible for real-time data processing, low-latency response, and local intelligent decision-making.

[0003] Efficiently and reliably synchronizing software capabilities from the cloud to the edge is key to realizing the value of cloud-edge collaboration. However, this process faces severe challenges that traditional technologies struggle to address: First, there is a conflict between scale and efficiency, with the concurrent deployment requirements of millions of nodes far exceeding the capabilities of manual or script-based operations and maintenance; second, the network environment is complex, with edge nodes often located in wide area networks with limited bandwidth and unstable connections, making the transmission of large software packages highly prone to failure; third, nodes are highly heterogeneous, with differences in hardware architecture, operating systems, and resource specifications making software adaptation and deployment extremely cumbersome; fourth, reliability assurance is weak, with the complex edge environment posing a high risk of deployment failure and lacking effective automatic recovery mechanisms; and fifth, collaborative management is difficult, as existing tools lack the ability to perform fine-grained canary releases, state synchronization, and closed-loop control for large-scale edge nodes.

[0004] Currently, while there are container orchestration-based device management solutions, their initial design is primarily geared towards homogeneous, high-bandwidth data center environments. When dealing with the large-scale, weakly connected, and highly heterogeneous characteristics of edge computing scenarios, they exhibit significant shortcomings in distribution efficiency, environment adaptability, deployment reliability, and collaborative management. Therefore, there is an urgent need for a systematic method for automated software distribution and deployment specifically designed for cloud-edge collaboration. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a method and system for automatic software distribution and deployment oriented towards cloud-edge collaboration. This method aims to achieve the following core objectives: efficient and intelligent distribution of software artifacts to ultra-large-scale edge node clusters; automated and seamless deployment and adaptation of software in heterogeneous edge environments; the construction of a complete mechanism to ensure high reliability and business continuity during the deployment process; and the establishment of a cloud-edge collaborative management and control system that supports refined operation and maintenance.

[0006] To achieve the aforementioned objectives, this invention proposes an automated software distribution and deployment method for cloud-edge collaboration. The core of this method lies in constructing an automated, observable, and controllable software delivery closed loop from the cloud to the edge, through a declarative deployment description unit, an intelligent coordination engine, and a bidirectional state synchronization channel.

[0007] 1. System Architecture and Core Components

[0008] The method operates within a three-tier system architecture comprising a cloud-based control center, an edge service layer, and edge node agents. The cloud-based control center includes an artifact repository, a policy orchestration engine, an intelligent scheduler, and a status monitoring service. The edge service layer acts as a regional relay, providing caching and aggregation functions. The edge node agents reside on each edge device and contain a lightweight deployment engine. All components communicate and synchronize their status through a bidirectional status synchronization channel.

[0009] 2. Deployment intent abstraction based on declarative description

[0010] This invention introduces a machine-readable deployment description unit that defines a complete deployment blueprint in structured data form. Specifically, it includes:

[0011] Target node constraint set: Defines the attribute conditions that the edge node must meet to allow deployment, including but not limited to hardware architecture type, operating system category, minimum memory and storage space requirements, and optional dedicated hardware capability tags.

[0012] Software artifact referencing and selection logic: This describes the storage location and retrieval method of each component constituting the application (such as the base runtime image, business code package, dependency libraries, and AI model files). Specifically, this logic supports dynamically selecting the most suitable artifact version based on the specific tag attributes of the target node; for example, selecting the corresponding model file for nodes with different computational precision.

[0013] Atomic deployment execution plan: Defines a process consisting of multiple sequentially executed deployment phases, each phase containing a series of atomic operations. These steps cover environment verification, resource preparation, artifact installation, dynamic rendering of configuration files, service startup and shutdown, and finally, production traffic switching.

[0014] Multi-level health verification rules: Define multi-level health probes to determine whether deployment is successful, including startup probes to determine whether service processes have started successfully, readiness probes to determine whether services are ready to receive business traffic, and business logic probes to verify whether core business functions are normal. Each probe is configured with execution frequency, timeout, and success threshold.

[0015] Automated rollback plan: Defines a sequence of rollback operations corresponding to the execution plan, or specifies the logic for generating rollback rules. This plan clarifies under what triggering conditions (such as persistent health check failures or deployment step timeouts) a rollback should be performed, as well as the specific rollback steps, ensuring that the system can quickly recover to its previous consistent state.

[0016] 3. Context-Aware Intelligent Distribution and Scheduling: After receiving a published task, the cloud-based intelligent scheduler executes the following intelligent scheduling process:

[0017] Context collection and evaluation: Real-time acquisition of dynamic context information of target edge nodes, including network connection status, real-time bandwidth and latency data, current resource utilization, and geographical topology.

[0018] Hybrid distribution network construction: Based on the collected context, the optimal distribution topology is dynamically constructed. For clusters with excellent network quality and dense nodes, a peer-to-peer transmission network is automatically organized, and high-performance nodes are designated as seeds; for scattered or cross-regional nodes, the nearest content delivery network node or edge service layer cache is preferred; for offline nodes, encrypted offline packets are generated and marked as tasks to be synchronized.

[0019] Differentiated instruction issuance: Based on the node's role in the distribution topology and network conditions, personalized distribution instruction sets containing different resource pull address priorities are issued. All instructions are issued through a lightweight, reliable messaging channel and are digitally signed to ensure integrity and authenticity.

[0020] 4. Transactional deployment at the edge and health-driven decision-making

[0021] The deployment engine within the edge node agent is responsible for executing the following key processes:

[0022] Environment Injection and Plan Instantiation: The collected precise local environment information (such as hardware model, tags, and resource reserves) is injected into the deployment description unit and parsed into a specific sequence of instantiation deployment instructions that is completely specific to the current node.

[0023] Pre-deployment compliance verification: In an isolated sandbox environment, strictly verify whether this node meets all target constraints, check system dependencies and resource availability, and verify software artifact signatures to form a security and compliance checkpoint before deployment.

[0024] Atomic transaction execution: The instantiated sequence of deployment instructions is executed as a single transaction. The engine creates checkpoints before and after critical steps to ensure the atomicity of core operations such as directory switching. All intermediate operations are first completed in a sandbox to avoid polluting the production environment.

[0025] Health-driven verification and traffic switching: After deployment, verification is strictly performed according to the defined multi-level health verification rules. Only after all required health probes pass will the engine execute the final, atomic production traffic switching operation, officially launching the new version of the service. Afterward, temporary resources are cleaned up and a success status is reported.

[0026] Fast and accurate rollback: If a failure occurs at any stage of pre-verification, transaction execution, or health verification, the engine immediately executes the minimum necessary set of operations based on the rollback plan or transaction logs, and rolls back the service state to the consistency point before the upgrade in a very short time, ensuring business continuity.

[0027] 5. Global state synchronization and policy-driven closed-loop management

[0028] The cloud-based control center aggregates real-time status, event logs, and performance metrics from all edge nodes via bidirectional channels, forming a global situational view. Pre-defined policy rules in the policy orchestration engine automatically analyze the state flow and trigger corresponding actions. For example, "If the average error rate of nodes in a canary release batch exceeds a set threshold, subsequent batch releases will be automatically paused, and the upgraded nodes will be rolled back." The system also provides global version consistency auditing and compliance reporting functions, achieving closed-loop control from expected state to actual state.

[0029] Compared with the prior art, the present invention has the following significant advantages:

[0030] 1. Significantly improved distribution efficiency and success rate: By constructing an adaptive hybrid distribution network, fully utilizing edge network resources, the distribution latency and central bandwidth pressure under massive nodes are significantly reduced, and the transmission success rate in weak network environments is improved.

[0031] 2. Enables true one-click deployment in heterogeneous environments: The declarative deployment description unit abstracts and externalizes the environment adaptation logic, enabling the same application to automatically adapt to multiple hardware and software environments, greatly simplifying software supply chain management and realizing "define once, run everywhere".

[0032] 3. Deployment reliability meets production-grade requirements: Through a complete assurance chain consisting of pre-verification, transactional execution, health-driven decision-making, and rapid rollback, the impact of the deployment process on business is minimized, greatly improving the security and reliability of edge software changes.

[0033] 4. Enable refined cloud-edge collaborative operation and maintenance: Provide end-to-end observability and policy-based automated closed-loop control capabilities, support complex canary release strategies, and enable operation and maintenance personnel to manage ultra-large-scale edge computing clusters efficiently and accurately.

[0034] 5. The system has high flexibility and scalability: The layered architecture and loosely coupled component design make the system easy to expand, and the lightweight edge agent can be adapted to various resource-constrained devices, which can meet the continuous evolution needs of future edge computing scenarios. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the overall architecture of the cloud-edge collaborative software automatic distribution and deployment system provided in this embodiment of the invention.

[0036] Figure 2 This is a detailed flowchart of the software package preparation and release strategy definition phase in this embodiment of the invention.

[0037] Figure 3 This is a detailed flowchart of the intelligent distribution scheduling and adaptive transmission phase in an embodiment of the present invention.

[0038] Figure 4 This is a detailed flowchart of the edge node atomic deployment and health verification phase in an embodiment of the present invention.

[0039] Figure 5 This is a detailed flowchart of the cloud-edge collaborative monitoring and closed-loop rollback control phases in this embodiment of the invention. Detailed Implementation

[0040] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0041] Example 1: System Architecture Overview

[0042] See Figure 1 The system architecture of this invention mainly includes three logical layers: cloud control center, edge service layer and edge node agent, which work together.

[0043] The cloud-based control center, deployed in a cloud computing facility, is the brain of the system. It includes the following core service modules: an artifact repository module for storing versioned software artifact packages and deployment description units; a policy orchestration and engine module, providing a visual interface for operations personnel to define node grouping, release policies, and automation rules, with its internal policy rule base supporting conditional-action logic judgments; an intelligent scheduler module, the core of distribution decisions, with a built-in network cost model and topology analysis algorithm responsible for planning the optimal distribution path; a status monitoring and storage service module, responsible for receiving, processing, storing, and indexing status events, operation logs, and performance metrics data from all edge nodes in real time; and a unified management console module, providing users with a global visual view and interactive interface.

[0044] The edge service layer is an optional but recommended middleware layer, typically located in a regional data center or large edge site. It acts as a regional proxy in the cloud, primarily providing software artifact caching to accelerate distribution within the region, offering limited local autonomous management capabilities during network outages, and serving as an aggregation gateway for status reporting from a large number of end nodes within the region, thus reducing the pressure on direct cloud connections.

[0045] The edge node agent is a resident process deployed on each managed edge device, serving as the final execution unit for cloud commands. At its core is a lightweight deployment engine responsible for parsing and executing deployment descriptors and managing the entire lifecycle of the native software. The agent communicates with the upper layer through a bidirectional state synchronization channel, which supports command issuance, status reporting, and heartbeat maintenance, ensuring a controllable and reliable connection.

[0046] Example 2: Software Package Preparation and Strategy Definition Process

[0047] Combination Figure 2 This stage corresponds to the "deployment intent abstraction" in the technical solution, and the specific steps are as follows:

[0048] Step S201: Application Building and Artifact Generation. In the continuous integration / continuous delivery pipeline, source code compilation, building, and packaging are completed. The build process not only generates the application's main binary file or container image, but also generates corresponding auxiliary resource packages, dependency library sets, and parameterized configuration file templates based on different preset target environment matrices. All these files are organized according to a predefined structure and ultimately packaged into a self-contained, immutable software artifact package, assigned a unique version identifier.

[0049] Step S202: Create a declarative deployment description unit. This is the key innovation of this method. Developers or operations personnel need to write a deployment description unit, which is a structured document, such as using JSON or a similar format. It does not contain actual executable code, but rather describes the complete logic and rules of the deployment. This unit must contain the following parts:

[0050] The first part defines the target node selection rules, which declares which edge nodes with certain characteristics are suitable for this deployment. For example, the node architecture must be ARM64 or x86_64, the memory must be no less than 2GB, and the application must be labeled with "Inference Service".

[0051] The second part describes the composition and acquisition method of the software artifacts. For example, it specifies that the application consists of two parts: a "basic runtime environment image" and "AI model files". Among them, the model files need to dynamically select the file address for downloading either a high-precision version or a low-precision optimized version based on the specific value of the "computation precision" tag on the node.

[0052] Part Three details the execution steps for deployment. These steps are organized into clear phases, such as the "Preparation Phase," "Installation Phase," and "Switchover Phase." Each step defines specific actions and parameters, such as "verifying disk space in the Preparation Phase," "unzipping the model files to the specified directory in the Installation Phase," and "using atomic operations to switch the new version directory to the running directory in the Switchover Phase."

[0053] Part Four defines the standards for health verification. It defines at least two types of health checks: a simple service port reachability check (readiness probe) and a business check (business probe) that calls a specific API to verify the normal functioning of the service. For each check, it configures the check interval, timeout, and success count thresholds.

[0054] Part Five outlines the rollback plan. It clearly lists a series of reverse operation steps to be performed in the event of deployment failure or health check failure, ensuring the system can safely revert to its previous state.

[0055] Step S203: Define the release strategy and node grouping. On the management console of the cloud control center, operations personnel first create logical node groups using a flexible tag query language, such as "all edge nodes located in North America, running in production environments, and equipped with GPU hardware." Then, a release strategy is created for this group. The strategy includes: selecting the "Canary Release" mode, initially upgrading only 5% of the nodes marked "Canary" within the group, observing for 30 minutes; if the metrics are normal, then upgrading the remaining nodes in two batches, with a 1-hour interval between each batch. The strategy can also include automated decision points, such as "if the error rate increases by more than 0.05% after the Canary node upgrade, automatically abort the release."

[0056] Step S204: Submit and create a release task. Associate and bind the software artifact package, deployment descriptor unit, and release strategy as a complete release task and submit them to the system. After performing syntax and basic semantic checks on the deployment descriptor unit, the system generates a globally unique task identifier and sets the task status to "pending scheduling," awaiting the next stage.

[0057] Example 3: Intelligent Distribution Scheduling and Adaptive Transmission Process

[0058] Combination Figure 3 This stage corresponds to "intelligent distribution and scheduling" in the technical solution, and the specific steps are as follows:

[0059] Step S301: Task Scheduling Triggering and Dynamic Context Analysis. The intelligent scheduler module starts immediately upon detecting a task in the "pending scheduling" state. It first extracts the latest context snapshots of all edge nodes within the task target group from the status monitoring service. This context data includes not only static attributes but also dynamic information: such as the current network connection quality score of each node, the average network round-trip latency and available bandwidth for the most recent minute, the current utilization of the CPU and memory, and the network topology relationships between nodes inferred from historical communication records.

[0060] Step S302: Construct and optimize the hybrid distribution topology. Based on the real-time context, the scheduler models the large-scale distribution problem as a dynamic, constrained optimization problem. Its decision engine performs the following calculations: For geographically concentrated nodes with low network latency, it automatically constructs them into a peer-to-peer distribution cluster and selects several lightly loaded, stable nodes as initial data sources (seed nodes). For geographically dispersed nodes or nodes with poor direct cloud connection quality, it calculates the network cost to each edge service layer caching node or commercial content delivery network access point and assigns the optimal download source. For nodes identified as offline, the scheduler generates an offline data packet containing complete task instructions and encrypted software artifacts and marks the node's task status as "waiting for connection recovery."

[0061] Step S303: Issue differentiated distribution instructions. Based on the aforementioned topology plan, the scheduler generates and issues differentiated control instructions. These instructions are issued through a highly reliable, low-overhead message channel (such as a secure connection based on a message queue telemetry transport protocol). For ordinary nodes in a point-to-point cluster, the instruction may include: "Prioritize pulling data from seed node A (IP address) in the same cluster, with regional cache B as an alternative source." The instruction also includes a task identifier, deployment description unit content, data integrity checksum (such as a hash value), and digital signature.

[0062] Step S304: Edge Proxy Collaborative Retrieval and Verification. Upon receiving the instruction, the edge node proxy's built-in download manager begins operation. The download manager supports multi-source downloads and resume interrupted downloads, attempting to retrieve software artifact packages from different sources according to the priority order specified in the instruction. After downloading, the proxy immediately verifies the integrity of the data packet using the checksum provided in the instruction and confirms the authenticity and tamper-proof nature of the data source by verifying the digital signature. Only after successful verification does the proxy report an "Artifact Receipt Ready" status event to the cloud.

[0063] Example 4: Atomized Deployment and Health Verification Process of Edge Nodes

[0064] Combination Figure 4 This stage corresponds to "transactional deployment and health-driven decision-making" in the technical solution, and the specific steps are as follows:

[0065] Step S401: Environment Injection and Deployment Plan Instantiation. The edge deployment engine initiates this deployment process. It first comprehensively collects precise runtime information about the local node, including the specific CPU model, operating system kernel version, currently available memory and storage capacity, and all attribute tags on the device. Subsequently, the engine uses this information as variables and substitutes them into the received deployment description unit, "instantiating" it. For example, the abstract logic of "selecting a model based on the node's precision tag" in the description unit is now concretized as "the precision tag of this node is 'int8', therefore the specific file 'model_int8.tar.gz' should be downloaded." After instantiation, a fully defined and locally specific list of executable deployment operations is generated.

[0066] Step S402: Pre-deployment compliance and security verification. The engine executes the pre-check steps in the instantiation plan within a temporarily created, isolated workspace (sandbox). It checks one by one: whether the available local storage space meets the requirements; whether the versions of the required system dependency libraries exist and are compatible; whether the service ports to be installed conflict with existing services; and whether the digital signature of the software artifact is valid and from a trusted source. If any check fails, the engine logs detailed error information, aborts the deployment, and immediately reports the pre-check failure event to the cloud.

[0067] Step S403: Atomic Transaction Execution of Deployment Operations. After the pre-check passes, the engine begins executing core deployment operations in a transactional manner. Following the steps in the instantiation plan, it completes all preparatory work within the sandbox, including unpacking software artifacts, dynamically generating configuration files (filling local variables such as device IDs into templates), and installing dependencies. When executing the critical "switch" step, the engine uses atomic operations (such as atomic rename system calls in Unix-like systems) to instantly replace the existing running directory with the prepared new version's working directory. During this process, the engine records transaction logs and sets restore points before critical steps.

[0068] Step S404: Multi-level Health Verification. After the new version service process starts, the engine does not immediately consider the deployment successful, but instead initiates a health verification process. It first executes a "startup probe" to confirm the process's liveness. Then, it executes "readiness probes" at set time intervals, such as repeatedly attempting to connect to the service's health check interface until the number of consecutive successful connections reaches a threshold, indicating the service is ready. Finally, it executes a potentially more time-consuming "business probe," such as sending a standard test request to the service to verify the correctness of its returned results. Only when all three levels of checks pass according to the rules is the deployment marked as "healthy."

[0069] Step S405: Final Switchover and Cleanup. Upon receiving the "health" assessment, the engine performs the final production traffic switchover action (if a complete switchover was not performed previously), such as updating the local load balancer configuration or stopping the old version process. Subsequently, the engine cleans up the temporary sandbox space, deletes intermediate files except for the backup of the previous stable version, and reports a "deployment successful" final status event to the cloud, along with the initial performance metrics after service startup.

[0070] Step S406: Rapid Fault Recovery and Rollback. If an error or timeout occurs at any stage of steps S402 to S404, the engine immediately triggers the fault recovery process. It automatically executes a series of reverse operations based on the predefined rollback plan in the deployment description unit or on the transaction logs recorded during the execution of this transaction. These operations are designed to be fast and accurate, aiming to revert the service state to a consistent state before the deployment began in the shortest possible time (typically within seconds), ensuring minimal business interruption. After the rollback is complete, the engine reports a "deployment failed" event, along with error context information for analysis.

[0071] Example 5: Cloud-Edge Collaborative Monitoring and Closed-Loop Rollback Control Process

[0072] Combination Figure 5 The specific steps for "global state synchronization and closed-loop management" in this stage of the technical solution are as follows:

[0073] Step S501: End-to-End Status Aggregation and Correlation Analysis. The cloud-based status monitoring service, acting as a high-throughput event hub, continuously receives status event streams from millions of edge nodes. The system not only persistently stores these raw events but also performs real-time analysis through a real-time stream processing engine. This engine can calculate various aggregated metrics, such as: the real-time success rate trend of currently deployed tasks across different geographical regions; the difference between new and old deployment versions in key business metrics (such as the 99th percentile of transaction processing latency); and the average time distribution for each stage of the deployment process: "download," "installation," and "verification."

[0074] Step S502: Global Visualization and Situational Awareness. The unified management console provides operations and maintenance personnel with a rich set of visual dashboards. The global topology view displays the health status and software version of all edge nodes in real time on the map using different colors and icons. The release task dashboard displays the progress, success and failure node counts for each release batch in swimlane diagram format. The node details panel allows drill-down queries of the complete deployment history, real-time resource monitoring curves, and latest log entries for any node.

[0075] Step S503: Policy-Driven Anomaly Detection and Alarming. Rules in the policy orchestration engine are applied to the state event stream in real time. Users can configure rules such as: "If the average request error rate of 'Canary' batch nodes increases by more than 0.1% compared to the baseline before the upgrade within 10 minutes after the upgrade is completed, a critical level alarm will be generated immediately." When the rule conditions are met, the system automatically triggers an alarm and notifies the relevant responsible persons through pre-configured channels (such as SMS, email, and internal communication tools).

[0076] Step S504: Automated Decision-Making and Manual Intervention. Upon alarm triggering, the system can automatically make decisions based on pre-defined policies for the published task. For example, if the policy is "automatically pause the task if the canary batch fails," the system will automatically set the task status to "paused," preventing subsequent batches from starting. Simultaneously, the console provides operations personnel with a clear intervention interface, displaying the decision basis and recommended operations (such as "view failed node logs" and "execute rollback"), supporting manual review before executing the next command.

[0077] Step S505: Execute large-scale closed-loop control actions. When it is decided to roll back a batch of nodes, operations personnel can perform a one-click operation on the console. The cloud scheduler will generate a dedicated "rollback task" for this purpose. This task essentially instructs the target node group to execute the "rollback plan" defined in the deployment description unit corresponding to the previous stable version, which is stored locally. The execution process of this rollback task is also scheduled, monitored, and recorded throughout the entire chain, forming a complete control closed loop.

[0078] Step S506: Version Consistency Audit and Governance. The system periodically (e.g., daily) performs a global scan, comparing the "actually running" software version on all edge nodes with the "target set" version. This generates an "Edge Asset Software Compliance Report," clearly listing all "offset" nodes with inconsistent versions. Based on this report, operations personnel can easily initiate "repair" or "synchronize" tasks to force offset nodes to converge to the desired state, thereby ensuring eventual consistency of the ultra-large-scale edge cluster.

[0079] The present invention and its embodiments have been described above. This description is not restrictive, and the accompanying drawings are only one embodiment of the present invention; the actual structure is not limited thereto. In conclusion, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the invention, such designs should fall within the protection scope of the present invention.

Claims

1. A method for automatic software distribution and deployment oriented towards cloud-edge collaboration, characterized in that: The method operates within a three-tier system architecture comprising a cloud control center, an edge service layer, and edge node proxies, and includes the following steps: S1. The cloud management center creates declarative deployment description units and release strategies based on user input, and associates software artifacts to generate release tasks; the deployment description unit defines a deployment blueprint with structured data, including target node constraint sets, software artifact reference and selection logic, atomic deployment execution plans, multi-level health verification rules, and automated rollback plans; S2. The intelligent scheduler in the cloud control center responds to the published task, constructs a hybrid distribution network topology based on the acquired dynamic context information of the target edge nodes, and issues differentiated distribution instructions to the target nodes; S3. After receiving the distribution instructions, the edge node agent pulls and verifies the software artifact, performs environment injection and plan instantiation, and parses the deployment description unit into an instantiation deployment instruction sequence for the current node; S4. The edge node agent performs pre-deployment compliance verification in an isolated environment. After the verification is passed, the instantiation deployment instruction sequence is executed in an atomic transaction manner, and a health verification is performed according to the multi-level health verification rules after the execution is completed. S5. After the health verification is passed, the production traffic is switched over and temporary resources are cleaned up, and the success status is reported; if the failure occurs at any stage of pre-verification, transaction execution or health verification, the rollback operation is performed according to the automated rollback plan. S6. The cloud-based control center aggregates the status of all edge nodes through a two-way status synchronization channel to form a global situational view, and performs status analysis and closed-loop control based on pre-set policy rules.

2. The method for automatic software distribution and deployment oriented towards cloud-edge collaboration according to claim 1, characterized in that: The software artifact referencing and selection logic in the deployment description unit supports dynamically selecting the most matching artifact version based on the tag attributes of the target node. The deployment phases defined in the atomic deployment execution plan include environment verification, resource preparation, artifact installation, configuration rendering, service start / stop, and traffic switching.

3. The method for automatic software distribution and deployment oriented towards cloud-edge collaboration according to claim 1, characterized in that: In step S2, constructing the hybrid distribution network topology specifically includes: for clusters with excellent network quality and dense nodes, automatically organizing a point-to-point transmission network and specifying seed nodes; for scattered or cross-regional nodes, guiding them to the nearest edge service layer cache or content distribution network node; for offline nodes, generating encrypted offline packets and marking them as tasks to be synchronized.

4. The method for automatic software distribution and deployment for cloud-edge collaboration according to claim 1, characterized in that: In step S4, the execution in an atomic transaction manner includes: creating checkpoints before and after critical steps to ensure that the directory switching operation is an atomic operation, and that all intermediate operations are completed in a sandbox.

5. The method for automatic software distribution and deployment oriented towards cloud-edge collaboration according to claim 1, characterized in that: The multi-level health verification rules include a startup probe to determine whether the service process has started successfully, a readiness probe to determine whether the service is ready to receive business traffic, and a business logic probe to verify whether the core business functions are normal.

6. The method for automatic software distribution and deployment for cloud-edge collaboration according to claim 1, characterized in that: In step S6, the closed-loop management includes: the policy orchestration engine automatically analyzes the state flow and triggers automated actions when preset conditions are met, including pausing release, triggering rollback, or generating alarms.

7. A software automatic distribution and deployment system for cloud-edge collaboration, used to implement the method of any one of claims 1-6, characterized in that, include: The cloud-based control center includes an artifact repository for storing software artifacts and deployment description units, a policy orchestration engine for defining and parsing release policies, an intelligent scheduler for planning distribution paths, and services for status monitoring and storage. The edge service layer, deployed in regional data centers, is used to provide software artifact caching, status reporting aggregation, and limited local autonomous management. The edge node agent, deployed on each edge device, contains a lightweight deployment engine for executing deployment descriptors and managing the software lifecycle; The cloud-based control center, edge service layer, and edge node agent communicate through a two-way state synchronization channel.

8. The method for automatic software distribution and deployment for cloud-edge collaboration according to claim 7, characterized in that: The edge node agent also includes a download manager, which supports resuming downloads of software artifacts from multiple sources based on priority, and performs integrity verification and signature verification.

9. A method for automatic software distribution and deployment for cloud-edge collaboration according to claim 7, characterized in that: The cloud-based control center also includes a unified management console, which provides a global visualization view, a task publishing dashboard, node detail queries, and a manual intervention interface.

Images