Automatic delivery method, automatic delivery platform, equipment, medium and product

Abstract

The invention discloses an automatic delivery method, an automatic delivery platform, equipment, a medium and a product, and belongs to the technical field of cloud computing. The method comprises the following steps: constructing a product delivery model for a product based on delivery metadata of the product and a predefined general delivery plug-in, and deploying the product delivery model and a product associated with the product delivery model to a delivery platform library; matching a product delivery model in the delivery platform library based on project requirements, and generating a project delivery scheme including hardware integration design and software integration design; analyzing the project delivery scheme, and based on the hardware integration design in the project delivery scheme, calling a predefined hardware operation instruction set to complete hardware integration deployment; and based on the software integration design in the project delivery scheme, calling a general delivery plug-in associated with the product delivery model to complete software integration deployment. According to the embodiment of the invention, quick delivery in a project integration scene can be realized, and the delivery efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to an automated delivery method, automated delivery platform, device, medium and product. Background Technology

[0002] Cloud service providers often face the challenge of delivering large-scale, multi-product integrated projects when offering diverse solutions including public, private, and hybrid clouds. Currently, automation technologies such as CI / CD pipelines primarily serve single-product R&D and deployment, while project-level delivery for multi-product, hardware / software integration still heavily relies on manual coordination and experience-based decision-making. Existing methods suffer from low efficiency in managing logic scripts, high script design difficulty and poor reusability when adapting to complex and flexible business scenarios, leading to low delivery efficiency and failing to meet the market demand for large-scale, rapid delivery of cloud services. Summary of the Invention

[0003] The purpose of this application is to provide an automated delivery method, automated delivery platform, equipment, medium, and product that can achieve rapid delivery and improve delivery efficiency in project integration scenarios.

[0004] To achieve the above objectives, a first aspect of this application provides an automated delivery method, which is executed by an automated delivery platform, the method comprising: Based on the product's delivery metadata and predefined general delivery plugins, a product delivery model is built for the product, and the product delivery model and its associated product deployment artifacts are published to the delivery platform library. Based on project requirements, the product delivery models in the delivery platform library are matched to generate a project delivery plan that includes hardware integration design and software integration design. The project delivery plan is analyzed, and based on the hardware integration design in the project delivery plan, a predefined hardware operation instruction set is invoked to complete the hardware integration deployment; based on the software integration design in the project delivery plan, a general delivery plugin associated with the product delivery model is invoked to complete the software integration deployment.

[0005] Compared with existing technologies, the automated delivery method provided in this application has the following advantages: It constructs a standardized product delivery model by integrating product delivery metadata and predefined general delivery plugins, and then publishes this model, along with product deployment artifacts, to the delivery platform library. This achieves standardized management of product delivery-related data and artifacts, effectively improving the reusability of product delivery capabilities, avoiding redundant construction of delivery capabilities, and reducing the development and management costs of product delivery models. Simultaneously, by directly matching standardized product delivery models in the platform library based on project requirements, it can quickly generate an integrated project delivery solution that combines hardware integration design and software integration design, reducing manual intervention in the solution design phase and improving efficiency. This improves the efficiency and accuracy of project delivery solution generation. Furthermore, after parsing the project delivery solution, hardware integration deployment is achieved by calling predefined hardware operation instruction sets, and software integration deployment is achieved by calling general delivery plugins associated with the product delivery model. This enables automated execution of hardware and software integration deployment in project integration scenarios, eliminating the need to develop separate deployment scripts for specific projects or products. This simplifies the project integration delivery execution process, improves overall delivery efficiency, and, relying on the automated delivery platform, completes the entire process from product delivery model construction and project delivery solution generation to hardware and software integration deployment. This achieves standardized and automated management of the cloud service delivery process, ensuring its stability and controllability.

[0006] In some embodiments, the construction of a product delivery model based on product delivery metadata and predefined generic delivery plugins includes: Register at least one predefined generic delivery plugin for the product; The product's delivery metadata is associated with the general delivery plugin to form a product delivery model; wherein, the delivery metadata includes a product model, a software model, and a configuration model; the product model is used to describe product specifications, the software model is used to describe software composition and deployment entry point, and the configuration model is used to describe configuration parameters and dependencies.

[0007] In some embodiments, publishing the product delivery model and its associated product deployment artifacts to the delivery platform repository includes: Based on the product delivery model, the product's deliverability is verified. Store the validated product delivery model and its associated product deployment artifacts in the delivery platform library.

[0008] In some embodiments, the step of matching product delivery models from the delivery platform library based on project requirements to generate a project delivery solution that includes hardware integration design and software integration design includes: Analyze project requirements and determine the target product needed; Based on the target product, match the corresponding product delivery model from the delivery platform library; Based on the product delivery model of the target product, combined with the project's configuration information and infrastructure data, hardware integration detailed design documents and software integration detailed design documents are automatically generated. The hardware integration detailed design document, the software integration detailed design document, and their associated product deployment artifacts are packaged into the project delivery solution.

