A code automatic release method and computer program product based on unified adaptive scheduling

Abstract

The application discloses a code automatic release method based on unified adaptive scheduling and a computer program product. The method comprises the following steps: receiving and responding to a release request, generating a unique task identifier; determining a target adaptive plug-in matched with a release type, and converting the release request into an identifiable format corresponding to the target adaptive plug-in; after generating and storing a pre-release state snapshot according to target information, calling an external release platform interface through the target adaptive plug-in to execute a release operation corresponding to the release request, and obtaining an execution result; based on the unique task identifier, collecting log data generated in the execution process of the release task, and destroying temporary credentials corresponding to the release task after the release task ends. In the application, the problems of code redundancy, configuration confusion and cumbersome switching caused by the parallel operation of multiple release systems can be eliminated, and the overall scheme can meet the unified, safe, efficient and flexible automatic release requirements of enterprises.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of computer data processing technology, and specifically relate to a method for automated code deployment based on unified adaptation scheduling and a computer program product. Background Technology

[0002] In enterprise-level DevOps development systems, automated code deployment is a core component for achieving continuous integration and continuous deployment, directly impacting system delivery efficiency and online stability. Real-world enterprise development scenarios present three typical requirements: complex enterprise-level deployments, lightweight file exchange, and GitOps code-driven deployments. These requirements need to be compatible with mature operation and maintenance platforms such as Jenkins and GitLab CI / CD, as well as lightweight SSH / SFTP remote file operation modes. Existing deployment solutions are mostly platform-bound, failing to achieve unified scheduling and adaptation across multiple modes. Furthermore, they exhibit significant shortcomings in security management, deployment reliability, troubleshooting, and batch scaling, making it difficult to meet enterprises' needs for unified, secure, efficient, and flexible automated deployments. Summary of the Invention

[0003] The embodiments of this disclosure provide a method for automated code deployment and a computer program product based on unified adaptive scheduling, which aims to solve one or more of the above-mentioned problems and other potential problems.

[0004] According to a first aspect of this disclosure, a method for automated code deployment based on unified adaptive scheduling is provided. The method includes receiving and responding to a deployment request, generating a unique task identifier for the current deployment task, and the deployment request including deployment type and target information.

[0005] After the release request passes security authentication, the target adapter plugin that matches the release type is determined from multiple preset adapter plugins, and the release request is converted into a recognizable format corresponding to the target adapter plugin.

[0006] After generating and storing a pre-release state snapshot based on the target information, the target adaptation plugin calls the external release platform interface to execute the release operation corresponding to the release request and obtain the execution result.

[0007] In response to the failure of the execution result verification, a fault compensation operation is triggered for the release operation. The fault compensation operation includes retrying to call the target adaptation plugin or performing a rollback based on the pre-release state snapshot.

[0008] In response to successful execution result verification, log data generated during the execution of this release task is collected based on the unique task identifier, and the temporary credential corresponding to this release task is destroyed after the release task ends.

[0009] According to a second aspect of this disclosure, a code automation deployment device based on unified adaptive scheduling is provided. The device includes a request receiving module, which is configured to receive and respond to deployment requests and generate a unique task identifier for the current deployment task. The deployment request includes deployment type and target information.

[0010] The plugin determination module is configured to determine the target adapter plugin that matches the release type from multiple preset adapter plugins after the release request passes security authentication, and convert the release request into a recognizable format corresponding to the target adapter plugin.

[0011] The request execution module is configured to generate and store a pre-release state snapshot based on the target information. Then, it calls the external release platform interface through the target adaptation plugin to execute the release operation corresponding to the release request and obtain the execution result.

[0012] The first result processing module is configured to trigger a fault compensation operation for the release operation in response to the failure of the execution result verification. The fault compensation operation includes retrying to call the target adaptation plugin or performing a rollback based on the pre-release state snapshot.

[0013] The second result processing module is configured to respond to successful execution result verification by collecting log data generated during the execution of this release task based on the unique task identifier, and destroying the temporary credential corresponding to this release task after the release task ends.

[0014] According to a third aspect of this disclosure, an electronic device is provided, including one or more processors and a memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform a method provided according to a first scheme.

[0015] According to a fourth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method provided according to the first aspect.

[0016] The solution provided in the embodiments of this specification can uniformly schedule release requests of different release types within the same standardized process without the upper-layer business system needing to be aware of the differences in the underlying platform. It can achieve one-click switching between different mainstream release modes by matching target adaptation plugins according to the release type. It eliminates the need for repeated development, configuration, and maintenance for different platforms, and can cover the full-scenario release needs of enterprise-level complex deployments, lightweight file replacement, and GitOps code-driven releases. It eliminates the problems of code redundancy, configuration chaos, and cumbersome switching caused by multiple release systems running in parallel, significantly reducing R&D and operation and maintenance costs. Moreover, the plug-in architecture means that adding a new release platform only requires the development of a corresponding adaptation plugin without modifying the core code. Furthermore, after the release operation is executed, fault compensation operations or full-link log collection will be performed based on the verification results, forming a complete reliability closed loop and making the entire release process controllable. This effectively avoids the problems of file corruption, service interruption, and version inconsistency caused by no backup, no rollback for failures, and no retries for anomalies in existing technologies. It significantly improves the release success rate and production environment stability, and solves the pain points of scattered logs, fragmented status, and inability to quickly locate faults in existing technologies. It eliminates the need for manual login to multiple platforms to check one by one, greatly shortens the fault recovery time, improves system observability and operation and maintenance efficiency, and enables the solution to meet the enterprise's unified, secure, efficient, and flexible automated release needs. Attached Figure Description

