A deployment method, device and deployment server of a software system

Abstract

The application provides a deployment method and device of a software system and a deployment server, relates to the technical field of software system deployment, and comprises the following steps: analyzing a construction parameter set of a to-be-deployed software system to obtain parameter characteristics; matching a pipeline execution process corresponding to the parameter characteristics from a pre-constructed shared pipeline library; and automatically executing the pipeline execution process based on the construction parameter set to complete automatic deployment of the to-be-deployed software system. The application analyzes the construction parameter set of the to-be-deployed software system to obtain the parameter characteristics, matches the pipeline execution process corresponding to the parameter characteristics from the pre-constructed shared pipeline library, and automatically executes the process based on the construction parameter set, so that different software systems can obtain an adaptive deployment process through the same set of shared pipeline libraries and automatically complete deployment only by providing respective construction parameter sets, and the deployment efficiency and consistency are improved.

Description

Technical Field

[0001] This application relates to the field of software system deployment technology, and more specifically, to a software system deployment method, apparatus, and deployment server. Background Technology

[0002] In automotive companies, the delivery of software systems such as vehicle software platforms, vehicle networking service systems, manufacturing execution systems (MES), and internal support platforms typically requires configuring a separate pipeline script or build configuration file for each software system. The pipeline script not only needs to define parameters but also script execution logic. When different software systems need to be deployed, operations and maintenance personnel must manually select and call the corresponding script from a large number of scattered scripts based on the type of system to be deployed, which seriously reduces deployment efficiency. Summary of the Invention

[0003] The purpose of this application is to provide a software system deployment method, apparatus, and deployment server to solve the above-mentioned problems existing in the prior art and improve the efficiency of software system deployment.

[0004] Firstly, a method for deploying a software system is provided, which may include: The set of construction parameters for the software system to be deployed is parsed to obtain parameter characteristics; Match the pipeline execution process corresponding to the parameter characteristics from the pre-built shared pipeline library; Based on the set of construction parameters, the pipeline execution process is automatically executed to complete the automated deployment of the software system to be deployed.

[0005] In an optional implementation, the set of build parameters includes: build commands, build environment parameters, and deployment target parameters; The shared pipeline library includes a stage rule library and a strategy rule library; the stage rule library contains the execution order of different pipeline stages and multiple stage rules; each stage rule contains stage rule conditions and the corresponding pipeline stage; the strategy rule library includes multiple strategy rules; each strategy rule contains strategy rule conditions and the corresponding execution strategy.

[0006] In an optional implementation, the set of construction parameters of the software system to be deployed is parsed to obtain parameter characteristics, including: The build command, build environment parameters, and deployment target parameters are parsed to obtain the first parameter feature, the second parameter feature, and the third parameter feature.

[0007] In an optional implementation, a pipeline execution flow corresponding to the parameter characteristics is matched from a pre-built shared pipeline library, including: Based on whether the first parameter feature, the second parameter feature, and the third parameter feature satisfy the stage rule conditions of each stage rule in the shared pipeline library, the pipeline stage to be executed is determined. The execution strategy is determined based on whether the first parameter feature, the second parameter feature, and the third parameter feature satisfy the policy rule conditions of each policy rule in the shared pipeline library. Based on the execution strategy, the execution order of the different pipeline stages, and the pipeline stages to be executed, a pipeline execution flow is generated.

[0008] In an optional implementation, the set of build parameters may further include: code repository address and code branch parameters; Based on the set of construction parameters, the pipeline execution process is automatically executed to complete the automated deployment of the software system to be deployed, including: Based on the code repository address and the code branch parameters, obtain the source code from the deployment server; Based on the construction environment parameters, determine the container instance corresponding to each pipeline stage to be executed in the pipeline execution process; Within a defined container instance, the build command is executed to compile the source code and generate a compiled artifact. Based on the deployment target parameters and the execution strategy in the pipeline execution process, the compiled artifact is deployed in the target runtime environment.