[0009] In some embodiments, parsing the project delivery plan, based on the hardware integration design in the project delivery plan, calls a predefined hardware operation instruction set to complete hardware integration deployment; based on the software integration design in the project delivery plan, calls a general delivery plugin associated with the product delivery model to complete software integration deployment, including: Analyze the project delivery plan to generate a hardware integration task queue and a software integration task queue; For each task in the hardware integration task queue, based on the device type and role specified by the task, the corresponding pre-arranged hardware atomic instruction sequence is invoked to execute automated hardware configuration and installation; For each task in the software integration task queue, based on the product information of the task identifier, the general delivery plugin corresponding to the product information is invoked to execute the automated software deployment of that product.

[0010] In some embodiments, the invocation of the generic delivery plugin corresponding to the product information to perform automated software deployment of the product includes: The product's deployment logic is driven by the standard execution interface provided by the general delivery plugin.

[0011] To achieve the above objectives, a second aspect of this application provides an automated delivery platform, comprising: The product delivery capability registration module is used to build a product delivery model for a product based on the product's delivery metadata and predefined general delivery plugins, and publish the product delivery model and its associated product deployment artifacts to the delivery platform library. The project delivery solution generation module is used to match the product delivery models in the delivery platform library with project requirements and generate a project delivery solution that includes hardware integration design and software integration design. The automated execution module is used to parse the project delivery plan, and based on the hardware integration design in the project delivery plan, call a predefined hardware operation instruction set to complete the hardware integration deployment; and based on the software integration design in the project delivery plan, call a general delivery plugin associated with the product delivery model to complete the software integration deployment.

[0012] To achieve the above objectives, a third aspect of this application provides an electronic device including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0013] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium comprising a stored computer program, wherein the computer program, when executed, controls the device containing the computer-readable storage medium to perform the method described in the first aspect.

[0014] To achieve the above objectives, a fifth aspect of the present application provides a computer program product, which includes a computer program or computer instructions, wherein the computer program or computer instructions, when executed by a processor, implement the method described in the first aspect. Attached Figure Description

[0015] Figure 1 This is a flowchart of an automated delivery method provided in an embodiment of this application; Figure 2 This is a flowchart of the delivery process provided in an embodiment of this application; Figure 3 This is a flowchart of a product deliverability verification provided in an embodiment of this application; Figure 4 This is a flowchart of a deployment tool provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the automated delivery platform provided in an embodiment of this application; Figure 6 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0017] In the description of this application, it should be understood that the terms "center", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0018] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0019] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0020] With the rapid development of cloud computing technology, the ability of cloud service providers to quickly deploy and deliver cloud service solutions to enterprises is crucial. Cloud service project delivery involves multiple deliverables, including products, services, and networks, and often involves complex scenarios with multiple product combinations and cross-product integration, placing high demands on the automation and intelligence of delivery. Currently, mainstream cloud service providers are developing internal delivery systems towards automated and intelligent delivery. While they have launched delivery tools for specific products and scenarios, these tools have low design granularity, requiring coding implementation for specific business scenarios. This leads to redundant development across different business models and severely compromises the reusability of business capabilities.

[0021] Among related technologies, some solutions propose a general SOA service model deployment system. This system identifies model change feature parameters through differential comparison between two databases and verifies feature accuracy through offline training. This addresses the issue of manual intervention and communication costs after model delivery iterations to some extent. However, this solution requires advance preparation of logic processing scripts, and the feature data parsing module needs to be developed separately for different business scenarios. All model data, business processing scripts, and model files must be designed before the initial delivery. Furthermore, it lacks end-to-end design for project integration and delivery. Another solution proposes a project batch integrated delivery system based on CI / CD technology. This system automates the development process from requirement to compilation and deployment of a single product through a pipeline, improving the quality and efficiency of single product delivery. However, this system cannot achieve automated planning and integration between multiple product sets in a project scenario.

[0022] In summary, cloud service delivery technologies generally suffer from two major shortcomings: first, the management efficiency of logic scripts is low, and script design is difficult and reusability is poor when adapting to complex and flexible business scenarios; second, there is a lack of integrated delivery technology solutions for project integration scenarios, and the end-to-end automated delivery capabilities are insufficient, which cannot meet the rapid delivery needs of complex project integration scenarios such as cloud architecture, cloud business, and cloud solutions.

[0023] Based on this, embodiments of this application provide an automated delivery method, automated delivery platform, equipment, medium, and product that can achieve rapid delivery and improve delivery efficiency in project integration scenarios.

