A method, apparatus, terminal device, and storage medium for publishing an application version.

Abstract

This application relates to the field of computer technology and provides a method, apparatus, terminal device, and storage medium for publishing application versions. Embodiments of this application achieve orderly execution of the publishing process by dynamically generating an executable process sequence with topological ordering; by parsing application version identifiers and service version data to generate a Kubernetes configuration set containing only state change services, it avoids processing all irrelevant service configuration files, reducing wasted computing resources and synchronization latency; by converting change files into key-value structures and persisting them to distributed storage, it leverages the high availability and reliability of distributed storage to ensure data security; and by monitoring key-value change events in distributed storage and synchronizing them to the Kubernetes cluster, it achieves real-time synchronization and rapid publishing of changes. This effectively solves the problems of traditional static script publishing processes, such as inability to dynamically respond to changes in business requirements, long publishing cycles, resource waste, and synchronization latency.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method, apparatus, terminal device and storage medium for publishing an application version. Background Technology

[0002] In the field of cloud-native application deployment, Kubernetes has become the de facto standard for container orchestration, enabling continuous delivery when combined with GitOps tools such as ArgoCD. This technology combination is widely used in industries such as internet, finance, and healthcare, especially in business scenarios requiring high availability and elastic scaling. With the popularization of microservice architecture, a single application typically contains dozens or even hundreds of independent services, making the version release process extremely complex.

[0003] However, in existing technologies, deployment processes are typically based on static scripts, which cannot dynamically respond to changes in business requirements. When adjustments to canary deployment strategies or co-location deployments are needed, developers must manually rewrite deployment scripts, leading to extended deployment cycles and severely slowing down business iteration. Furthermore, traditional solutions require the full generation of Kubernetes configuration description files for each deployment. Even for updates to a single service, hundreds of unrelated service YAML files must be reprocessed, resulting in significant waste of computing resources and synchronization delays. Summary of the Invention

[0004] In view of this, embodiments of this application provide an application version publishing method, apparatus, terminal device, and storage medium, which can solve the problems in related technologies where application version publishing cannot dynamically respond to changes in business needs, wastes computing resources, and causes synchronization delays.

[0005] In a first aspect, embodiments of this application provide a method for publishing an application version, including:

[0006] Receive the instruction to create an application version and generate an executable process sequence with topological sorting based on the application version instruction;

[0007] Execute the executable process sequence and trigger events. When the executable process sequence completion event is detected, parse the application version identifier and service version data in the executable process sequence.

[0008] Generate a Kubernetes configuration set that contains only state change services based on the application version identifier and service version data;

[0009] Write the Kubernetes configuration set to a disk file to obtain the change file, and convert the change file into a key-value structure and persist it to distributed storage;

[0010] Listen for key-value change events in distributed storage, extract file paths and content from the event payload, and synchronize the changed files to the Kubernetes cluster;

[0011] Once synchronization is successful, the application version release is complete.

[0012] Secondly, embodiments of this application provide an application version publishing device, including:

[0013] The receiving module is used to receive the application version creation instruction and generate an executable process sequence of topological sorting based on the application version instruction.

[0014] The parsing module is used to execute the executable process sequence and trigger events. When the executable process sequence completion event is detected, the application version identifier and service version data in the executable process sequence are parsed.

[0015] The generation module is used to generate a Kubernetes configuration set that contains only state change services, based on the application version identifier and service version data.

[0016] The transformation module is used to write Kubernetes configuration sets to disk files, obtain change files, and convert the change files into key-value structures and persist them to distributed storage;

[0017] The listening module is used to listen for key-value change events in distributed storage, extract file paths and content from the event payload, and synchronize the changed files to the Kubernetes cluster.

[0018] The completion module is used to release the application version after successful synchronization.

[0019] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described application version publishing method.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described application version publishing method.

[0021] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the aforementioned application version publishing method.

[0022] The beneficial effects of this application's embodiments compared to existing technologies are as follows: This application's embodiments achieve orderly execution of the release process by dynamically generating an executable process sequence with topological sorting; by parsing application version identifiers and service version data to generate a Kubernetes configuration set containing only state change services, it avoids processing all irrelevant service configuration files, reducing wasted computing resources and synchronization latency; by converting change files into key-value structures and persisting them to distributed storage, it leverages the high availability and reliability of distributed storage to ensure data security; and by monitoring key-value change events in distributed storage and synchronizing them to the Kubernetes cluster, it achieves real-time synchronization and rapid release of changes. These steps work together to effectively solve the problems of traditional static script release processes, such as inability to dynamically respond to changes in business requirements, long release cycles, resource waste, and synchronization latency, significantly improving the speed of business iteration and the efficiency and reliability of application version releases. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram illustrating the implementation process of the application version publishing method provided in this embodiment.