[0009] In an optional implementation, if the pipeline stage to be executed includes an image building stage, then after generating the compiled artifact, the method further includes: Based on the execution strategy in the pipeline execution process and the compiled artifact, an image file is generated; Based on the deployment target parameters and the execution strategy, the image file is deployed in the target runtime environment.

[0010] In an optional implementation, the method further includes: If the set of construction parameters fails the security check, the automated deployment of the software system to be deployed will be terminated.

[0011] Secondly, a software system deployment apparatus is provided, the apparatus comprising: The parsing unit is used to parse the set of build parameters of the software system to be deployed to obtain parameter characteristics; The matching unit is used to match the pipeline execution process corresponding to the parameter features from a pre-built shared pipeline library; The deployment unit is used to automatically execute the pipeline execution process based on the set of construction parameters to complete the automated deployment of the software system to be deployed.

[0012] Thirdly, a deployment server is provided, the deployment server including a memory and a processor, the memory storing a shared pipeline library, and the processor executing instructions in the memory to implement any of the methods described in the first aspect above.

[0013] Fourthly, a vehicle controller is provided, the vehicle controller being used to perform any of the methods described in the first aspect above to achieve automated deployment of the vehicle's software system on the vehicle controller.

[0014] This application parses the build parameter set of the software system to be deployed to obtain parameter characteristics, matches the pipeline execution process corresponding to the parameter characteristics from a pre-built shared pipeline library, and then automatically executes the process based on the build parameter set. This allows different software systems to obtain a suitable deployment process and automatically complete the deployment by providing their own build parameter sets through the same shared pipeline library, without the need to write deployment scripts separately for each software system. This drives the automated deployment of any system with a unified deployment entry point, significantly reducing manual intervention in deployment operations and improving deployment efficiency and consistency. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a software system deployment method provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of a software system deployment device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a deployment server provided in an embodiment of this application. Detailed Implementation

[0017] 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 a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The words "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The words "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but do not exclude other elements or objects. The words "connected," "coupled," or "connected," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up," "down," "left," "right," etc., are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0018] The software system deployment method provided in this application embodiment can be applied to servers or terminals. The server can be a physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal can be user equipment (UE) such as mobile phones, smartphones, laptops, digital radio receivers, personal digital assistants (PDAs), and tablet computers (PADs), handheld devices, in-vehicle devices, wearable devices, computing devices, or other processing devices connected to a wireless modem, mobile stations (MS), mobile terminals, etc.

[0019] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0020] Figure 1 This is a flowchart illustrating a software system deployment method provided in an embodiment of this application. Figure 1As shown, the method may include: Step S110: Analyze the set of construction parameters of the software system to be deployed to obtain parameter characteristics.

[0021] The build parameter set can include: code repository address, code branch parameters, build command, build environment parameters, and deployment target parameters. The code repository address parameter is a URL that points to the deployment server storing the source code of the software system to be deployed. The code branch parameter is a string that specifies the source code to be pulled from the repository pointed to by the code repository address, such as main, develop, or release / 2.0. The build command parameter is a string that describes the specific instructions for compiling or packaging the software system to be deployed, such as mvn clean install for Java projects or npm run build for front-end projects. The build environment parameter is a string that specifies the runtime environment required to execute the build command, usually using the name of the container image as its value, such as maven:3.8-openjdk-11 or node:16-alpine. The deployment target parameter is a string that identifies the target runtime environment where the software system to be deployed will ultimately be deployed, such as the Kubernetes cluster name, host IP address, or vehicle identifier.

[0022] In practice, users participate in and trigger a parameterized job to obtain the set of build parameters for the software system to be deployed through one of the following three methods: manually filling in the parameters through the Jenkins web page and clicking build, passing the parameters via a remote API interface using an HTTP request, or automatically triggering the job through a pre-set scheduled task; the build command, build environment parameters, and deployment target parameters are parsed to obtain the first parameter feature, the second parameter feature, and the third parameter feature.

[0023] This application introduces a parameterization mechanism by constructing a parameter set, enabling the same pipeline entry point to adapt to different code repository addresses, different code branches, different build commands, different build environments, and different deployment strategies, thereby avoiding the need to maintain a separate pipeline configuration file for each software project.