[0024] Please see Figure 1 , Figure 1 This is an optional flowchart of the automated delivery method provided in the embodiments of this application. Figure 1 The method is executed by an automated delivery platform and may include, but is not limited to, steps S101 to S103.

[0025] Step S101: Based on the product's delivery metadata and predefined general delivery plugins, build a product delivery model for the product, and publish the product delivery model and its associated product deployment artifacts to the delivery platform library; Step S102: Based on the product delivery model in the project requirements matching delivery platform library, generate a project delivery plan that includes hardware integration design and software integration design. Step S103: Analyze the project delivery plan; based on the hardware integration design in the project delivery plan, call the predefined hardware operation instruction set to complete the hardware integration deployment; based on the software integration design in the project delivery plan, call the general delivery plugin associated with the product delivery model to complete the software integration deployment.

[0026] Steps S101 to S103, as illustrated in this embodiment, construct a standardized product delivery model using product delivery metadata and predefined general delivery plugins. This model, along with product deployment artifacts, is then uniformly published to the delivery platform library. This achieves standardized management of product delivery-related data and artifacts, effectively improving the reusability of product delivery capabilities, avoiding redundant construction of delivery capabilities, and reducing the development and management costs of product delivery models. Simultaneously, by directly matching standardized product delivery models in the platform library based on project requirements, an integrated project delivery solution combining hardware and software integration design can be quickly generated, reducing manual intervention in the solution design phase and improving project delivery efficiency. The solution generation efficiency and design accuracy are improved. In addition, after parsing the project delivery solution, hardware integration deployment is achieved by calling a predefined hardware operation instruction set, and software integration deployment is achieved by calling a general delivery plugin associated with the product delivery model. This realizes the automated execution of hardware and software integration deployment in the project integration scenario, without the need to develop deployment scripts separately for specific projects or products. This simplifies the execution process of project integration delivery, improves the overall delivery efficiency, and relies on the automated delivery platform to complete the entire process operation from product delivery model construction and project delivery solution generation to hardware and software integration deployment. This realizes the standardization and automated management of the cloud service delivery process, ensuring the stability and controllability of the delivery process.

[0027] The automated delivery platform of this application constructs a three-layer collaborative architecture: delivery development, delivery design, and delivery operation. These three layers are seamlessly connected to form an end-to-end delivery closed loop. The delivery development phase is centered on the product flow. Through the construction of standardized product delivery models, CI / CD packaging, and deliverability reviews, it accumulates reusable product delivery capabilities and stores them in the delivery platform library. The delivery design phase is centered on digital design. Relying on metadata models and platform infrastructure capabilities, it transforms user requirements into an integrated project delivery solution that includes hardware integration design and software integration design. The delivery operation phase is centered on batch automated execution. It parses design solutions into executable tasks and achieves standardized integration, deployment, testing, and acceptance of hardware and software through hardware-based atomic instruction sets and general delivery plugins.

[0028] Please see Figure 2 In an optional embodiment, this solution divides the delivery process into three states to form an automated delivery platform: delivery development state, delivery design state, and delivery runtime state. The specific process is as follows: In the development delivery phase, because cloud service providers deliver cloud services using software as the carrier, delivery begins with the completion of software development logic, and this area is driven by the product flow. The product delivery model includes a product model describing a sellable product, a software model consisting of multiple software components, a configuration model describing project-related configurations and dependencies, and general delivery plugins associated with the product. Each product uses CI / CD technology to package deployment media based on this model and undergoes a deliverability review covering dimensions such as automated deployment processes, model references, and configuration setting checks. The corresponding product team evaluates whether the software deliverability and hardware convergence requirements are met according to product characteristics. After the review is passed, the software version is associated with the solution and finally released to the artifact repository.

[0029] In the delivery design phase, the synchronous process of the delivery development phase is carried over, corresponding to the content of the project delivery design scheme. This area includes a metadata model, which serves as the digital foundation for delivery. It covers the solution model supporting project delivery, the equipment model describing the resources and attributes involved in the hard set process, the product model describing the resources and attributes involved in the soft set product, the pipeline model defining the standard workflow plug-ins and processes, the software model defining the attributes of general software or clusters, and the configuration model defining various configurations in the project delivery process; as well as the platform's basic capabilities, including project management for managing project progress, project personnel, and project tasks, task management for managing delivery operations and including pipeline execution status maintenance, user management for the delivery platform's user permission system, and approval management for fine-grained management of project permissions to ensure project security and controllability. Driven by business flow, user requirements are imported through demand management, the optimal HLD solution is calculated, and adjustments to user requirements are supported. Automated cost calculation is also completed. Once the user confirms the requirements and quotation to form a real project, the project delivery is promoted through the delivery planning and delivery tools of the delivery platform. The solution is selected through delivery planning, and product matching is completed, including product version and baseline. The delivery manager completes the filling in of necessary project information, i.e., project configuration. The platform then automatically outputs rack design schemes. These rack design schemes are entered based on the results of the data center survey, forming a digital display of the assembly rack equipment port connection software relationships. Then, resources are matched from the hard set element database according to the standardized network testing template to form a network testing LLD design scheme. Based on the metadata information of the product model, software model, and configuration model, a soft set LLD design scheme is generated.