[0025] Figure 2 This is a schematic diagram of the application version publishing method apparatus provided in the embodiments of this application.

[0026] Figure 3 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are protected by this application.

[0028] It should be noted that the terms "comprising," "including," and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application, are intended to cover non-exclusive inclusion. For example, a process, method, terminal, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Terms such as "first" and "second" in the claims, specification, and accompanying drawings of this application, as well as relational terms, are used merely to distinguish one entity / operation / object from another entity / operation / object, and do not necessarily require or imply any such immediate relationship or order between these entities / operations / objects.

[0029] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0030] In the field of cloud-native application deployment, Kubernetes has become the de facto standard for container orchestration, enabling continuous delivery when combined with GitOps tools such as ArgoCD. This technology combination is widely used in industries such as internet, finance, and healthcare, especially in business scenarios requiring high availability and elastic scaling. With the popularization of microservice architecture, a single application typically contains dozens or even hundreds of independent services, making the version release process extremely complex.

[0031] However, in existing technologies, deployment processes are typically based on static scripts, which cannot dynamically respond to changes in business requirements. When adjustments to canary deployment strategies or co-location deployments are needed, developers must manually rewrite deployment scripts, leading to extended deployment cycles and severely slowing down business iteration. Furthermore, traditional solutions require the full generation of Kubernetes configuration description files for each deployment. Even for updates to a single service, hundreds of unrelated service YAML files must be reprocessed, resulting in significant waste of computing resources and synchronization delays.

[0032] In view of this, the embodiments of this application achieve orderly execution of the release process by dynamically generating an executable process sequence with topological ordering; by parsing application version identifiers and service version data to generate a Kubernetes configuration set containing only state change services, it avoids processing all irrelevant service configuration files, reducing wasted computing resources and synchronization latency; by converting change files into key-value structures and persisting them to distributed storage, the high availability and reliability of distributed storage ensure data security; and by monitoring key-value change events in distributed storage and synchronizing them to the Kubernetes cluster, it achieves real-time synchronization and rapid release of changes. These steps work together to effectively solve the problems of traditional static script release processes, such as inability to dynamically respond to changes in business requirements, long release cycles, resource waste, and synchronization latency, significantly improving the speed of business iteration and the efficiency and reliability of application version releases.

[0033] To illustrate the technical solution of this application, specific embodiments are described below.

[0034] Figure 1 This illustration shows a flowchart of an application version publishing method provided in an embodiment of this application. This method can be applied to terminal devices. Terminal devices can be mobile phones, tablets, laptops, ultra-mobile personal computers (UMPCs), netbooks, etc.

[0035] Specifically, the method for releasing the above application version may include the following steps S101 to S106.

[0036] Step S101: Receive the application version creation instruction and generate an executable process sequence for topology sorting based on the application version instruction.

[0037] In some specific implementations, the executable process sequence for generating topological sorting based on the application version instructions may specifically include steps S401 to S403.

[0038] Step S401: Parse the target application name, version number, and service dependencies from the application version instruction.

[0039] The application version directive can be a user-initiated command to create an application version, which may include application version-related configuration information and operational requirements. The target application name can be the specific application name specified in the version directive for which the version needs to be released, used to uniquely identify the target application. The version number can be the specific identifier for this application version defined in the application version directive, used to distinguish different versions of the application. Service dependencies can be the dependency relationships between various services in the application version, describing the order and dependency conditions between services.

[0040] In the embodiments of this application, the application version instruction is a request submitted by the user through a specific interface or API to create an application version, which includes key information such as the target application name, version number, and service dependencies. The terminal device can parse this instruction to extract these three core elements, thereby providing basic information for the release of the target application version and providing necessary data support for subsequent construction of a directed graph and generation of an executable sequence, ensuring that the release process is targeted at the correct application version and services that match the actual dependencies.

[0041] Step S402: Construct a directed graph based on service dependencies.

[0042] A directed graph is a graphical structure consisting of nodes (services) and directed edges (service dependencies), used to visually represent the dependencies between services.

[0043] In the embodiments of this application, the terminal device can use the parsed service dependency relationships as a basis, treating each service as a node in a directed graph, and the dependency relationships between services as directed edges (the direction represents the dependency order, i.e., the dependent service points to the service that depends on it), thereby transforming the abstract service dependency relationships into a concrete graphical structure, intuitively displaying the dependency relationships between services. By visualizing the service dependency relationships, a clear graphical basis is provided for subsequent topology sorting operations, facilitating accurate analysis of the dependency order between services.

[0044] Step S403: Using a topological sorting algorithm, generate the executable process sequence based on the directed graph.