[0024] In one embodiment of this application, before parsing the set of build parameters for the software system to be deployed, the method may further include: The security of the build commands in the build parameter set is verified, and the verification results are obtained, including: The build command is decomposed into an abstract syntax tree using a pre-built parser based on an abstract syntax tree; each node of the abstract syntax tree is traversed to identify all call names or command names; Each identified command name is compared with a preset list of dangerous commands. If a build command contains any dangerous command name, and the parameters of the corresponding build command contain dangerous flags such as recursive deletion flags, root directory paths, or wildcards, then the build command is determined to contain an unauthorized deletion operation or a prohibited command. The corresponding build parameter set fails the security check, the automated deployment of the software system to be deployed is terminated, no subsequent parsing, matching, or deployment steps are executed, and a configuration error message is output. The list of dangerous commands includes at least the following command names: delete commands and their parameters for recursively deleting files, format commands for formatting disks, overwrite commands for overwriting, and permanent deletion commands for permanently deleting files. Once the parameter set passes the security check, proceed with the next steps.

[0025] In another implementation, the build command is input into a lightweight sandbox for simulated execution. The sandbox intercepts all file system calls but does not actually modify the disk. The call records generated during the simulated execution are monitored. If any system call for deletion is detected and the target path of the deletion operation does not belong to the preset security whitelist directory, it is determined that the build command has illegal deletion behavior, the corresponding build parameter set fails the security check, the automated deployment of the software system to be deployed is terminated, no subsequent parsing, matching or deployment steps are executed, and the configured error message is output.

[0026] In another embodiment of this application, the build command, build environment parameters, and deployment target parameters are parsed to obtain a first parameter feature, a second parameter feature, and a third parameter feature, including: Parsing the build command parameters to obtain the first parameter feature can include the following steps: matching the build command parameters with preset keywords, and generating the first parameter feature based on the matching results; the first parameter feature can include: Maven build feature and NPM build feature; wherein, the preset keywords include mvn, maven, npm, go, and pip, etc., each corresponding to different build tools; the first parameter feature is used to indicate whether the corresponding build stage needs to be executed; if the feature value of the first parameter feature is true, the corresponding build stage needs to be executed; if the build command contains mvn or maven, a boolean Maven build feature is generated to indicate that the Maven build stage needs to be executed; if the build command contains npm, an NPM build feature is generated to indicate that the NPM build stage needs to be executed; if the build command does not contain any preset keywords, the value of the generated first parameter feature is empty or 0; Parsing the build environment parameters to obtain the second parameter feature can include the following steps: matching the build environment parameters with preset environment keywords, and generating the second parameter feature based on the matching results; wherein, the preset environment keywords may include maven, Java, node, and python, etc.; the second parameter feature is used to characterize the type of runtime environment required for this deployment; if the build environment contains maven or Java, a Java environment feature is generated; if the build environment contains node, a Node environment feature is generated; if the build environment contains python, a Python environment feature is generated; if the build environment does not contain any preset keywords, the value of the second parameter feature is empty or 0; Parsing the deployment target parameters to obtain the third parameter feature can include the following steps: determining whether the deployment target parameter is empty or does not exist; if the value of the deployment target parameter is not empty, generating a deployment feature to characterize that deployment is required; further performing deployment type keyword matching processing on the deployment target parameter, and generating a deployment type feature based on the matching result; wherein, the preset deployment type keywords include k8s, kubernetes, host, and compose, etc.; if the deployment target parameter contains k8s or kubernetes, the deployment type feature is k8s; if the deployment target parameter contains host or compose, the deployment type feature is host; if the value of the deployment target parameter is empty or does not exist, it indicates that no deployment is required, and no deployment feature or deployment type feature is generated; the deployment feature and deployment type feature are used as the third parameter feature. The first parameter feature, the second parameter feature, and the third parameter feature are combined into a feature vector in a preset order to obtain the parameter features.

[0027] Step S120: Match the pipeline execution process corresponding to the parameter characteristics from the pre-built shared pipeline library.