[0030] In the delivery operation phase, it inherits the business flow from the delivery design phase, corresponding to the specific delivery implementation process in the delivery plan. This area conducts delivery in a batch production line manner according to standardized plans. The mounting design plan and network commissioning LLD plan use standardized plan content as input to the hardware integration tools, guiding them to complete standard construction, automated hardware installation, automated network commissioning, and post-completion hardware inspection. The software integration LLD plan serves as input to the software integration tools, guiding them to complete standard software integration. Integration is built for both online and offline scenarios. The online scenario is directly integrated with the delivery center platform, while the offline scenario cannot be integrated with the delivery platform and must be achieved through import / export. After integration, the delivery platform completes project testing through automated testing tools and project acceptance through automated acceptance tools, ultimately leading to project transition and deployment.

[0031] In step S101 of some embodiments, delivery metadata is basic data that describes product delivery attributes, configuration rules, and deployment relationships. Delivery metadata includes product model, software model, and configuration model.

[0032] Predefined generic delivery plugins are standardized plugins developed in advance by the automated delivery platform that are adaptable to the integrated deployment of multiple product software and have general software deployment and execution capabilities, such as Helm, Playbook, Shell, Sealer, and HTTP plugins; Product delivery models are digital models built based on delivery metadata and generic delivery plugins; Product deployment artifacts are standardized media packages formed after the product has completed development and can be directly used for deployment, containing product programs, basic configuration files, etc.; Delivery platform library is a standardized resource library in the automated delivery platform used to uniformly store and manage product delivery models and related product deployment artifacts, supporting the retrieval and calling of models and artifacts.

[0033] In some embodiments, a product delivery model is built for the product based on the product's delivery metadata and predefined generic delivery plugins, including: Register at least one predefined generic delivery plugin for the product; The product's delivery metadata is associated with the general delivery plugin to form a product delivery model. The delivery metadata includes a product model, a software model, and a configuration model. The product model describes the product specifications, the software model describes the software structure and deployment entry point, and the configuration model describes the configuration parameters and dependencies.

[0034] Specifically, building a product delivery model is the primary action in the delivery development phase. Since cloud services are delivered using software as the carrier, delivery begins with the completion of software development. Therefore, the delivery development phase supports automated project delivery in the form of a product flow, and building a product delivery model is the first and crucial step in accumulating product delivery capabilities. This involves registering at least one predefined general delivery plugin for the product, enabling standardized and automated deployment capabilities and ensuring that subsequent product deployments can be executed in a standardized and reusable manner through this general plugin.

[0035] Delivery metadata, comprising product models, software models, and configuration models, serves as a digital carrier of product delivery capabilities. Specifically: the product model describes the marketable cloud service product, including information such as name, version, pricing, specifications, and baseline, clearly defining the product's market attributes and delivery benchmark, and acting as the primary identifier of the product as a deliverable; the software model is a digitally decomposed description of the product, as multiple software programs can collaborate to form a single product, containing software names, software versions, the product to which the software belongs, the software's own attributes, and basic configuration information, clearly defining the product's software structure and deployment entry point; the configuration model describes both the configuration parameters strongly relevant to the project within the product software and clarifies the dependencies between product software programs, specifically including configuration names, configuration items, configuration types, configuration values, and referenced software, ensuring both project compatibility of the configuration and traceability of dependencies.

[0036] Furthermore, associating product delivery metadata with predefined generic delivery plugins essentially binds the product's business attributes, software composition, and configuration dependencies with generic automated deployment capabilities, thereby forming a standardized product delivery model.

[0037] In some embodiments, publishing the product delivery model and its associated product deployment artifacts to the delivery platform repository includes: Based on the product delivery model, the product deliverability is verified. Store the validated product delivery model and its associated product deployment artifacts in the delivery platform library.

[0038] Specifically, after the product delivery model is built, each product will use CI / CD technology to package deployment media based on this model, resulting in product deployment artifacts associated with the product. Further, a deliverability review is added to the CI / CD process. The review criteria include multiple dimensions such as the completeness of the automated deployment process, the accuracy of model references, and configuration settings checks. The corresponding product team evaluates these aspects based on product characteristics to confirm that the product meets both software deliverability requirements and the settings requirements after hardware convergence. After the review is passed, the software version needs to be associated with the corresponding solution (such as public cloud, full-stack dedicated cloud, private cloud, edge station, etc.). Finally, the product delivery model and its associated product deployment artifacts are published to the artifact repository, providing standardized product resources that can be directly called upon for subsequent project deliveries.