[0045] In the embodiments of this application, the terminal device can select a suitable topology sorting algorithm (such as the Kahn algorithm) to sort the constructed directed graph. By calculating the in-degree of each node (i.e., the number of nodes it depends on), nodes with an in-degree of 0 are sequentially added to the executable sequence, and the in-degree of the relevant nodes is updated, until all nodes are added to the sequence. This ultimately generates an ordered executable process sequence, thereby clarifying the order of service releases, ensuring that the order of service releases conforms to the actual dependencies, avoiding release failures due to unmet dependencies, and providing orderly guidance for subsequent execution operations.

[0046] This application's implementation method achieves dynamic and precise control over the service release order by accurately parsing key information from application version instructions, constructing a directed graph of service dependencies, and generating an ordered executable sequence using a topological sorting algorithm. Compared to traditional static scripts where the dependency order is fixed and cannot adapt to dependency changes, this application's implementation method can automatically generate the correct release order based on the actual service dependencies, avoiding manual script modifications due to dependency adjustments and improving the flexibility and automation of the release process. Simultaneously, the ordered executable sequence ensures the correctness of service releases, reduces release failures caused by incorrect ordering, thereby accelerating application version releases and improving business iteration efficiency.

[0047] Step S102: Execute the executable process sequence and trigger an event. When the executable process sequence completion event is detected, parse the application version identifier and service version data in the executable process sequence.

[0048] The version identifier is a specific symbol or string used to uniquely identify an application version, and it is the core identifier connecting application version commands and corresponding version data. Service version data is used to record the specific version information of each service in the application version, including the service's functional characteristics, configuration parameters, etc., and is the key basis for generating Kubernetes configuration sets.

[0049] In some specific implementations, when an executable process sequence completion event is detected, parsing the application version identifier and service version data in the executable process sequence may specifically include steps S501 to S503.

[0050] Step S501: When the executable process sequence completion event is detected, extract the version identifier from the event.

[0051] In the embodiments of this application, the executable process sequence completion event is a notification event triggered after the executable process sequence is executed, and its event payload contains a version identifier associated with the sequence. The terminal device can set up an event listening mechanism (such as a message queue or event bus) to parse and extract the version identifier from the event payload when the event is detected, providing the necessary basis for subsequent querying of the corresponding service version data.

[0052] Step S502: Query the version database according to the version identifier to obtain all service version data of the corresponding version.

[0053] The version database is a pre-built database that stores application version information, and it establishes a mapping relationship between version identifiers and service version data.

[0054] In the embodiments of this application, the terminal device can use the extracted version identifier as a query condition to retrieve the database through a database query interface (such as SQL query or API call) to obtain all service version data corresponding to the version identifier, thereby accurately locating the service version information of the target application version and ensuring that the data parsed subsequently is consistent with the actual version.

[0055] Step S503: Parse the service version data to form a structured data packet.

[0056] Structured data packets are standardized data sets that parse the original service version data into a specific format (such as JSON or XML) to facilitate subsequent program processing and analysis.

[0057] In the embodiments of this application, the terminal device can parse the data through a data parsing module (such as a regular expression parser or a JSON parser), extract key fields (such as service name, version number, configuration parameters, etc.), and organize them into structured data packets according to a predefined format (such as a JSON object or an XML document), thereby converting the raw data into a standardized format that is easy for the program to process, providing a clear and easy-to-operate data foundation for the subsequent generation of Kubernetes configuration sets.

[0058] This application's implementation extracts version identifiers by monitoring the executable process sequence to ensure accurate version information acquisition; it retrieves corresponding service version data from the version database, avoiding the risks of manual input or incorrect association; and it parses the service version data to form structured data packets, improving data processability and the automation of subsequent processes. These steps work together to quickly and accurately obtain the service version information required for the application version, providing reliable data support for generating a Kubernetes configuration set containing only state-changing services. This avoids release delays caused by data acquisition errors or inefficient processing in traditional solutions, thereby improving the efficiency and accuracy of application version releases.

[0059] Step S103: Generate a Kubernetes configuration set containing only state change services based on the application version identifier and the service version data.

[0060] The Kubernetes configuration set is a collection of configuration files corresponding to all state-changing services. It contains only the configurations of services that need to be updated and is the core configuration data required for application version release.

[0061] In some specific embodiments of this application, generating a Kubernetes configuration set containing only state change services based on the application version identifier and the service version data may specifically include steps S601 to S603.

[0062] Step S601: Filter out the status change services from the service version data.

[0063] Among them, the state change service is the service whose state (such as code version, configuration parameters, dependencies, etc.) has changed compared to the previous version of the application, and it is the core object that needs to be released and updated.