[0028] The shared pipeline library includes a stage rule library, a strategy rule library, parsing logic, and matching logic. The stage rule library contains the execution order of different pipeline stages and multiple stage rules. Each stage rule contains stage rule conditions and the corresponding pipeline stage. The strategy rule library includes multiple strategy rules. Each strategy rule contains strategy rule conditions and the corresponding execution strategy.

[0029] In practice, the pipeline stage to be executed is determined based on whether the first, second, and third parameter features satisfy the stage rule conditions of each stage in the shared pipeline library. Specifically, the first, second, and third parameter features are sequentially verified to ensure they meet the stage rule conditions of each stage. If any parameter feature satisfies the corresponding stage rule condition, the pipeline stage corresponding to that stage rule condition is determined as the pipeline stage to be executed. The pipeline stages to be executed can include: code download stage, Maven compilation stage, NPM compilation stage, image building stage, and automated deployment stage. Pipeline stages not included in the pipeline stages to be executed will not be generated or executed, thus enabling the pipeline execution process to be dynamically tailored according to different projects and different parameter combinations. This method achieves dynamic generation of the pipeline structure, avoiding the problems of fixed pipeline stages and rigid processes in traditional pipelines. The execution strategy is determined based on whether the first, second, and third parameter features satisfy the policy rule conditions of each policy rule in the shared pipeline library. Specifically, the deployment strategy is determined based on whether the third parameter feature satisfies the policy rule conditions of each policy rule in the shared pipeline library. The execution strategy may include: a rolling update deployment strategy and a host deployment strategy. The rolling update deployment strategy is used to update the image version in the Deployment by calling the Kubernetes API, triggering a rolling update to achieve uninterrupted service deployment. The host deployment strategy is used to connect to the target host via SSH, transfer the docker-compose.yml file, and execute the docker-compose up -d command to complete the deployment and startup of the service. Based on the execution strategy, the execution order of different pipeline stages, and the pipeline stages to be executed, a pipeline execution flow is generated.

[0030] Step S130: Based on the set of construction parameters, automatically execute the pipeline execution process to complete the automated deployment of the software system to be deployed.

[0031] In one embodiment of this application, if the pipeline stage to be executed does not include an image building stage, then based on the set of build parameters, the pipeline execution process is automatically executed to complete the automated deployment of the software system to be deployed, which may include: Based on the code repository address and code branch parameters, the source code is retrieved from the deployment server. Specifically, a Git request is sent to the remote code repository server on the deployment server, and the source code corresponding to the code repository address and code branch parameters is pulled to the local workspace directory of the vehicle controller, server, or terminal. After the pull is completed, the workspace path is recorded in the pipeline execution process. Based on the build environment parameters, determine the container instances corresponding to each pipeline stage to be executed in the pipeline execution process. If the pipeline stages to be executed include Maven compilation stages, NPM compilation stages, and other similar compilation or build stages, then the container instances corresponding to these stages must be determined. All compilation stages are selected from the pipeline stages to be executed. The container image names corresponding to the build environment parameters are determined. A one-to-one correspondence is established between each selected compilation stage and its corresponding container image name, and this correspondence is configured as the runtime configuration for the pipeline execution process. When a compilation stage is actually executed, the container runtime (such as Docker or containerd) is invoked according to the runtime configuration to pull the corresponding image from the image repository (if it does not exist locally), create and start the container instance, and mount the workspace into it to execute the build command. Within a defined container instance, a build command is executed to compile the source code and generate compiled artifacts. Specifically, the container image name corresponding to the compilation stage is read from the pipeline execution configuration. The local container runtime checks if the image already exists locally; if not, it is pulled from the remote image repository on the deployment server. A new container instance is created and started. The workspace directory obtained during the source code acquisition process is mounted to a fixed path inside the container in the startup parameters. The container's working directory is set to this mount point, and the container startup command is set to the build command from the build parameter set. After the container starts, the internal build process reads the mounted source code in an isolated file system environment, performs compilation, linking, and packaging operations, and writes the generated compiled artifacts (such as JAR files, WAR files, binary files, or static resources) to a specified output subdirectory in the workspace (e.g., "target / "). Since the workspace directory is mounted, the files written inside the container will appear directly in the host machine's workspace. The deployment service blocks and waits for the build command inside the container to complete, obtaining its exit code: if the exit code is zero, it indicates successful compilation and artifact generation; if it is non-zero, it indicates compilation failure. Regardless of success or failure, the deployment service then stops and removes the container instance (retaining the artifacts in the workspace), and records the artifact storage path in the context of the pipeline execution process for use in subsequent image building or deployment stages. Throughout the process, the container instance provides a reproducible compilation environment isolated from the host machine, ensuring that different build tasks do not interfere with each other; Based on the deployment target parameters and the execution strategy in the pipeline execution process, the compiled artifacts are deployed in the target runtime environment. Specifically, the deployment target parameters and execution strategy are read from the pipeline execution process. When the execution strategy is a host deployment strategy, the following operations are performed: the storage path of the compiled artifacts is obtained from the runtime context of the pipeline execution process; a secure connection is established with the target host based on the host address in the deployment target parameters and pre-configured authentication credentials; the compiled artifact files are transferred to the preset deployment directory on the target host via SCP or SFTP protocol; after the transfer is complete, a startup command is executed on the target host via SSH, for example, `java -jar / opt / app / myapp.jar` for Java artifacts and `chmod +x / opt / app / myapp && / opt / app / myapp` for binary artifacts; the startup command is waited for to complete, and the process is checked for survival (e.g., by checking the PID or listening port). If the startup is successful, the deployment is complete; if it fails, the failure handling strategy determines whether to roll back or terminate.