[0039] It should be noted that deliverability verification is not conducted independently for a single product, but covers all products in the corresponding solution. The verification process must be performed on each product within the solution, and the overall process will only end after the verification of all products has been completed.

[0040] For example, please refer to Figure 3 When performing product deliverability verification, the first step is to determine if the product to be verified has been updated. If the product has not been updated, the deliverability verification process for that product is terminated directly. If the product has been updated, it is necessary to further determine whether the product is being integrated into the delivery system for the first time. If it is being integrated for the first time, an appropriate plugin must be selected from predefined common plugins such as Helm, Playbook, Shell, Sealer, and HTTP to complete the registration, edit the Service Code, and associate the product model, software model, and configuration model in the product code repository. Among these, the product model is defined according to the project scenario, supporting different product versions and features configured for different projects; the software model is defined according to the product delivery scenario dimension, and can correspond to the deployment entry point of the same tool. It does not require managing the deployment scripts of all components, and can be flexibly maintained in the product code repository, with multiple software models corresponding to one product model; the configuration model is used to describe various configuration standards for product delivery, supporting both common configurations that can be associated with multiple products and multiple software, and exclusive configurations adapted to specific product scenarios. If the product is not being integrated for the first time, the corresponding product model, software model, and configuration model data are directly retrieved from the configured code repository information to complete the relevant information updates.

[0041] It's important to note that the Service Code is a unique identifier for a product within the automated delivery platform. It's used by the platform to identify and associate the product with corresponding delivery resources, and is a crucial basis for the pipeline-driven engine to match general delivery plugins. Editing this code involves both creating a unique Service Code for newly integrated products and binding it to product information and selected general delivery plugins; and modifying, re-associating, or maintaining the attributes of existing Service Codes when product information is updated, plugin compatibility is adjusted, or deployment logic changes, to ensure the accuracy of the code's matching with the actual product delivery resources.

[0042] It should be noted that both the artifact library and the product code library belong to the delivery platform library. They respectively carry the storage and management functions of R&D resources and delivery media, and form an association mapping with the product delivery model resources to ensure closed-loop control of resources throughout the delivery chain.

[0043] Furthermore, after configuring or updating the aforementioned product delivery capabilities, the deliverability review phase is required. At this stage, different teams pull the corresponding deployment media, artifacts, and configuration information for the product in the integration verification environment and complete the deployment test; once the test review is passed, the product's deliverability verification is complete.

[0044] Once the deliverability verification of all products in the solution has passed, it means that the delivery metadata and artifact data information required for the project integration scenario are available. At this point, these data need to be synchronized to the system in the delivery design state (data synchronization is achieved by calling the metadata model interface). Finally, the verified product delivery model and its associated product deployment artifacts are stored together in the delivery platform library.

[0045] In step S102 of some embodiments, project requirements can be the user's delivery requirements for cloud service project integration, including information such as required product specifications, deployment scale, hardware configuration, and business function requirements; hardware integration design can be the standardized design content of the project delivery plan for the selection, networking, installation, and network debugging of hardware devices and other integration deployment requirements; software integration design can be the standardized design content of the project delivery plan for the deployment sequence, configuration adaptation, and component integration of product software and other deployment requirements; project delivery plan can be an integrated and directly executable project integration delivery plan generated by the automated delivery platform after matching the product delivery model with the project requirements, which includes hardware and software integration design.

[0046] In some embodiments, based on product delivery models in the project requirements matching delivery platform library, a project delivery solution including hardware integration design and software integration design is generated, including: Analyze project requirements and determine the target product needed; Based on the target product, match the corresponding product delivery model from the delivery platform library; Based on the product delivery model of the target product, combined with the project's configuration information and infrastructure data, hardware integration detailed design documents and software integration detailed design documents are automatically generated. Package the hardware integration detailed design document, the software integration detailed design document, and their associated product deployment artifacts into a project delivery solution.

[0047] Specifically, the process in this embodiment is completed in the delivery design phase, which includes modules such as platform basic capabilities, metadata model, requirements management, and delivery planning, to realize the digital and automated transformation from project requirements to delivery solutions.

[0048] First, the project requirements are analyzed. User-imported requirements include product specifications, equipment purpose, and procurement quantity. The metadata module has pre-built comprehensive equipment metadata (covering equipment name, manufacturer model, equipment purpose, and equipment configuration), and a fixed correspondence has been established between equipment purpose names and product model names. Simultaneously, the product model incorporates logical product clusters, containing logical definitions of product names, components, and configurations. Different specifications of the same product manifest as software and configuration differences at the delivery level, while the product version remains unchanged. Based on this metadata, the system first matches the corresponding product range based on the equipment purpose in the requirements, then filters out suitable specific products based on product specifications, ultimately determining the required target product. This process supports user adjustments to the requirements and automatically performs cost calculations. Once the user confirms the requirements and quote, a deliverable, real project is formally formed.