[0017] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0018] Figure 1 This invention illustrates an architecture diagram of a code automation deployment system based on unified adaptation scheduling, representing some embodiments of the present disclosure.

[0019] Figure 2 A flowchart illustrating an automated code deployment method based on unified adaptation scheduling, according to some embodiments of this disclosure, is shown.

[0020] Figure 3 A flowchart illustrating a method for automated code deployment based on unified adaptation scheduling, according to further embodiments of this disclosure, is shown.

[0021] Figure 4 The diagram shows a structural schematic of a code automation deployment apparatus based on unified adaptation scheduling according to some embodiments of the present disclosure;

[0022] Figure 5 A schematic block diagram of an electronic device according to some embodiments of the present disclosure is shown. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0024] The terms “comprising” and “having”, and any variations thereof, in this specification, claims, and the foregoing drawings are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. Depending on the context, the word “if” as it applies herein may be interpreted as “when”, “in response to determination”, or “in response to detection”.

[0025] As mentioned earlier, in actual enterprise-level R&D and operations scenarios, due to the limitations of traditional deployment tools and their adaptability to different scenarios, most enterprises design and develop three completely isolated code deployment and execution systems to meet their diverse deployment needs. These three systems lack a unified scheduling framework, common component reuse, standardized interface specifications, and centralized configuration management, resulting in a siloed technical architecture. Specifically, this includes: developing a Java module to call the Jenkins API and deploy code using Java-based HTTP request tools; developing a Java module to call the GitLab API and deploy code using Java-based GitLab API calling tools, achieving automated deployment with strong binding to the code repository by creating code tags and triggering CI / CD pipelines; and developing an SFTP direct-connection server file replacement module using Java and the JSch component, directly establishing a remote connection via SSH / SFTP protocols to perform simplified deployment operations such as uploading and overwriting files on the server. All three release modules are independently developed, deployed, and maintained. Configuration files, authentication credentials, execution logic, status monitoring, and logging are completely separated, making unified management and flexible switching impossible.

[0026] Figure 1This diagram illustrates the architecture of a unified adaptive scheduling-based automated code deployment system 100 according to some embodiments of this disclosure. System 100 includes a user terminal 110, a deployment server 120, and multiple heterogeneous deployment execution platforms (e.g., Jenkins platform 130, GitLab platform 131, and SSH / SFTP protocol platform 132). The deployment server 120 communicates with the user terminal 110 and connects to each deployment execution platform through corresponding platform interfaces. The user terminal 110 initiates deployment requests to the deployment server 120; it can be a front-end management interface operated by operations personnel, a scheduled task, or a third-party system. Internally, the deployment server 120 can establish communication connections with the Jenkins platform 130 via HTTP / HTTPS, with the GitLab platform 131 via the GitLab REST API, and with the target server (i.e., the SSH / SFTP protocol platform 132) via the SSH / SFTP protocol. The Jenkins platform handles complex enterprise-level deployment processes, the GitLab platform triggers CI / CD pipelines associated with code repositories, and the SSH / SFTP protocol platform handles lightweight remote file replacement operations.

[0027] Based on the above architecture, after receiving a unified-format publishing request from user terminal 110, publishing server 120 first performs security authentication and parameter verification. Then, based on the publishing type field in the publishing request, it dynamically routes the request to the corresponding adapter plugin. This plugin converts the general request parameters into dedicated interface parameters recognizable by the target publishing platform, and then calls the corresponding external platform's interface to execute the actual publishing operation. Throughout the execution process, publishing server 120 uses a globally unique task identifier to correlate and aggregate execution logs scattered across multiple platforms, enabling full-chain tracking and observation of the publishing process. Simultaneously, it enforces pre-backup and fault rollback mechanisms before and after publishing to ensure transactional security of the publishing operation. After the publishing is completed and the result verification is finished, publishing server 120 can destroy all sensitive credentials used in this task, release system resources, and return a standardized publishing result to user terminal 110.

[0028] Figure 2The diagram illustrates a flowchart of an automated code deployment method 200 based on unified adaptation scheduling, representing some embodiments of this disclosure. Method 200 can be executed by a deployment server, which can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-mount server, or a workstation, mainframe, or other hardware device with strong computing power. Alternatively, it can be a server cluster composed of multiple servers, where each server is symmetrically arranged, meaning each server is functionally and hierarchically equivalent in the transaction chain, and each server can independently provide services. Providing services independently can be understood as requiring no additional server assistance.

[0029] like Figure 2 As shown, in method 200, step 202 can receive and respond to a release request, and generate a unique task identifier for this release task. The release request includes the release type and target information.