[0032] In one embodiment of this application, if the pipeline stage to be executed includes an image building stage, then based on the set of build parameters, the pipeline execution process is automatically executed to complete the automated deployment of the software system to be deployed, which may include: Based on the code repository address and code branch parameters, the source code is retrieved from the deployment server. Specifically, a Git request is sent to the remote code repository server on the deployment server, and the source code corresponding to the code repository address and code branch parameters is pulled to the local workspace directory of the vehicle controller, server, or terminal. After the pull is completed, the workspace path is recorded in the pipeline execution process. Based on the source code, the image build strategy is determined. Specifically, it checks if a file named docker-compose.yml exists in the source code. If it does not exist, it checks if a file named Dockerfile exists. If docker-compose.yml exists, the image build strategy is determined to be a multi-service image build strategy, meaning that multiple service images need to be built and packaged simultaneously using the docker-compose command. If docker-compose.yml does not exist but Dockerfile exists, the strategy is determined to be a single-image build strategy, meaning that a single image is built based on the Dockerfile using the docker build command. If neither exists, it is handled according to the preset default behavior (e.g., termination with an error, or using a default Dockerfile template). Based on the build environment parameters, determine the container instance corresponding to each pipeline stage to be executed in the pipeline execution process; Within a defined container instance, a build command is executed to compile the source code and generate compiled artifacts. Based on the execution strategy and compiled artifacts in the pipeline execution process, image files are generated. Specifically, if the execution strategy is a single-image build strategy, a Dockerfile file is found in the workspace directory. This file typically contains the base image, instructions for copying compiled artifacts, and startup commands. The local Docker daemon is invoked, and the `docker build` command is executed, specifying the Dockerfile path and build context (i.e., the workspace directory), with the directory containing the compiled artifacts as part of the build context. The Docker daemon copies the compiled artifacts to the image layer according to the instructions in the Dockerfile, ultimately generating a new container image. This image is tagged (the tags come from the image tag parameters in the build parameter set), and `docker push` is executed to push the image to the preset image repository. If the execution strategy is a multi-service image build strategy, a `docker-compose.yml` file is found in the workspace directory. This file defines the build methods for multiple services (e.g., each service corresponds to a Dockerfile in a subdirectory). The `docker-compose build` command is executed, and the Compose tool will build multiple service images sequentially or in parallel according to the definitions in the file. After the build is complete, the deployment service executes `docker-compose push` to push all generated images to the configured image repository. The tag of each image is determined by the configuration in the Compose file or external parameters. Based on the deployment target parameters and execution strategy, the image file is deployed in the target runtime environment. Specifically, if the execution strategy is a rolling update deployment strategy, the target runtime environment is a container orchestration cluster (such as Kubernetes). The process reads the pre-configured Kubernetes resource configuration file (such as Deployment YAML) in the pipeline execution flow or dynamically constructs an update request via API. It calls the local kubectl command-line tool or directly calls the Kubernetes API to update the value of the container image field in the Deployment object to the image file address. After receiving the update request, the Kubernetes cluster initiates the rolling update process: gradually creating Pods for new images while terminating Pods for old images to ensure uninterrupted service. The deployment service can poll the update status and wait for all Pods to be ready. After the rolling update is complete, the deployment service records the new replica set version. If the execution strategy is a host deployment strategy, the target runtime environment is one or more hosts running DockerEngine. It reads the target host's address (from the deployment target parameters) and SSH access credentials from the pipeline execution flow; writes the image file address into the docker-compose.yml file (or overrides it via environment variables); transfers the docker-compose.yml file and necessary environment configuration files to the specified directory on the target host via SSH; executes the `docker-compose pull` command on the remote host to pull the new image file from the image repository; after pulling, executes the `docker-compose up -d` command to recreate and start the container according to the compose file. The deployment service can check the container's running status to confirm that the service has started normally.