[0064] In the embodiments of this application, the terminal device can identify services whose status has changed by comparing them with the service version data of the previous version (such as comparing whether the version number has changed or whether the configuration parameters have been adjusted). These services are the status change services that need to be updated, thereby accurately locating the services that need to be updated, avoiding invalid processing of services that have not changed, and providing a basis for generating targeted configuration sets in the future.

[0065] Step S602: For each of the state change services, obtain the corresponding Kubernetes configuration template from the template library.

[0066] Among them, the Kubernetes configuration template can be a predefined basic file that conforms to the Kubernetes configuration specification, containing the general configuration structure required for service deployment (such as container images, resource limits, service exposure methods, etc.), and can generate an executable configuration file by injecting specific data.

[0067] In the embodiments of this application, the terminal device can search for and obtain the corresponding Kubernetes configuration template from the template library according to the type or functional characteristics of the state change service (such as by service name matching or tag filtering), thereby providing a standardized configuration foundation for each state change service, ensuring that the generated configuration file meets the Kubernetes specification requirements, and reducing repetitive configuration work through template reuse.

[0068] Step S603: Inject the service version data into the Kubernetes configuration template to generate a configuration file, and inject the application version identifier to obtain the Kubernetes configuration set.

[0069] In the embodiments of this application, the terminal device can replace the specific version data of the state change service (such as service name, container image version, resource request value, etc.) into the template variable to generate a specific configuration file; at the same time, the application version identifier is injected into the metadata part of the configuration file (such as tags or annotations) to achieve the association between version and configuration. This operation is repeated for all state change services, and finally all the generated configuration files are collected into a Kubernetes configuration set, thereby transforming the abstract template into an executable configuration file, and realizing configuration version tracking through version identifiers, providing complete configuration data containing only the changed services for subsequent synchronization to the Kubernetes cluster.

[0070] This implementation avoids processing all irrelevant services by filtering state-changing services, reducing wasted computing resources. It provides a standardized configuration foundation through a template library, ensuring configuration standardization and consistency. By injecting service version data and application version identifiers, it generates a Kubernetes configuration set containing only changed services and establishes a link between versions and configurations. Compared to traditional solutions that require generating full configuration files for each release, this implementation significantly reduces the complexity and resource consumption of configuration generation. Furthermore, the injection of version identifiers facilitates subsequent version tracking and rollback, thereby improving the efficiency and accuracy of application version releases and accelerating business iteration.

[0071] Step S104: Write the Kubernetes configuration set to a disk file to obtain a change file, and convert the change file into a key-value structure and persist it to distributed storage.

[0072] The change file is a new configuration file obtained by replacing the target file with a temporary file, recording the configuration changes required for application version release. The key-value structure converts the file content into a data structure stored in key-value pairs, facilitating efficient querying and access in a distributed storage system. Distributed storage is a storage system composed of multiple independent storage nodes (such as etcd and Redis), possessing high availability, scalability, and data consistency, used for persistently storing the key-value structure data of the change file.

[0073] In some specific embodiments of this application, the above-mentioned writing of the Kubernetes configuration set to a disk file to obtain a change file, and converting the change file into a key-value structure and persisting it to distributed storage may specifically include steps S701 to S705.

[0074] Step S701: Write the Kubernetes configuration set to a temporary file.

[0075] In the embodiments of this application, the terminal device can write the configuration set content to a temporary file in a preset format (such as YAML format) through a file writing operation (such as using a file writing API of a programming language). This file serves as intermediate storage to avoid configuration errors caused by directly modifying the target file, thereby preserving the intermediate results of the configuration data and providing security for subsequent verification and replacement operations.

[0076] Step S702: Read the source file and calculate the hash value of the source file.

[0077] The source file is the Kubernetes configuration file corresponding to the previous version of the application. It is the configuration data that existed before this release and is used to verify the newly generated configuration data.

[0078] In the embodiments of this application, the terminal device can obtain the content of the source file through file reading operations (such as opening a file and reading its content), and then use a hash algorithm (such as MD5) to calculate the content of the source file to generate a unique hash value, thereby obtaining a unique identifier of the old configuration file, providing a basis for subsequent verification of the consistency between the new configuration file and the old configuration file.

[0079] Step S703: Verify based on the hash value.

[0080] In the embodiments of this application, after generating the hash value of the source file, the terminal device can perform the same hash calculation on the temporary file (containing new configuration data) to obtain the hash value of the temporary file, and then compare the hash value of the temporary file with the hash value of the source file. If they match, it indicates that the new configuration data is no different from the old configuration data (the same configuration may be generated repeatedly due to an error); if they do not match, it indicates that the new configuration data has been changed or is incorrect. This ensures that the newly generated configuration data is the expected changed content and avoids abnormal configuration data due to program errors or external interference.