[0030] In this embodiment, operations and maintenance personnel can send release requests to the release server through the manual operation interface of the front-end management platform, the scheduled task scheduler, or API calls from third-party systems. The release request is the input instruction that triggers the entire automated release process and includes at least two core fields: release type and target information. The release type indicates which specific release execution method should be used for this release, including three types: the first type corresponds to the Jenkins platform interface call mode, the second type corresponds to the GitLab API pipeline trigger mode, and the third type corresponds to the remote file operation mode based on the SSH / SFTP protocol. By specifying different values ​​in this field, flexible switching between the three release modes can be achieved without modifying any core scheduling code. The target information indicates the target object of this release operation, and its specific content varies depending on the release type, including, for example, the associated system ID, deployment environment, version number, file path parameters, release strategy, and execution method. To accommodate the different needs of the three modes, the release request can be in JSON format, and the proprietary parameters required by different modes can be placed in optional extended fields, which are parsed by the corresponding adaptation plugins.

[0031] Upon receiving a release request, a globally unique task identifier will be generated for the release task corresponding to the request. This unique task identifier can be generated, for example, by combining a timestamp, a random number, and a machine identifier. This unique task identifier can be attached to the context object of the release task, allowing the corresponding data to be queried and tracked at different processing stages. This enables the fragmented information originally scattered across multiple systems and components to be linked into a complete end-to-end tracing chain.

[0032] In method 200, step 204 can determine the target adapter plugin that matches the release type from multiple preset adapter plugins after the release request has passed security authentication, and convert the release request into a recognizable format corresponding to the target adapter plugin.

[0033] In this embodiment, the publishing request first undergoes security authentication. This authentication can be achieved by dynamically reading corresponding sensitive credentials from the encryption configuration center based on the system identifier or user identifier carried in the publishing request, and then using these credentials to call the corresponding identity information for authentication. After successful authentication, a target adapter plugin matching the publishing type can be determined from multiple preset adapter plugins based on the publishing type field in the publishing request. Specifically, for example, a mapping table between publishing types and adapter plugin instances can be maintained. Upon receiving a publishing request, the corresponding adapter plugin instance is retrieved from the mapping table based on the value of the publishing type field, thus obtaining the target adapter plugin. Based on the target adapter plugin, the general publishing parameters passed from the outside in the publishing request can be converted into a dedicated parameter format (i.e., a recognizable format) that the publishing platform corresponding to the target adapter plugin can recognize. After this format conversion, the publishing request becomes a specific execution parameter object for the corresponding publishing platform, serving as input for subsequent calls to external publishing platform interfaces.

[0034] In method 200, after step 206 generates and stores a pre-release state snapshot based on the target information, the target adaptation plugin calls the external release platform interface to execute the release operation corresponding to the release request and obtain the execution result.

[0035] In this embodiment, before officially starting the corresponding release operation, a pre-release state snapshot is generated based on the target information to completely record the state information before release, providing reliable raw data for possible subsequent rollbacks. The generated pre-release state snapshot can be associated with a unique task identifier during storage for quick retrieval during rollback. Next, the target adapter plugin can call the corresponding external release platform interface based on the converted release request to complete the actual code release or file operations. After the external release platform interface call completes the release operation, the target adapter plugin receives the execution result returned by the platform. This execution result contains at least one execution status identifier to indicate whether the call was successfully triggered or completed on the platform side. For example, the Jenkins interface returns the Queue ID or build number; the GitLab interface returns the Pipeline ID; and the SFTP operation returns a boolean value indicating whether the file upload was successful, etc.

[0036] In method 200, step 208 may trigger a fault compensation operation for the release operation in response to the failure of the execution result verification. The fault compensation operation may include retrying to call the target adaptation plugin or performing a rollback based on the pre-release state snapshot.

[0037] In this embodiment, the execution result is also verified to determine whether the corresponding release operation was successfully executed, and a verification result of success or failure is returned. The verification content may vary depending on the release type. For example, for Jenkins mode, the verification content may include: polling to confirm whether the final status of the Jenkins build is "SUCCESS", whether the build log contains an exception stack trace, and whether the service on the target server has been successfully deployed and started. For GitLab mode, the verification content may include: confirming that the final status of the pipeline is "SUCCESS", whether the tags in the code repository have been correctly created, and whether the deployment task has been completed in the target environment. For SFTP mode, the verification content may include: confirming that the remote file exists in the target path, that the size of the remote file is consistent with the local source file, that the MD5 value of the remote file matches the local source file, and that the read / write permissions of the remote file are configured correctly. If the execution result verification fails, a fault compensation operation for the release operation will be triggered. Depending on the actual needs, fault compensation operations may include retrying to call the target adaptation plugin or performing a rollback based on a snapshot of the state before release. The former will retry calling and executing the release operation, while the latter mainly rolls back based on the snapshot to ensure restoration to the historical state and ensure that the system is available after the rollback.

[0038] In method 200, step 210 may respond to the successful verification of the execution result by collecting the log data generated during the execution of this release task based on the unique task identifier, and destroying the temporary credential corresponding to this release task after the release task ends.