[0049] Furthermore, the product delivery model is matched. After identifying the target product, the corresponding solution is selected based on the project requirements. Then, the product delivery model corresponding to the target product is retrieved and matched from the delivery platform library. This product delivery model includes information such as product version and baseline, and has been associated with the product model, software model, and configuration model in the metadata model. This ensures that the matched model can adapt to the delivery requirements of the project integration scenario. At the same time, the platform's basic capabilities in the delivery design state (project management, task management, etc.) ensure that the matching process is orderly and controllable.

[0050] Furthermore, detailed hardware integration design documents (LLD) and detailed software integration design documents (LLD) are generated. Project-specific configuration information is filled in by the delivery manager through the system's visual interface, relating to project integration; infrastructure data consists of on-site data center survey results (including data center and rack information). Based on the target product's product delivery model, the platform first automatically outputs rack design schemes (digitally displaying the relationships between racks, devices, ports, connections, and software), then matches resources from the hardware set metadata database according to standardized network testing templates to generate network testing LLD design schemes (i.e., detailed hardware integration design documents); simultaneously, it combines metadata information from the product model, software model, and configuration model (including specification differences of the product's logical clusters) to generate software set LLD design schemes (i.e., detailed software integration design documents).

[0051] After generating detailed design documents for hardware and software integration, the system will export these digital LLD design schemes and integrate and package them with related product deployment artifacts to form an integrated project delivery scheme that can be directly executed. Subsequently, based on the project delivery scheme, corresponding delivery tools and tasks for each process can be generated to achieve seamless connection from requirements to delivery execution.

[0052] In step S103 of some embodiments, the hardware operation instruction set can be a standardized set of atomic instructions predefined by the automated delivery platform that can realize integrated operations such as hardware device installation and network debugging, and has general hardware operation execution capabilities; hardware integration deployment can be the process of completing hardware-level integration implementation such as hardware device installation, network debugging, and networking according to the hardware integration design requirements of the project delivery plan; software integration deployment can be the process of completing software-level integration implementation such as product software deployment, configuration, and component integration according to the software integration design requirements of the project delivery plan.

[0053] In some embodiments, the project delivery plan is parsed, and based on the hardware integration design in the project delivery plan, a predefined hardware operation instruction set is invoked to complete the hardware integration deployment; based on the software integration design in the project delivery plan, a generic delivery plugin associated with the product delivery model is invoked to complete the software integration deployment, including: Analyze the project delivery plan and generate hardware integration task queues and software integration task queues; For each task in the hardware integration task queue, based on the device type and role specified by the task, the corresponding pre-arranged hardware atomic instruction sequence is invoked to execute automated hardware configuration and installation; For each task in the software integration task queue, based on the product information of the task identifier, the general delivery plugin corresponding to the product information is invoked to execute the automated software deployment of that product.

[0054] Specifically, the process in this embodiment corresponds to the delivery implementation process in the delivery runtime state, which is promoted in a batch production line manner based on standardized solutions.

[0055] The project delivery plan includes hardware integration design (rack design scheme, network debugging LLD scheme) and software integration design (software LLD scheme). The parsing process requires importing these design contents, along with product service artifact packages and project equipment information, as final files into the deployment tool system; for example... Figure 4 As shown, the deployment tool system parses the LLD file through a built-in translator, and simultaneously parses the configuration model and renders the corresponding configuration values, generating hardware integration task queues and software integration task queues.

[0056] The tasks in the hardware integration task queue are specifically divided into network commissioning configuration instances and installation configuration instances. The execution process relies on the hardware integration automation tool module (including device module, architecture module, atomic module, and scenario module) in the delivery runtime state. The atomic module maintains the atomic execution instructions for each device in advance. Multiple atomic instructions can be assembled into scenario instances that match the device role type, manufacturer type, and initialization configuration. The architecture module defines the scenario combinations of hardware devices under different solutions. The deployment tool system matches the corresponding scenario instance according to the device type and role specified in the task, calls the pre-arranged hardware atomic instruction sequence, and executes standard construction, automated hardware installation, and automated network commissioning operations in sequence. After the operation is completed, it automatically performs hardware installation checks. This process relies on the accurate maintenance of device metadata and template information to ensure the compliance of hardware configuration and installation.

[0057] The software integration task queue is designed with a workflow of middleware deployment, basic service deployment, foundation service deployment, console service deployment, deployment integration testing, and virtual machine initialization. The execution process is managed by a unified pipeline-driven engine: Based on the product information identified by the task, the pipeline-driven engine matches the corresponding general delivery plugin (including Helm, Playbook, Shell, Sealer, HTTP, etc.; all products must be compatible with at least one plugin to achieve full-process automation) through the product's service code, starts the plugin logic, and calls the product's script entry point to complete the deployment. The deployment process supports both online and offline scenarios: in online scenarios, the software integration tools and the automated delivery platform are directly integrated; in offline scenarios, the solution and artifacts need to be transferred via import and export to achieve a closed-loop deployment. After software integration and deployment are completed, the automated delivery platform will launch automated testing and acceptance tools to complete the full-process verification. After successful verification, the project enters the maintenance and deployment phase.

[0058] In some embodiments, a generic delivery plugin corresponding to product information is invoked to perform automated software deployment of the product, including: The product's deployment logic is driven by the standard execution interface provided by the generic delivery plugin.

[0059] Specifically, the general delivery plugin, as a predefined standardized deployment tool of the platform, has a general software deployment and execution framework. The standard execution interface is the unified call entry point provided by the framework and a bridge connecting the general capabilities of the plugin with the product's specific requirements. This interface sets a unified calling specification for all adapted plugins, ensuring that the pipeline drive engine can call different types of plugins in a standardized manner without developing differentiated calling logic for plugin types, thereby enabling the product deployment logic to run.

[0060] In other embodiments, the product-specific deployment logic is driven by the standard execution interface provided by the general delivery plugin. Product-specific deployment logic refers to the unique deployment requirements formed by different products based on their own characteristics. This includes deployment dependency order of product components, assignment rules for personalized configuration parameters, product-specific deployment step requirements, and inter-component integration logic—deployment content strongly related to the product. This type of logic is personalized content not included in the default framework of the general delivery plugin. In this embodiment, the product-specific deployment logic can be embedded into the plugin's general execution framework through the standard execution interface of the general delivery plugin, enabling the plugin to adapt to product-specific requirements.

[0061] In actual execution, after the pipeline-driven engine matches the corresponding general delivery plugin with the product's Service Code, it issues execution instructions to the plugin through the plugin's standard execution interface. This drives the plugin to complete the fully automated software deployment process based on its own general deployment framework and the embedded product-specific deployment logic. This approach not only relies on the general delivery plugin to ensure the standardization and reusability of software deployment, avoiding the repetitive work of developing dedicated deployment tools for individual products, but also adapts to the personalized deployment needs of different products through the standard execution interface, ensuring the automated and standardized implementation of software deployment for different products in project integration scenarios.

[0062] In this embodiment, the automated delivery platform first analyzes the project delivery plan, extracts the specific execution requirements of the hardware and software integration design, calls up the predefined hardware operation instruction set based on the hardware integration design to execute and complete the hardware integration deployment, and at the same time calls up the general delivery plug-in associated with the product delivery model based on the software integration design to execute and complete the software integration deployment.

[0063] This method achieves standardized operations across the entire process, from product delivery model construction and project delivery solution generation to hardware and software integration deployment, through an automated delivery platform. Relying on predefined universal plugins and hardware operation instruction sets, it enhances the reusability of product delivery capabilities and avoids redundant development of deployment scripts. The delivery platform library enables centralized management of product delivery models and deployment artifacts, improving the matching efficiency between project requirements and product models. Simultaneously, hardware and software integration deployment are completed automatically by the platform calling predefined resources, achieving full automation of the delivery process in project integration scenarios. This reduces manual intervention, simplifies the delivery execution process, effectively improves the overall delivery efficiency of cloud service project integration, and lowers delivery management and implementation costs.

[0064] Please see Figure 5 This application also provides an automated delivery platform that can implement the above-described automated delivery method. The automated delivery platform includes: Product delivery capability registration module 501 is used to build a product delivery model for a product based on the product's delivery metadata and predefined general delivery plugins, and publish the product delivery model and its associated product deployment artifacts to the delivery platform library. The project delivery solution generation module 502 is used to generate a project delivery solution that includes hardware integration design and software integration design by matching the product delivery model in the delivery platform library with the project requirements. The automated execution module 503 is used to parse the project delivery plan, and based on the hardware integration design in the project delivery plan, call the predefined hardware operation instruction set to complete the hardware integration deployment; based on the software integration design in the project delivery plan, call the general delivery plugin associated with the product delivery model to complete the software integration deployment.

[0065] The specific implementation of this automated delivery platform is basically the same as the specific implementation of the automated delivery method described above, and will not be repeated here.

[0066] Thirdly, embodiments of this application provide an electronic device, see [link to relevant documentation]. Figure 6 The diagram shown is a structural schematic of an electronic device provided in this application.

[0067] like Figure 6 As shown, the device includes: Memory 31 is used to store computer programs; Processor 32 is used to execute computer programs; The processor 32 executes a computer program to implement an automated delivery method as described in any of the above embodiments.

[0068] For example, a computer program may be divided into one or more modules / units, one or more of which are stored in memory 31 and executed by processor 32 to complete this application. One or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in an electronic device.

[0069] The processor 32 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0070] The memory 31 can be used to store computer programs and / or modules. The processor 32 implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory 31 and calling the data stored in the memory 31. The memory 31 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 31 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0071] It should be noted that the aforementioned electronic devices include, but are not limited to, processors and memory, as will be understood by those skilled in the art. Figure 6 The structural diagram is merely an example of the electronic device described above and does not constitute a limitation on the electronic device. It may include more components than shown in the diagram, or combine certain components, or use different components.