[0081] Step S704: When the verification passes, replace the target file with the temporary file to obtain the modified file.

[0082] The target file is the Kubernetes configuration file that needs to be updated after the application version is released.

[0083] In the embodiments of this application, if the verification passes (the hash values ​​of the temporary file and the source file are inconsistent, and the expected changes are met), the terminal device can perform a file replacement operation: moving or copying the temporary file to the storage path of the target file, overwriting the original target file. After replacement, the target file becomes a change file containing new configuration data. This file records the specific configuration changes required for the application version release, ensuring that only verified and correct configuration data will be updated to the target file, thus avoiding release failures due to configuration errors.

[0084] Step S705: Convert the file content of the modified file into a key-value structure and persist the key-value structure to distributed storage.

[0085] In the embodiments of this application, the terminal device can first read the content of the modified file, convert it into a key-value structure (such as using the file path as the key and the file content as the value, or splitting it into key-value pairs according to the configuration field), and then persist the key-value structure data to the distributed storage system through the write interface of the distributed storage (such as the PUT operation of etcd), thereby storing the configuration data in an efficient and reliable manner, facilitating subsequent monitoring and synchronization operations, while using the high availability of distributed storage to ensure data security.

[0086] This application's implementation avoids the risk of directly modifying the target file by writing to a temporary file, ensures the consistency and correctness of configuration data through hash verification, achieves precise updates by generating a change file by replacing the target file, and improves data reliability and synchronization efficiency by converting to a key-value structure and persisting it to distributed storage. Compared to traditional solutions that directly modify configuration files and lack verification, this application's implementation significantly reduces the probability of release failures due to configuration errors. Simultaneously, distributed storage ensures high data availability, providing a reliable foundation for subsequent rapid synchronization to the Kubernetes cluster, thereby improving the stability and efficiency of application version releases.

[0087] Step S105: Listen for key-value change events in the distributed storage, extract the file path and content from the event payload, and synchronize the changed file to the Kubernetes cluster.

[0088] In some specific embodiments of this application, the above-mentioned synchronization of the application version and the target service version to the Kubernetes cluster may specifically include steps S801 to S803.

[0089] Step S801: Listen for key-value change events in the preset path.

[0090] Among them, the key-value change event of the preset path is a key-value change notification event triggered under a specific path pre-defined in the distributed storage system, focusing only on configuration change events related to application version release.