[0039] In this embodiment, if the execution result verification is successful, it indicates that the corresponding release operation has been successfully executed, and the release task will enter the final stage. At this time, all log data generated during the execution of this release task can be collected and associated in a unified manner. The log data may include, but is not limited to: instruction reception log (recording the content of the original release request), security authentication log (recording the authentication process and result), backup log (recording the generation result of the state snapshot), release execution log (recording the process and return result of the adapter plugin calling the external interface), verification log (recording the execution result of each verification), retry log (if there are retries, recording the number of retries and the result of each retrieval), and rollback log (if there is a rollback, recording the detailed process of the rollback operation). These log entries will be associated and bound by a unique task identifier. After collection, a complete end-to-end tracking log can be formed, which is convenient for operation and maintenance personnel to query and retrieve later or to display the release progress in real time in the form of a visual timeline on the front-end management interface. In addition, temporary credentials generated during this release task will be destroyed, such as sensitive credentials stored in memory (e.g., Jenkins Token, GitLab Token, SSH password or private key), memory objects in the garbage collection mechanism, and resources in the thread pool, to ensure that sensitive information does not leave traces in the system and to prevent resource leakage from the source.

[0040] In one possible implementation, after receiving and responding to the release request and generating a unique task identifier for this release task, the method further includes:

[0041] Based on the system identifier in the release request, sensitive credentials are dynamically read from the encryption configuration center and stored in memory;

[0042] Security authentication is performed on the release request based on the user role that initiated the release request, the deployment environment specified in the release request, and the release type.

[0043] In this embodiment, sensitive credentials corresponding to the platform of the request type can be dynamically read from the encrypted configuration center based on the system identifier or user identifier carried in the release request. These credentials are only temporarily used in memory and are immediately cleared after execution, with no plaintext display, no local storage, and no hard-coded code throughout the process. The encrypted configuration center can be, for example, an enterprise-level configuration management tool such as Nacos or Apollo. After obtaining the sensitive credentials, a triple permission check is performed on three aspects: the user role initiating the release request, the deployment environment specified in the release request, and the release type. Role permission check can be performed by retrieving the user's role type (e.g., administrator, publisher, and observer) using the sensitive credentials to determine if they have the permission to perform the release operation. Environment permission check can be performed by retrieving environment permission information using the sensitive credentials to determine if the deployment environment specified in the release request (e.g., test environment, pre-production environment, production environment) is open to the current user. Type permission check can be performed by retrieving type permission information using the sensitive credentials to determine if the current user is authorized to use the release type specified in the request. Only after all three permission checks pass will the received release request be further processed.

[0044] In one possible implementation, a pre-release state snapshot is generated and stored based on the target information, including:

[0045] In response to a release type of Type 1, the currently running build number is recorded and stored as a snapshot of the pre-release state.

[0046] In response to the release type being type 2, record the latest tag and branch status in the current code repository and store the tag and branch status as a snapshot of the pre-release status;

[0047] In response to the release type being type 3, a backup directory is created on the target server, the original files to be operated on are moved to the backup directory, and the backup directory is stored as a snapshot of the state before release.

[0048] In this embodiment, the generation method for pre-release state snapshots differs for different release types. For the first type, the Jenkins API is called to obtain the number of the last build. This build number is used as the core data of the state snapshot, associated with a unique task identifier, and stored in the system database. The build number is recorded instead of other information because Jenkins build numbers are strictly incremental and unique. This number allows for precise location of the historical build version before release, enabling rapid rollback. For the second type, the GitLab API is called to obtain the latest commit hash value of the branch at the top of the release request, as well as the latest tag list of the current code repository. The branch name, the hash value of the latest commit representing the branch status, and the latest tag are then used as the core data of the state snapshot, associated with a unique task identifier, and stored in the system database. When a rollback is needed, the system can use this commit hash value to call the GitLab API to create a new rollback tag, or directly trigger the execution of the pipeline pointing to that commit. For the third type, a subdirectory, or backup directory, will be created under the target server's (i.e., the server performing this deployment) directory. The corresponding files will be moved to this backup directory, and the backup path will be recorded. This backup path will be used as the core data for the state snapshot, associated with a unique task identifier, and stored in the system database. This ensures that the file no longer exists in the original path after the backup is complete, thus avoiding file conflicts during subsequent deployments.

[0049] Figure 3 A flowchart illustrating a further embodiment of the code automation deployment method 300 based on unified adaptation scheduling of this disclosure is shown. Figure 3 As shown, in method 300, step 302 can receive and respond to a release request, and generate a unique task identifier for this release task. The release request includes the release type and target information.

[0050] In this embodiment, step 302 can be referred to step 202, and will not be repeated here.

[0051] In method 300, step 304 can determine the target adapter plugin that matches the release type from multiple preset adapter plugins after the release request has passed security authentication, and convert the release request into a recognizable format corresponding to the target adapter plugin.

[0052] In this embodiment, step 304 can be referred to step 204, and will not be repeated here.

[0053] In method 300, after step 306 generates and stores a pre-release state snapshot based on the target information, the external release platform interface is called through the target adaptation plugin.

[0054] In this embodiment, step 306 can be referred to step 206, and will not be repeated here.

[0055] In method 300, step 308 can generate an interface authentication header based on the authentication information in the release request, in response to the target adapter plugin being a Jenkins adapter plugin.

[0056] In this embodiment, for the Jenkins adapter plugin, authentication information, such as username and API token, can be read from the release request. The authentication information is concatenated into a string according to the specified format, and the string is encoded to generate an authentication header value to obtain the interface authentication header.