[0033] In yet another embodiment of this application, the method may further include, before parsing the set of construction parameters: A historical parameter database is pre-built, storing the set of construction parameters corresponding to a preset number of successful deployments in the past. For the currently received set of construction parameters, the frequency of each parameter appearing in the historical parameter database is calculated, and the reciprocal of the frequency is multiplied by a preset weighting coefficient to obtain the risk score of the parameter. If the risk score of any parameter exceeds a preset risk threshold, the parameter is marked as a high-risk parameter, and a secondary confirmation request is returned at the triggering end. The secondary confirmation request contains the comparison information between the current value and the historical value of the high-risk parameter. When a confirmation instruction is received, subsequent steps are executed. If no confirmation instruction is received or a rejection instruction is received, the deployment process is terminated.

[0034] In another embodiment of this application, the process of performing security verification on the build command using an abstract syntax tree-based parser also includes command obfuscation detection processing: The build command is normalized, and the normalization process includes removing all whitespace characters, escape sequences, and command-line comments; The normalized build command is decomposed into an abstract syntax tree using an abstract syntax tree parser, and the hash value of the tree is calculated to obtain the normalized hash value. A dangerous command hash library is pre-built, which contains the hash values ​​of plaintext dangerous commands and variant hash values ​​after preset obfuscation transformations. The preset obfuscation transformations include alternating uppercase and lowercase letters, inserting invalid characters, and using backslashes for line breaks. The normalized hash value is compared with all hash values ​​in the dangerous command hash library. If a match is found, it is determined that the build command contains an unauthorized deletion operation or a prohibited command, the automated deployment of the software system to be deployed is terminated, and the configured error message is output. If a match is not found, the parameter danger flag matching continues.

[0035] In another embodiment of this application, the process of matching the construction command parameters with preset keywords to generate the first parameter feature may further include: A keyword variant dictionary is pre-constructed, whereby each preset keyword is associated with a set of common variants. These common variant sets are generated through offline analysis of historical build command logs. For an input build command string, consecutive letter sequences are extracted, and the minimum edit distance between each letter sequence and each keyword in the keyword variant dictionary is calculated. If the minimum edit distance is less than a preset edit distance threshold, the letter sequence is mapped to the corresponding preset keyword, and a corresponding first parameter feature is generated based on that preset keyword, with the corresponding Boolean feature value set to true. If the minimum edit distance is greater than or equal to the edit distance threshold, no corresponding first parameter feature is generated.