[0072] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed, implements the automated delivery method of any of the above embodiments.

[0073] It should be understood that all or part of the processes in the automated delivery method described above can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the automated delivery method described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the relevant jurisdiction. For example, in some relevant jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0074] Fifthly, embodiments of this application also provide a computer program product, which is stored in a storage medium and executed by at least one processor to implement the automated delivery method of any of the above embodiments.

[0075] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0076] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications are also considered to be within the scope of protection of this application.

Claims

1. An automated delivery method, characterized in that, The method is executed by an automated delivery platform, and the method includes: Based on the product's delivery metadata and predefined general delivery plugins, a product delivery model is built for the product, and the product delivery model and its associated product deployment artifacts are published to the delivery platform library. Based on project requirements, the product delivery models in the delivery platform library are matched to generate a project delivery plan that includes hardware integration design and software integration design. The project delivery plan is analyzed, and based on the hardware integration design in the project delivery plan, a predefined hardware operation instruction set is invoked to complete the hardware integration deployment; based on the software integration design in the project delivery plan, a general delivery plugin associated with the product delivery model is invoked to complete the software integration deployment.

2. The method according to claim 1, characterized in that, The product-based delivery metadata and predefined generic delivery plugins are used to build a product delivery model, including: Register at least one predefined generic delivery plugin for the product; The product's delivery metadata is associated with the general delivery plugin to form a product delivery model; wherein, the delivery metadata includes a product model, a software model, and a configuration model; the product model is used to describe product specifications, the software model is used to describe software composition and deployment entry point, and the configuration model is used to describe configuration parameters and dependencies.