[0057] In method 300, step 310 can be based on the interface authentication header and concatenate a Uniform Resource Locator (URL) according to the Jenkins remote triggering specification. The URL includes the project identifier and the authentication token.

[0058] In this embodiment, after generating the interface authentication header, a Uniform Resource Locator (URL) is constructed according to the Jenkins remote triggering specification. As an example, the format for constructing a URL according to the Jenkins remote triggering specification can include the project name, build token, and parameter information. This data can be obtained from the target information of the release request, the system configuration of the release platform, etc. Based on the preset Jenkins remote triggering specification, the constructed URL simultaneously includes the project identifier (e.g., represented by the task name) and the authentication token (e.g., represented by the token parameter), ensuring that the request can be correctly recognized and authorized by Jenkins.

[0059] In method 300, step 312 can pass the deployment parameters of the release request to the Jenkins platform based on the Uniform Resource Locator to trigger the Jenkins build task and receive the build task identifier returned by the Jenkins platform.

[0060] In this embodiment, deployment parameters from the release request can be passed to the Jenkins platform in form based on the Uniform Resource Locator (URL) to trigger a build task. After the build task trigger request is sent, the Jenkins platform returns an HTTP response. The server receives and extracts the build task identifier (e.g., queue ID or subsequently generated build number) from this response as the basis for subsequent polling.

[0061] In method 300, step 314 can continuously poll the execution status of the Jenkins build task based on the build task identifier until the first status information representing the completion of the build task is obtained.

[0062] In this embodiment, the server can periodically call the Jenkins status query API based on the obtained build task identifier, and continuously call the interface at a preset polling interval (e.g., once every 5 seconds) to continuously poll the Jenkins build task. After each call, the execution status of this release operation (indicating success or failure) is determined until the first status information indicating the completion of the build task is obtained. After obtaining the first status information, that is, the information indicating successful execution, the release operation is considered to be completed, and the execution result can be obtained.

[0063] In method 300, step 316 may respond to the target adapter plugin being a GitLab adapter plugin by calling the GitLab repository interface, creating a version tag based on the branch specified in the release request, and receiving the tag information after successful creation.

[0064] In this embodiment, if the target adapter plugin is a GitLab adapter plugin, the GitLab repository interface is first called to transmit a release request. After receiving the release request, GitLab will create a version tag according to the branch specified in the release request, and return tag information including tag name, commit hash, creation time, etc. upon successful creation. This tag information will serve as the basis for triggering the pipeline subsequently.

[0065] In method 300, step 318 can pass environment variables and deployment parameters based on tag information to trigger GitLab pipeline execution and receive the pipeline task identifier returned by GitLab pipeline.

[0066] In this embodiment, based on the commit indicated by the tag information, the corresponding GitLab pipeline trigger interface can be invoked, and the pre-set environment variables and deployment parameters can be passed as variables and parameters used during pipeline execution, thereby enabling GitLab to create a new pipeline execution instance. The GitLab pipeline will also return a JSON response containing pipeline details, including a pipeline task identifier, as the basis for subsequent polling and log retrieval.

[0067] In method 300, step 320 can continuously poll the execution status of the GitLab pipeline based on the pipeline task identifier until a second status information representing the completion of pipeline execution is obtained.

[0068] In this embodiment, similar to the Jenkins mode, the GitLab pipeline status query interface can be continuously called at a preset polling interval (e.g., once every 5 seconds) based on the pipeline task identifier to determine the execution status of the GitLab pipeline. Different execution statuses correspond to different status information. When the status information indicates an abnormal pipeline execution, the task execution log can be retrieved based on the pipeline task identifier for troubleshooting. When the second status information indicating the completion of pipeline execution is obtained, the final status will be recorded and the polling loop will exit.

[0069] In method 300, step 322 may, in response to the target adapter being an SFTP adapter, establish an SSH / SFTP connection with the target server based on the authentication information in the publishing request.

[0070] In this embodiment, if the target adapter plugin is an SFTP adapter plugin, an SSH / SFTP connection will be established with the target server (i.e., the server performing the publishing operation) via the JSch (Java Secure Channel) component, based on the authentication information (such as username, password, or private key) in the publishing request, and also in conjunction with the target server information (such as IP address and port number) in the publishing request. After the connection is successfully established, an object can be obtained, and all subsequent file operations can be completed through this object.

[0071] In method 300, step 324 can generate the target file to be published locally based on the file generation parameters in the publishing request after the SSH / SFTP connection is successfully established.

[0072] In this embodiment, the configuration file or resource file to be published is often not statically existing, but needs to be dynamically generated based on the parameters in the publishing request. Therefore, based on the locally stored template file and the file generation parameters in the publishing request, all placeholders in the template file are replaced with actual values ​​to generate a complete, directly deployable target file. After the target file is generated, it can be stored in the system's local temporary directory, and the filename can include a version number or timestamp to distinguish different versions.

[0073] In method 300, step 326 can use an SSH / SFTP connection to upload the target file to the target path of the target server to replace the original file in the target path.

[0074] In this embodiment, a target file stored locally can be uploaded to the target path on the target server via an SSH / SFTP connection, directly replacing the original file in the target path. During the upload process, the SFTP protocol can use a streaming method, with data being transmitted directly from the local file system to the target server via an encrypted SSH channel, eliminating the need to cache the entire file in memory and preventing memory overflow.