[0091] In the embodiments of this application, the terminal device can pre-set the listening path (such as / app-releases / config) in a distributed storage system (such as etcd) through a management interface or API, and then call the listening interface provided by the distributed storage (such as etcd's watch API) to subscribe to all key-value change events under that path, focusing on configuration change events directly related to application version release, avoiding listening to events on irrelevant paths, and improving listening efficiency and the targeting of data processing.

[0092] Step S802: When a new event is detected, extract the file path and content from the event payload.

[0093] The event payload is the specific data content carried by the key-value change event, which includes the file path (key) and file content (value) of the changed file. It is the core data source for synchronizing to the Kubernetes cluster and is used to convey specific information about the configuration change.

[0094] In the embodiments of this application, when the distributed storage system detects a new key-value change event under a preset path, the terminal device can trigger a preset event callback function; obtain the event payload (containing the changed key-value pair data) through the event object, where the key is the file path (e.g., / app-releases / config / service-a.yaml) and the value is the file content (configuration data in YAML format); extract key configuration change information from the event (the file path locates the target file, and the content is the specific configuration), and provide specific data support for subsequent synchronization operations.

[0095] Step S803: Using the file path as a parameter, the changed file is synchronized to the Kubernetes cluster.

[0096] In the embodiments of this application, the terminal device can use the extracted file path as an identifier to obtain the corresponding file content (specific configuration data of the changed file) through the read interface of distributed storage (such as etcd's get API); then call the API interface of the Kubernetes cluster (such as using the kubectl apply -f<file path> command or the client-go client library), take the file content as configuration input, and perform deployment operations (such as creating / updating Deployment, Service and other resources) to make the current state of the Kubernetes cluster consistent with the target state described in the changed file, thereby synchronizing the configuration changes in the distributed storage to the Kubernetes cluster in real time and completing the actual release of the application version.

[0097] This application's implementation accurately captures configuration changes related to application version releases by listening to key-value change events at preset paths, avoiding interference from irrelevant events. By extracting file paths and content from event payloads, it ensures the accuracy and integrity of synchronized data. By directly synchronizing file paths and content to the Kubernetes cluster, it achieves real-time application of configuration changes, avoiding release delays caused by manual or delayed synchronization in traditional solutions. Compared to traditional methods, this application's implementation significantly improves the automation and real-time performance of configuration synchronization, reduces human error, and leverages the reliability of distributed storage and the API capabilities of Kubernetes to ensure the stability and efficiency of the release process, thereby significantly improving the response speed and accuracy of application version releases.

[0098] Step S106: After successful synchronization, complete the application version release.

[0099] In the embodiments of this application, after the change files are synchronized to the Kubernetes cluster, the terminal device can confirm whether the synchronization operation was successful by querying the cluster status or receiving cluster feedback information. Once the synchronization is confirmed to be successful, it indicates that the application version has been deployed and released in the Kubernetes cluster as expected, and the entire release process is complete.

[0100] In some specific embodiments of this application, after successful synchronization and completion of application version release, the above method may further include steps S901 to S903.

[0101] Step S901: parse the deployment status data returned by the Kubernetes cluster, and extract the Pod startup status, service readiness probe results, and resource usage indicators of the application version instance.

[0102] In the embodiments of this application, after the Kubernetes cluster completes configuration synchronization, the terminal device can return deployment status data (JSON format) through an API interface (such as GET / api / v1 / namespaces / {namespace} / pods). This data includes the startup status of all Pods (such as the status.phase field), ready probe results (such as the status.containerStatuses[].ready field), and resource usage metrics (such as the status.usage field). By parsing this JSON data, the Pod startup status (whether it is Running or Ready), service ready probe results (whether all probes passed), and resource usage metrics (such as CPU and memory usage) of the target application version instance (matched by tag or name) are extracted to verify whether the deployment is successful and ensure that the service instance has started correctly and can provide services.

[0103] Step S902: When all the Pods are in the ready state and the pass rate of the ready probe reaches 100%, the monitoring metric atomic process is triggered to continuously collect the service performance metrics of the application version.

[0104] In the embodiments of this application, the terminal device can determine, based on the extracted deployment status data, whether the startup status of all Pods is Ready and whether the service readiness probe pass rate is 100% (no failed probes). If the conditions are met, the terminal device calls the API of the monitoring system (such as Prometheus) or triggers a preset monitoring task (monitoring metric atomic process) to continuously collect service performance metrics of the application version (such as collecting the total number of requests via http_requests_total, the response latency via http_requests_duration_seconds, and the number of failed requests via http_requests_failed_total), thereby ensuring service health before starting performance monitoring and providing a data foundation for subsequent fault detection.

[0105] Step S903: If the error rate exceeds the threshold within the preset time window, the traffic weight of the target service version is adjusted to 0%, and the abnormal application version is marked as obsolete. The historical version rollback atomic process is triggered, and the key-value data of the previous stable version is retrieved from the distributed storage and resynchronized to the cluster.

[0106] In the embodiments of this application, within a preset time window (e.g., 5 minutes), the terminal device can calculate the error rate (error rate = number of error requests / total number of requests × 100%) based on continuously collected service performance metrics (e.g., number of erroneous requests / total number of requests). If the error rate exceeds a preset threshold (e.g., 5%), the traffic weight of the target service version is adjusted to 0% (i.e., new traffic is prohibited) through a traffic management tool (e.g., Istio's VirtualService); simultaneously, the application version is marked as "deprecated" in the version management system (i.e., subsequent operations are prohibited); then, a historical version rollback atomic process is triggered, retrieving the key-value data of the previous stable version through the distributed storage read interface (e.g., etcd's get API), and calling the Kubernetes API (e.g., kubectl apply) to resynchronize the key-value data to the cluster, completing the version rollback. This achieves automatic fault detection, traffic isolation, and rapid rollback, reducing the impact of faults on business operations.

[0107] This application's implementation verifies service health by parsing deployment status data, ensuring service availability after release. It continuously collects performance data through atomic processes that trigger monitoring metrics, providing real-time data for fault detection. By using preset time windows and error rate thresholds to accurately identify anomalies, it automatically adjusts traffic weights, marks obsolete states, and triggers historical version rollbacks, achieving rapid fault isolation and automatic recovery. Compared to traditional solutions that rely on manual verification and rollback, this application's implementation significantly improves post-release fault response speed, reduces business interruption time, and reduces human error through automated processes, ensuring high availability and stability of application version releases.

[0108] Figure 2 This illustration shows a structural diagram of an application version publishing device according to an embodiment of this application. The application version publishing device 2 can be configured on a terminal device. Specifically, the application version publishing device 2 may include:

[0109] The receiving module 201 is used to receive an application version creation instruction and generate an executable process sequence of topological sorting according to the application version instruction.

[0110] The parsing module 202 is used to execute the executable process sequence and trigger events. When the executable process sequence completion event is detected, the application version identifier and service version data in the executable process sequence are parsed.

[0111] The generation module 203 is used to generate a Kubernetes configuration set that contains only state change services based on the application version identifier and the service version data.

[0112] The conversion module 204 is used to write the Kubernetes configuration set to a disk file to obtain a change file, and convert the change file into a key-value structure and persist it to distributed storage;

[0113] The listening module 205 is used to listen for key-value change events in distributed storage, extract file paths and contents from the event payload, and synchronize the changed files to the Kubernetes cluster.

[0114] Module 206 is used to complete the application version release after successful synchronization.

[0115] The beneficial effects of this application's embodiments compared to existing technologies are as follows: This application's embodiments achieve orderly execution of the release process by dynamically generating an executable process sequence with topological sorting; by parsing application version identifiers and service version data to generate a Kubernetes configuration set containing only state change services, it avoids processing all irrelevant service configuration files, reducing wasted computing resources and synchronization latency; by converting change files into key-value structures and persisting them to distributed storage, it leverages the high availability and reliability of distributed storage to ensure data security; and by monitoring key-value change events in distributed storage and synchronizing them to the Kubernetes cluster, it achieves real-time synchronization and rapid release of changes. These steps work together to effectively solve the problems of traditional static script release processes, such as inability to dynamically respond to changes in business requirements, long release cycles, resource waste, and synchronization latency, significantly improving the speed of business iteration and the efficiency and reliability of application version releases.

[0116] In some embodiments of this application, the receiving module 201 is further configured to:

[0117] The target application name, version number, and service dependencies are parsed from the application version instructions;

[0118] Construct a directed graph based on service dependencies;

[0119] The executable process sequence is generated based on the directed graph using a topological sorting algorithm.

[0120] In some embodiments of this application, the parsing module 202 is further configured to:

[0121] When an executable process sequence completion event is detected, extract the version identifier from the event;

[0122] Query the version database based on the version identifier to obtain all service version data for the corresponding version;

[0123] The service version data is parsed to form a structured data packet.

[0124] In some embodiments of this application, the generation module 203 is further configured to:

[0125] Filter out the status change services from the service version data;

[0126] For each of the aforementioned state change services, obtain the corresponding Kubernetes configuration template from the template library;

[0127] The service version data is injected into the Kubernetes configuration template to generate a configuration file, and the application version identifier is injected to obtain the Kubernetes configuration set.

[0128] In some embodiments of this application, the conversion module 204 is further configured to:

[0129] Write the Kubernetes configuration set to a temporary file;

[0130] Read the source file and calculate its hash value;

[0131] Verification is performed based on the hash value;

[0132] When the verification passes, the target file is replaced with the temporary file to obtain the modified file;

[0133] The file content of the modified file is converted into a key-value structure, and the key-value structure is persisted to distributed storage.

[0134] In some embodiments of this application, the monitoring module 205 is further configured to:

[0135] Listen for key-value change events at a preset path;

[0136] When a new event is detected, extract the file path and content from the event payload;

[0137] Using the file path as a parameter, the changed file is synchronized to the Kubernetes cluster.

[0138] In some embodiments of this application, the application version publishing device 2 further includes a rollback module for:

[0139] Parse the deployment status data returned by the Kubernetes cluster to extract the Pod startup status, service readiness probe results, and resource usage metrics of the application version instance;

[0140] When all the Pods are in the ready state and the pass rate of the ready probe reaches 100%, the monitoring metric atomic process is triggered to continuously collect the service performance metrics of the application version.

[0141] If the error rate exceeds the threshold within the preset time window, the traffic weight of the target service version will be adjusted to 0%, and the abnormal application version will be marked as obsolete. This will trigger the historical version rollback atomic process, retrieving the key-value data of the previous stable version from the distributed storage and resynchronizing it to the cluster.

[0142] like Figure 3 The diagram shown is a schematic of a terminal device provided in an embodiment of this application. The terminal device 3 may include: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301, such as an application version publishing program. When the processor 301 executes the computer program 303, it implements the steps in the above-described application version publishing embodiments, for example... Figure 1 Steps S101 to S106 are shown.

[0143] A computer program can be divided into one or more modules / units. One or more modules / units are stored in memory 302 and executed by processor 301 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in a terminal device.

[0144] The terminal device may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of a terminal device and does not constitute a limitation on the terminal device. It may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, a terminal device may also include input / output devices, network access devices, buses, etc.

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

[0146] The memory 302 can be an internal storage unit of the terminal device, such as the hard drive or RAM of the terminal device. The memory 302 can also be an external storage device of the terminal device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 302 can include both internal and external storage units of the terminal device. The memory 302 is used to store computer programs and other programs and data required by the terminal device. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0147] It should be noted that, for the sake of convenience and brevity, the structure of the terminal device described above can also be referred to the specific description of the structure in the method embodiment, which will not be repeated here.

[0148] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0149] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described application version release method.