[0036] In another embodiment of this application, parallel scheduling based on a directed acyclic graph (DAG) can be introduced during the generation of the pipeline execution flow. Specifically, each stage in the set of pipeline stages to be executed is modeled as a node in a DAG, and directed edges are established according to the dependencies between stages (e.g., the image build stage depends on the Maven compilation stage or the NPM compilation stage) to obtain a stage dependency graph. A topological sort is performed on the stage dependency graph, and all nodes with an in-degree of zero are identified. The stages corresponding to these nodes are marked as parallelizable stages. The pipeline execution engine creates independent execution threads for each of the parallelizable stages, executes the parallelizable stages simultaneously, and updates the stage dependency graph after each stage is completed, recalculating the nodes with an in-degree of zero. This approach achieves maximum parallelism while ensuring the correct execution order of stages, thus shortening the overall pipeline execution time.

[0037] In another embodiment of this application, a canary deployment process based on consistent hashing is introduced during the deployment of compiled artifacts to the target runtime environment based on deployment target parameters and execution strategies. Specifically, when the deployment target parameters point to a group of target hosts, a virtual node on a consistent hash ring is assigned to each target host. The value of the virtual node is the hash value of the unique identifier of the target host. Compiled artifacts are associated with canary tags, which include a version number and a canary ratio. The hash ring interval corresponding to the current deployment task is calculated based on the canary ratio. Compiled artifacts are only transmitted and deployed to target hosts where the virtual node falls within the hash ring interval. After deployment, the routing table is dynamically updated, and the routing table records the current artifact version for each target host. Upon receiving a canary release confirmation instruction, the compiled artifacts are deployed to the remaining target hosts, completing the full deployment.

[0038] This application utilizes a shared pipeline library to uniformly orchestrate continuous integration and automated deployment processes. Through parameterized configuration and dynamic stage generation mechanisms, it achieves high reusability and flexible tailoring of pipeline processes. At the same time, by combining containerized build and automated deployment execution methods, it improves the stability and consistency of the build and release process, significantly reduces pipeline maintenance costs, and has good engineering practical value.

[0039] This application sets up different container environments for different build or compilation stages, so that each build stage executes in an independent container environment. For projects that require Java builds, the pipeline calls the relevant logic of mvnBuild in the Maven container to complete code compilation and artifact generation; for projects that require front-end builds, the pipeline executes NPM build commands in the Node container to complete the front-end resource build. Different build tasks are isolated from each other to avoid build failures caused by differences in build environments.

[0040] This application decouples the build and deployment process logic from project configuration parameters by centrally encapsulating it within a shared pipeline library, significantly improving pipeline reusability and centralized management capabilities while reducing maintenance complexity. By driving pipeline execution through parameterization, the same pipeline process can flexibly adapt to different projects, vehicle platforms, and deployment environments, reducing repetitive configuration work and improving configuration consistency. Executing build tasks in a containerized build environment avoids the impact of differences in different build node environments on build results, improving the stability and repeatability of the build process. It achieves a complete closed loop from code acquisition, building, artifact generation, image building and pushing to automated deployment, reducing manual intervention and shortening software delivery cycles. It is suitable for continuous integration and automated deployment scenarios involving parallel development and delivery of multiple projects and environments in automotive enterprises, possessing strong engineering practicality and promotional value.

[0041] Corresponding to the above method, embodiments of this application also provide a software system deployment apparatus, such as... Figure 2 As shown, the device includes: The parsing unit 210 is used to parse the set of construction parameters of the software system to be deployed to obtain parameter characteristics; Matching unit 220 is used to match pipeline execution processes corresponding to parameter features from a pre-built shared pipeline library; Deployment unit 230 is used to automatically execute pipeline execution processes based on a set of build parameters to complete the automated deployment of the software system to be deployed.

[0042] The functions of each functional unit of the software system deployment device provided in the above embodiments of this application can be implemented through the above method steps. Therefore, the specific working process and beneficial effects of each unit in the software system deployment device provided in the embodiments of this application will not be repeated here.