[0075] Furthermore, after the target file is uploaded, access permissions can be configured to ensure that only those with the appropriate permissions can read the target file. Integrity verification can also be performed on the target file with configured permissions to ensure that the file uploaded to the server is completely identical to the file to be published locally, eliminating the possibility of data corruption during network transmission. Integrity verification methods can include file size comparison, MD5 hash value comparison, etc.

[0076] In method 300, step 328 can obtain the execution result.

[0077] In this embodiment, step 328 can be referred to step 206, and will not be repeated here.

[0078] In method 300, step 330 may trigger a fault compensation operation for the release operation in response to the failure of the execution result verification. The fault compensation operation may include retrying to call the target adaptation plugin or performing a rollback based on the pre-release state snapshot.

[0079] In this embodiment, step 330 can be referred to step 208, and will not be repeated here.

[0080] In method 300, step 332 may respond to the successful verification of the execution result by collecting the log data generated during the execution of this release task based on the unique task identifier, and destroying the temporary credential corresponding to this release task after the release task ends.

[0081] In this embodiment, step 332 can be referred to step 210, and will not be repeated here.

[0082] In one possible implementation, triggering a fault compensation operation for the release operation includes:

[0083] Determine the exception type corresponding to the verification failure;

[0084] If the exception type is a preset retryable exception type and the current number of retries is less than the threshold, the target adapter plugin is invoked again.

[0085] If the exception type is not a preset retryable exception type or the current retry count reaches the threshold, the pre-release state snapshot is invoked to perform a rollback.

[0086] In this embodiment, the server first analyzes the specific reasons for the verification failure and categorizes the corresponding exception types into retryable and non-retryable exception types. Retryable exception types refer to those caused by temporary factors that have a high probability of success with retrying within a short period, such as network timeout exceptions and connection pool exhaustion exceptions. Non-retryable exception types refer to those caused by fundamental errors that cannot be resolved by retrying, such as parameter error exceptions and insufficient permissions exceptions. In addition, a retry counter (initially 0) is maintained for this release task, incrementing by 1 after each retry operation. If the exception type belongs to a preset retryable exception type and the current number of retries is less than the threshold, a retry operation will be performed, i.e., the target adaptation plugin will be called again to perform the release operation, and the retry counter will be incremented by 1. If the exception type does not belong to a preset retryable exception type or the current number of retries has reached the threshold, no further attempts will be made; instead, a rollback operation will be performed directly using the pre-release state snapshot. In this way, the deployment server can avoid wasting time and resources on meaningless retries, while ensuring that temporary failures have a chance to recover automatically through retries, thereby improving the overall deployment success rate. Specifically, the retry operation can be progressively increased according to an exponential backoff strategy based on the interval between two adjacent retries, to avoid putting excessive request pressure on the target deployment platform due to frequent retries.

[0087] In one possible implementation, the method further includes:

[0088] In response to a batch release request, the release operation is performed on each target node based on the scheduling strategy, and the execution results of each target node are summarized to generate a batch release report. The scheduling strategy includes a serial strategy or a parallel strategy.

[0089] In this embodiment, in actual enterprise deployment scenarios, a business system is often deployed on multiple server nodes (e.g., multiple data centers, multiple availability zones), or a single deployment requires updating multiple interdependent microservices simultaneously, necessitating batch deployment. Therefore, upon receiving a deployment request, it can be determined whether the request is a batch deployment request, for example, based on whether the deployment request targets multiple target nodes rather than just one. For batch deployment requests, the entire process from receiving the deployment request to collecting log data can be executed for each target node according to a pre-determined scheduling strategy. The execution results of each target node are then summarized to generate a batch deployment report. This report can include the total number of nodes, the number of successful nodes, the number of failed nodes, the number of rollback nodes, as well as the detailed execution status of each node and its corresponding unique task identifier. This allows operations personnel to quickly understand the overall situation of the batch deployment through the report and conduct targeted investigations on failed nodes.

[0090] The scheduling strategy can be either a serial strategy or a parallel strategy. A serial strategy involves processing target nodes sequentially, one after another, processing the next node only after the previous one has been successfully published and confirmed. A parallel strategy involves using a thread pool to process multiple target nodes simultaneously, with the publishing operations of multiple nodes executed concurrently.

[0091] Figure 4 The diagram illustrates the structure of a code automation deployment apparatus 400 based on unified adaptation scheduling according to some embodiments of this disclosure. The various embodiments in this specification are described in a progressive manner; similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments. Figure 4 As shown, the device 400 includes a request receiving module 401, which is configured to receive and respond to publishing requests, generate a unique task identifier for this publishing task, and the publishing request includes publishing type and target information;

[0092] The plugin determination module 402 is configured to determine the target adapter plugin that matches the release type from multiple preset adapter plugins after the release request passes security authentication, and convert the release request into a recognizable format corresponding to the target adapter plugin.

[0093] The request execution module 403 is configured to generate and store a pre-release state snapshot based on the target information, and then call the external release platform interface through the target adaptation plugin to execute the release operation corresponding to the release request and obtain the execution result.

[0094] The first result processing module 404 is configured to trigger a fault compensation operation for the release operation in response to the failure of the execution result verification. The fault compensation operation includes retrying to call the target adaptation plugin or performing a rollback based on the pre-release state snapshot.