[0150] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps in the above-described application version release method.

[0151] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0152] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for various specific applications, but such implementations should not be considered beyond the scope of this application.

[0153] In the embodiments provided in this application, it should be understood that the disclosed apparatus / terminal devices and methods can be implemented in other ways. For example, the apparatus / terminal device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0154] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0156] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0157] The embodiments described above are merely illustrative of the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for releasing an application version, characterized in that, include: Receive an instruction to create an application version, and generate an executable process sequence for topological sorting based on the application version instruction; Execute the executable process sequence and trigger events. When the executable process sequence completion event is detected, parse the application version identifier and service version data in the executable process sequence. Based on the application version identifier and the service version data, generate a Kubernetes configuration set that contains only state change services; The Kubernetes configuration set is written to a disk file to obtain a change file, which is then converted into a key-value structure and persisted to distributed storage. Listen for key-value change events in distributed storage, extract the file path and content from the event payload, and synchronize the changed file to the Kubernetes cluster; Once synchronization is successful, the application version release is complete. The step of generating the executable process sequence for topology sorting based on the application version instructions includes: The target application name, version number, and service dependencies are parsed from the application version instructions; Construct a directed graph based on service dependencies; The executable process sequence is generated based on the directed graph using a topological sorting algorithm.

2. The application version release method as described in claim 1, characterized in that, When an executable process sequence completion event is detected, the application version identifier and service version data in the executable process sequence are parsed, including: When an executable process sequence completion event is detected, extract the version identifier from the event; Query the version database based on the version identifier to obtain all service version data for the corresponding version; The service version data is parsed to form a structured data packet.