[0043] This application also provides a deployment server, such as... Figure 3 As shown, it includes a processor 310 and a memory 320; Memory 320 is used to store the shared pipeline library; Processor 310 is used to execute instructions in memory 320 to perform the following steps: The set of construction parameters for the software system to be deployed is parsed to obtain parameter characteristics; Match pipeline execution processes corresponding to parameter characteristics from a pre-built shared pipeline library; Based on the set of construction parameters, the pipeline execution process is automatically executed to complete the automated deployment of the software system to be deployed.

[0044] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0045] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be 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, or discrete hardware components.

[0046] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 1 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0047] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0048] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0049] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0050] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0051] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0052] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of this application and its equivalents, then these modifications and variations are also intended to be included in the embodiments of this application.

Claims

1. A method for deploying a software system, characterized in that, The method includes: The set of construction parameters for the software system to be deployed is parsed to obtain parameter characteristics; Match the pipeline execution process corresponding to the parameter characteristics from the pre-built shared pipeline library; Based on the set of construction parameters, the pipeline execution process is automatically executed to complete the automated deployment of the software system to be deployed.

2. The method as described in claim 1, characterized in that, The set of build parameters includes: build commands, build environment parameters, and deployment target parameters; The shared pipeline library includes a stage rule library and a strategy rule library; the stage rule library contains the execution order of different pipeline stages and multiple stage rules; each stage rule contains stage rule conditions and the corresponding pipeline stage; the strategy rule library includes multiple strategy rules; each strategy rule contains strategy rule conditions and the corresponding execution strategy.

3. The method as described in claim 2, characterized in that, The set of construction parameters for the software system to be deployed is parsed to obtain parameter characteristics, including: The build command, build environment parameters, and deployment target parameters are parsed to obtain the first parameter feature, the second parameter feature, and the third parameter feature.

4. The method as described in claim 3, characterized in that, From a pre-built shared pipeline library, match the pipeline execution process corresponding to the parameter characteristics, including: Based on whether the first parameter feature, the second parameter feature, and the third parameter feature satisfy the stage rule conditions of each stage rule in the shared pipeline library, the pipeline stage to be executed is determined. The execution strategy is determined based on whether the first parameter feature, the second parameter feature, and the third parameter feature satisfy the policy rule conditions of each policy rule in the shared pipeline library. Based on the execution strategy, the execution order of the different pipeline stages, and the pipeline stages to be executed, a pipeline execution flow is generated.

5. The method as described in claim 2, characterized in that, The set of build parameters also includes: code repository address and code branch parameters; Based on the set of construction parameters, the pipeline execution process is automatically executed to complete the automated deployment of the software system to be deployed, including: Based on the code repository address and the code branch parameters, obtain the source code from the deployment server; Based on the construction environment parameters, determine the container instance corresponding to each pipeline stage to be executed in the pipeline execution process; Within a defined container instance, the build command is executed to compile the source code and generate a compiled artifact. Based on the deployment target parameters and the execution strategy in the pipeline execution process, the compiled artifact is deployed in the target runtime environment.

6. The method as described in claim 5, characterized in that, If the pipeline stage to be executed includes an image building stage, then after generating the compiled artifact, the method further includes: Based on the execution strategy in the pipeline execution process and the compiled artifact, an image file is generated; Based on the deployment target parameters and the execution strategy, the image file is deployed in the target runtime environment.

7. The method as described in claim 1, characterized in that, The method further includes: If the set of construction parameters fails the security check, the automated deployment of the software system to be deployed will be terminated.

8. A software system deployment apparatus, characterized in that, The device includes: The parsing unit is used to parse the set of build parameters of the software system to be deployed to obtain parameter characteristics; The matching unit is used to match the pipeline execution process corresponding to the parameter features from a pre-built shared pipeline library; The deployment unit is used to automatically execute the pipeline execution process based on the set of construction parameters to complete the automated deployment of the software system to be deployed.

9. A deployment server, characterized in that, The deployment server includes a memory and a processor, the memory storing a shared pipeline library, and the processor executing instructions in the memory to implement the method as described in any one of claims 1 to 7.

10. A vehicle controller, characterized in that, The vehicle controller is used to perform the method as described in any one of claims 1-7 to achieve automated deployment of the vehicle's software system on the vehicle controller.

Images