[0095] The second result processing module 405 is configured to respond to successful execution result verification by collecting log data generated during the execution of this release task based on the unique task identifier, and destroying the temporary credential corresponding to this release task after the release task ends.

[0096] In one possible implementation, the request receiving module 401 is further configured to dynamically read sensitive credentials from the encryption configuration center based on the system identifier in the publishing request, and store the sensitive credentials in memory; and to perform security authentication on the publishing request based on the user role that initiated the publishing request, the deployment environment specified in the publishing request, and the publishing type.

[0097] In one possible implementation, the release type includes a first type for identifying Jenkins platform interface calls, a second type for identifying GitLab platform interface calls, and a third type for identifying remote file operations based on the SSH / SFTP protocol; the target information includes the associated system ID, deployment environment, version number, file path parameters, release strategy, and execution method; the preset adaptation plugins include a Jenkins adaptation plugin corresponding to the first type, a GitLab adaptation plugin corresponding to the second type, and an SFTP adaptation plugin corresponding to the third type.

[0098] In one possible implementation, the request execution module 403 is further configured to, in response to a release type of the first type, record the currently running build number and store the build number as a pre-release state snapshot; in response to a release type of the second type, record the latest tag and branch status in the current code repository and store the tag and branch status as a pre-release state snapshot; and in response to a release type of the third type, create a backup directory in the target server, move the original files to be operated to the backup directory, and store the backup directory as a pre-release state snapshot.

[0099] In one possible implementation, the request execution module 403 is further configured to respond to the target adapter plugin being a Jenkins adapter plugin, generate an interface authentication header based on the authentication information in the release request; based on the interface authentication header, concatenate a Uniform Resource Locator (URL) according to the Jenkins remote triggering specification, the URL including a project identifier and an authentication token; based on the URL, pass the deployment parameters of the release request to the Jenkins platform to trigger a Jenkins build task, and receive the build task identifier returned by the Jenkins platform; based on the build task identifier, continuously poll the execution status of the Jenkins build task until the first status information representing the completion of the build task is obtained.

[0100] In one possible implementation, the request execution module 403 is further configured to respond to the target adapter plugin being a GitLab adapter plugin by calling the GitLab repository interface, creating a version tag based on the branch specified in the release request, and receiving the tag information after successful creation; passing environment variables and deployment parameters based on the tag information to trigger the execution of the GitLab pipeline, and receiving the pipeline task identifier returned by the GitLab pipeline; and continuously polling the execution status of the GitLab pipeline based on the pipeline task identifier until obtaining the second status information indicating that the pipeline execution is complete.

[0101] In one possible implementation, the request execution module 403 is further configured to respond to the target adapter plugin as an SFTP adapter plugin, establish an SSH / SFTP connection with the target server based on the authentication information in the publishing request; after the SSH / SFTP connection is successfully established, generate the target file to be published locally based on the file generation parameters in the publishing request; and upload the target file to the target path of the target server through the SSH / SFTP connection to replace the original file in the target path.

[0102] In one possible implementation, the first result processing module 404 is further configured to determine the exception type corresponding to the verification failure; in response to the exception type being a preset retryable exception type and the current retry count being less than the threshold, the target adaptation plugin is invoked again; in response to the exception type not being a preset retryable exception type or the current retry count reaching the threshold, the pre-release state snapshot is invoked to perform a rollback.

[0103] In one possible implementation, the apparatus further includes a batch processing module configured to respond to a release request as a batch release request, perform release operations on each target node based on a scheduling strategy, and summarize the execution results of each target node to generate a batch release report. The scheduling strategy may include a serial strategy or a parallel strategy.

[0104] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this specification is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0105] Figure 5 A block diagram of an electronic device 500 that can implement various embodiments of the present disclosure is shown. For example... Figure 5 As shown, the electronic device 500 includes a processor 510, a disk drive 520, an input / output interface 530, a network interface 540, and a memory 550. The processor 510, disk drive 520, input / output interface 530, network interface 540, and memory 550 can communicate with each other via a communication bus 560.

[0106] The processor 510 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs in order to implement the technical solution provided in this application.

[0107] The memory 550 can be implemented in the form of ROM (Read Only Memory), RAM (Read Access Memory), static memory, dynamic storage devices, etc. The memory 550 can store the operating system 551 used to control the operation of the electronic device 500, and the basic input / output system (BIOS) 552 used to control the low-level operations of the electronic device 500. Additionally, it can store a web browser 553, a data storage management system 554, etc. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 550 and is called and executed by the processor 510.

[0108] Input / output interface 530 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, vibrators, indicator lights, etc.

[0109] Network interface 540 is used to connect a communication module (not shown in the figure) to enable communication and interaction between the device and other devices. The communication module can communicate via wired means (e.g., USB, Ethernet cable) or wireless means (e.g., mobile network, Wi-Fi, Bluetooth).

[0110] Bus 560 includes a pathway for transmitting information between various components of the device, such as processor 510, disk drive 520, input / output interface 530, network interface 540, and memory 550.

[0111] It should be noted that although the above-described device only shows the processor 510, disk drive 520, input / output interface 530, network interface 540, memory 550, bus 560, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the method of this application, and does not necessarily include all the components shown in the figures.