3. The application version release method as described in claim 1, characterized in that, The step of generating a Kubernetes configuration set containing only state change services based on the application version identifier and the service version data includes: Filter out the status change services from the service version data; For each of the aforementioned state change services, obtain the corresponding Kubernetes configuration template from the template library; The service version data is injected into the Kubernetes configuration template to generate a configuration file, and the application version identifier is injected to obtain the Kubernetes configuration set.

4. The application version release method as described in claim 1, characterized in that, The step of writing the Kubernetes configuration set to a disk file to obtain a change file, and converting the change file into a key-value structure and persisting it to distributed storage includes: Write the Kubernetes configuration set to a temporary file; Read the source file and calculate its hash value; Verification is performed based on the hash value; When the verification passes, the target file is replaced with the temporary file to obtain the modified file; The file content of the modified file is converted into a key-value structure, and the key-value structure is persisted to distributed storage.

5. The application version release method as described in claim 1, characterized in that, The process of monitoring key-value change events in distributed storage, extracting file paths and content from event payloads, and synchronizing the changed files to the Kubernetes cluster includes: Listen for key-value change events at a preset path; When a new event is detected, extract the file path and content from the event payload; Using the file path as a parameter, the changed file is synchronized to the Kubernetes cluster.

6. The application version release method as described in claim 1, characterized in that, After successful synchronization and application version release, the following steps are also included: Parse the deployment status data returned by the Kubernetes cluster to extract the Pod startup status, service readiness probe results, and resource usage metrics of the application version instance; When all the Pods are in the ready state and the pass rate of the ready probe reaches 100%, the monitoring metric atomic process is triggered to continuously collect the service performance metrics of the application version. If the error rate exceeds the threshold within the preset time window, the traffic weight of the target service version will be adjusted to 0%, and the abnormal application version will be marked as obsolete. This will trigger the historical version rollback atomic process, retrieving the key-value data of the previous stable version from the distributed storage and resynchronizing it to the cluster.

7. An application version publishing device, characterized in that, include: The receiving module is used to receive the application version creation instruction and generate an executable process sequence of topological sorting according to the application version instruction; The parsing module is used to execute the executable process sequence and trigger events. When the executable process sequence completion event is detected, the application version identifier and service version data in the executable process sequence are parsed. The generation module is used to generate a Kubernetes configuration set that contains only state change services based on the application version identifier and the service version data. The conversion module is used to write the Kubernetes configuration set to a disk file to obtain a change file, and convert the change file into a key-value structure and persist it to distributed storage; The listening module is used to listen for key-value change events in distributed storage, extract file paths and contents from the event payload, and synchronize the changed files to the Kubernetes cluster. The completion module is used to release the application version after successful synchronization. The receiving module is further configured to: The target application name, version number, and service dependencies are parsed from the application version instructions; Construct a directed graph based on service dependencies; The executable process sequence is generated based on the directed graph using a topological sorting algorithm.

8. A terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the application version publishing method as claimed in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the application version release method as described in any one of claims 1 to 6.

Images