3. The method according to claim 2, characterized in that, The step of publishing the product delivery model and its associated product deployment artifacts to the delivery platform repository includes: Based on the product delivery model, the product's deliverability is verified. Store the validated product delivery model and its associated product deployment artifacts in the delivery platform library.

4. The method according to claim 1, characterized in that, The process of matching product delivery models from the delivery platform library with project requirements to generate a project delivery solution that includes hardware integration design and software integration design includes: Analyze project requirements and determine the target product needed; Based on the target product, match the corresponding product delivery model from the delivery platform library; Based on the product delivery model of the target product, combined with the project's configuration information and infrastructure data, hardware integration detailed design documents and software integration detailed design documents are automatically generated. The hardware integration detailed design document, the software integration detailed design document, and their associated product deployment artifacts are packaged into the project delivery solution.

5. The method according to claim 4, characterized in that, The process involves parsing the project delivery plan, and based on the hardware integration design within the project delivery plan, calling a predefined hardware operation instruction set to complete the hardware integration deployment. Based on the software integration design in the project delivery plan, the general delivery plugin associated with the product delivery model is invoked to complete the software integration and deployment, including: Analyze the project delivery plan to generate a hardware integration task queue and a software integration task queue; For each task in the hardware integration task queue, based on the device type and role specified by the task, the corresponding pre-arranged hardware atomic instruction sequence is invoked to execute automated hardware configuration and installation; For each task in the software integration task queue, based on the product information of the task identifier, the general delivery plugin corresponding to the product information is invoked to execute the automated software deployment of that product.

6. The method according to claim 5, characterized in that, The invocation of the general delivery plugin corresponding to the product information to perform automated software deployment of the product includes: The product's deployment logic is driven by the standard execution interface provided by the general delivery plugin.

7. An automated delivery platform, characterized in that, include: The product delivery capability registration module is used to build a product delivery model for a product based on the product's delivery metadata and predefined general delivery plugins, and publish the product delivery model and its associated product deployment artifacts to the delivery platform library. The project delivery solution generation module is used to match the product delivery models in the delivery platform library with project requirements and generate a project delivery solution that includes hardware integration design and software integration design. The automated execution module is used to parse the project delivery plan, and based on the hardware integration design in the project delivery plan, call a predefined hardware operation instruction set to complete the hardware integration deployment; and based on the software integration design in the project delivery plan, call a general delivery plugin associated with the product delivery model to complete the software integration deployment.

8. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the automated delivery method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium resides to perform the automated delivery method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions that, when executed by a processor, implement the automated delivery method as described in any one of claims 1 to 6.

Images