[0112] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0113] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Furthermore, although operations are depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0114] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for automated code deployment based on unified adaptive scheduling, characterized in that, The method includes: Receive and respond to a release request, and generate a unique task identifier for this release task. The release request includes the release type and target information. After the release request passes security authentication, a target adapter plugin matching the release type is determined from a plurality of preset adapter plugins, and the release request is converted into a recognizable format corresponding to the target adapter plugin. After generating and storing a pre-release state snapshot based on the target information, the external release platform interface is called through the target adaptation plugin to execute the release operation corresponding to the release request and obtain the execution result; In response to the failure of the execution result verification, a fault compensation operation is triggered for the release operation. The fault compensation operation includes retrying to call the target adaptation plugin or performing a rollback based on the pre-release state snapshot. In response to the successful verification of the execution result, the log data generated during the execution of this release task is collected based on the unique task identifier, and the temporary credential corresponding to this release task is destroyed after the release task is completed.

2. The method for automated code deployment based on unified adaptive scheduling according to claim 1, characterized in that, After receiving and responding to the release request and generating a unique task identifier for this release task, the process also includes: Based on the system identifier in the release request, sensitive credentials are dynamically read from the encryption configuration center and stored in memory; The release request is authenticated based on the user role that initiated the release request, the deployment environment specified in the release request, and the release type.

3. The method for automated code deployment based on unified adaptation scheduling according to claim 1, characterized in that, The release types include a first type for identifying Jenkins platform interface calls, a second type for identifying GitLab platform interface calls, and a third type for identifying remote file operations based on SSH / SFTP protocols; the target information includes associated system ID, deployment environment, version number, file path parameters, release strategy, and execution method; the preset adaptation plugins include a Jenkins adaptation plugin corresponding to the first type, a GitLab adaptation plugin corresponding to the second type, and an SFTP adaptation plugin corresponding to the third type.

4. The method for automated code deployment based on unified adaptive scheduling according to claim 3, characterized in that, The step of generating and storing a pre-release state snapshot based on the target information includes: In response to the release type being the first type, the currently running build number is recorded, and the build number is stored as a snapshot of the pre-release state. In response to the release type being the second type, the latest tag and branch status in the current code repository is recorded, and the tag and branch status is stored as a snapshot of the pre-release status; In response to the release type being the third type, a backup directory is created within the target server, the original files to be operated on are moved to the backup directory, and the backup directory is stored as a snapshot of the pre-release state.

5. The method for automated code deployment based on unified adaptive scheduling according to claim 3, characterized in that, The execution of the publishing operation corresponding to the publishing request includes: In response to the target adapter plugin being a Jenkins adapter plugin, an interface authentication header is generated based on the authentication information in the release request; Based on the interface authentication header, a Uniform Resource Locator (URL) is constructed according to the Jenkins remote triggering specification. The URL includes the project identifier and the authentication token. Based on the Uniform Resource Locator, the deployment parameters of the release request are passed to the Jenkins platform to trigger the Jenkins build task, and the build task identifier returned by the Jenkins platform is received. Based on the build task identifier, the execution status of the Jenkins build task is continuously polled until the first status information indicating the completion of the build task is obtained.

6. The method for automated code deployment based on unified adaptive scheduling according to claim 3, characterized in that, The execution of the publishing operation corresponding to the publishing request includes: In response to the target adapter plugin being a GitLab adapter plugin, the GitLab repository interface is called to create a version tag based on the branch specified in the release request, and the tag information after successful creation is received. Based on the tag information, environment variables and deployment parameters are passed to trigger the execution of the GitLab pipeline, and the pipeline task identifier returned by the GitLab pipeline is received. Based on the pipeline task identifier, the execution status of the GitLab pipeline is continuously polled until a second status information representing the completion of pipeline execution is obtained.

7. The method for automated code deployment based on unified adaptation scheduling according to claim 3, characterized in that, The execution of the publishing operation corresponding to the publishing request includes: In response to the target adapter being an SFTP adapter, an SSH / SFTP connection is established with the target server based on the authentication information in the publishing request. After the SSH / SFTP connection is successfully established, the target file to be published is generated locally according to the file generation parameters in the publishing request; The target file is uploaded to the target path of the target server via the SSH / SFTP connection to replace the original file in the target path.

8. The method for automated code deployment based on unified adaptation scheduling according to claim 1, characterized in that, The triggering of the fault compensation operation for the release operation includes: Determine the exception type corresponding to the verification failure; If the exception type belongs to a preset retryable exception type and the current number of retries is less than the threshold, the target adapter plugin is invoked again. In response to the exception type not belonging to the preset retryable exception type or the current retry count reaching the threshold, the pre-release state snapshot is invoked to perform a rollback.

9. The method for automated code deployment based on unified adaptation scheduling according to claim 1, characterized in that, The method further includes: In response to the release request being a batch release request, release operations are performed on each target node based on a scheduling strategy, and the execution results of each target node are summarized to generate a batch release report. The scheduling strategy includes a serial strategy or a parallel strategy.

10. A computer program product, characterized in that, The method includes a computer program that, when executed by a processor, implements a code automation deployment method based on a unified adaptive scheduling according to any one of claims 1-9.

Images