Application version release method and device, terminal equipment and storage medium

Abstract

The invention is suitable for the technical field of computers, and provides an application version release method and device, terminal equipment and a storage medium, according to the embodiment of the invention, an executable process sequence of topological sorting is dynamically generated, and orderly execution of a release process is achieved; the Kubernetes configuration set only containing the state change service is generated by analyzing the application version identifier and the service version data, so that the situation that unrelated service configuration files are fully processed is avoided, and computing resource waste and synchronization delay are reduced; the change file is converted into a key value structure and persisted to distributed storage, and the data security is guaranteed by using the high availability and reliability of the distributed storage; and monitoring a key value change event stored in a distributed manner and synchronizing the key value change event to the Kubernetes cluster, thereby realizing real-time synchronization and rapid release of the change. The problems that a traditional static script release process cannot dynamically respond to service demand changes, the release period is long, resources are wasted, and synchronization is delayed are effectively solved.

Description

Technical Field

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

[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 the internet, finance, and healthcare, particularly in business scenarios requiring high availability and elastic scalability. With the prevalence of microservices architecture, a single application often consists of dozens or even hundreds of independent services, making the version release process extremely complex.

[0003] However, existing technologies typically rely on static scripts to implement release processes, making them unable to dynamically adapt to changing business needs. When adjusting the grayscale strategy or canary release process, developers must manually rewrite deployment scripts, extending release cycles and significantly slowing down business iteration. Furthermore, traditional solutions require the full generation of Kubernetes configuration descriptors for each release. Even if only a single service is updated, hundreds of YAML files for unrelated services must be reprocessed, resulting in significant wasted computing resources and synchronization delays. Summary of the Invention

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

[0005] In a first aspect, an embodiment of the present application provides a method for publishing an application version, comprising: Receive an instruction to create an application version, and generate a topologically sorted executable process sequence according to the application version instruction; Execute the executable process sequence and trigger the event. When the executable process sequence completion event is monitored, parse the application version identifier and service version data in the executable process sequence. Generate a Kubernetes configuration set containing only services with changed status based on the application version identifier and service version data; Write the Kubernetes configuration set to a disk file, obtain the change file, convert the change file into a key-value structure, and persist it to distributed storage; Monitor key-value change events in distributed storage, extract file paths and contents from event payloads, and synchronize changed files to the Kubernetes cluster. When the synchronization is successful, the application version is released.

[0006] In a second aspect, an embodiment of the present application provides a device for publishing an application version, including: A receiving module, configured to receive an instruction to create an application version and generate a topologically sorted executable process sequence 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 monitored, the application version identifier and service version data in the executable process sequence are parsed; A generation module, which generates a Kubernetes configuration set containing only state-changed services based on the application version identifier and service version data; The conversion module is used to write the Kubernetes configuration set to a disk file, obtain the change file, convert the change file into a key-value structure, and persist it to distributed storage; The monitoring module is used to monitor key-value change events in distributed storage, extract file paths and contents from event payloads, and synchronize changed files to the Kubernetes cluster. The completion module is used to complete the application version release when the synchronization is successful.

[0007] In a third aspect, an embodiment of the present application provides a terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned method for publishing an application version when executing the computer program.

[0008] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of the above-mentioned application version publishing method.

[0009] In a fifth aspect, an embodiment of the present application provides a computer program product, which, when running on a terminal device, enables the terminal device to execute the above-mentioned method for publishing the application version.

[0010] The beneficial effects of the embodiments of the present application compared with the prior art are as follows: the embodiments of the present application achieve orderly execution of the release process by dynamically generating a topologically sorted executable process sequence; by parsing the application version identifier and service version data to generate a Kubernetes configuration set that only contains state change services, it avoids the full processing of irrelevant service configuration files, reduces computing resource waste and synchronization delays; converts the change file into a key-value structure and persists it to distributed storage, and ensures data security by utilizing the high availability and reliability of distributed storage; monitors the key-value change events of the distributed storage and synchronizes them to the Kubernetes cluster, achieving real-time synchronization and rapid release of changes. These steps work together to effectively solve the problems of the traditional static script release process's inability to dynamically respond to changes in business needs, long release cycles, resource waste and synchronization delays, and significantly improves the speed of business iteration and the efficiency and reliability of application version releases. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 This is a flowchart of the implementation of the method for publishing the application version provided in the embodiment of the present application.

[0013] Figure 2 It is a structural diagram of the device for publishing the application version provided in an embodiment of the present application.

[0014] Figure 3 It is a structural diagram of the terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0015] In order to make the purpose, technical solutions and advantages of this application more clear, the application is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without making any creative work are protected by this application.

[0016] It should be noted that the terms "include", "comprising" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. 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 that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices. In the claims, specification and drawings of this application, relational terms such as "first" and "second" are merely used to distinguish one entity / operation / object from another entity / operation / object, and do not necessarily require or imply any such real-time relationship or order between these entities / operations / objects.

[0017] References to "embodiments" herein mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0018] 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 the internet, finance, and healthcare, particularly in business scenarios requiring high availability and elastic scalability. With the prevalence of microservices architecture, a single application often consists of dozens or even hundreds of independent services, making the version release process extremely complex.

[0019] However, existing technologies typically rely on static scripts to implement release processes, making them unable to dynamically adapt to changing business needs. When adjusting the grayscale strategy or canary release process, developers must manually rewrite deployment scripts, extending release cycles and significantly slowing down business iteration. Furthermore, traditional solutions require the full generation of Kubernetes configuration descriptors for each release. Even if only a single service is updated, hundreds of YAML files for unrelated services must be reprocessed, resulting in significant wasted computing resources and synchronization delays.

[0020] In view of this, the embodiment of the present application realizes the orderly execution of the release process by dynamically generating a topologically sorted executable process sequence; generates a Kubernetes configuration set containing only state-changing services by parsing the application version identifier and service version data, thereby avoiding the full processing of irrelevant service configuration files, reducing the waste of computing resources and synchronization delays; converts the change file into a key-value structure and persists it to distributed storage, and ensures the security of the data by utilizing the high availability and reliability of distributed storage; monitors the key-value change events of the distributed storage and synchronizes them to the Kubernetes cluster, realizing real-time synchronization and rapid release of changes. These steps work together to effectively solve the problems of the traditional static script release process's inability to dynamically respond to changes in business needs, long release cycles, waste of resources, and synchronization delays, significantly improving the speed of business iteration and the efficiency and reliability of application version releases.

[0021] In order to illustrate the technical solution of the present application, specific embodiments are provided below.

[0022] Figure 1 The present invention provides a schematic diagram of a method for publishing an application version, which can be applied to a terminal device, such as a mobile phone, tablet computer, laptop computer, ultra-mobile personal computer (UMPC), or netbook.

[0023] Specifically, the above-mentioned method for publishing an application version may include the following steps S101 to S106.

[0024] Step S101 : receiving an instruction to create an application version, and generating a topologically sorted executable process sequence according to the application version instruction.

[0025] In some specific implementations, the above-mentioned generation of a topologically sorted executable process sequence according to the application version instruction may specifically include steps S401 to S403.

[0026] Step S401: parse the target application name, version number, and service dependency from the application version instruction.

[0027] The application version directive can be a user-initiated instruction for creating an application version and can include configuration information and operational requirements related to the application version. The target application name can be the specific application name specified in the version directive for the version to be released, uniquely identifying the target application. The version number can be the specific identifier of the application version defined in the application version directive, used to distinguish between different versions of the application. Service dependencies can be the dependency relationships between services in the application version, describing the order and dependency conditions between services.

[0028] In the implementation of this application, an application version instruction is a request to create an application version submitted by a user through a specific interface or interface. It contains key information such as the target application name, version number, and service dependencies. The terminal device can parse this instruction and extract these three core elements, thereby providing basic information for the release of the target application version. This provides the necessary data support for the subsequent construction of the directed graph and generation of the executable sequence, ensuring that the release process is carried out for the correct application version and services that meet the actual dependency relationships.

[0029] Step S402: construct a directed graph based on the service dependency relationship.

[0030] Among them, a directed graph is a graphical structure consisting of nodes (services) and directed edges (service dependencies), which is used to intuitively represent the dependencies between services.

[0031] In the implementation of this application, a terminal device can use the parsed service dependencies as a basis, treating each service as a node in a directed graph and the dependencies between services as directed edges (the direction indicates the dependency order, i.e., the dependent service points to the dependent service). This converts the abstract service dependency into a concrete graph structure, intuitively displaying the dependencies between services. By visualizing the service dependencies, a clear graphical basis is provided for subsequent topological sorting operations, facilitating accurate analysis of the dependency order between services.

[0032] Step S403: Generate the executable process sequence according to the directed graph using a topological sorting algorithm.

[0033] In the implementation of the present application, the terminal device can select an appropriate topological 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 other nodes it depends on), nodes with an in-degree of 0 are sequentially selected to be added to the executable sequence, and the in-degrees of related nodes are updated until all nodes are added to the sequence. Ultimately, an ordered sequence of executable processes is generated, thereby clarifying the order of service releases and ensuring that the order of service releases conforms to actual dependencies, avoiding release failures due to unmet dependencies and providing orderly guidance for subsequent execution operations.

[0034] The implementation method of the present application achieves dynamic and precise control over the order of service release by accurately parsing key information from application version instructions, constructing a directed graph of service dependencies, and using a topological sorting algorithm to generate an ordered executable sequence. Compared to traditional static scripts where the dependency order is fixed and cannot adapt to dependency changes, the implementation method of the present application can automatically generate the correct release order based on the actual service dependency relationship, avoiding the manual modification of the script due to dependency adjustments, and improving the flexibility and automation of the release process. At the same time, the ordered executable sequence ensures the correctness of service release, reduces release failures due to sequence errors, thereby speeding up the release of application versions and improving business iteration efficiency.

[0035] Step S102: executing the executable process sequence and triggering an event. When the executable process sequence completion event is monitored, parsing the application version identifier and service version data in the executable process sequence.

[0036] The version identifier is a specific symbol or string that uniquely identifies an application version. It serves as the core identifier connecting the application version directive with the corresponding version data. Service version data records the specific version information of each service in the application version. It contains service features, configuration parameters, and other information, and is the key basis for generating Kubernetes configuration sets.

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

[0038] Step S501: When an executable process sequence completion event is monitored, a version identifier in the event is extracted.

[0039] In the embodiments of this application, an executable process sequence completion event is a notification event triggered after the execution of an executable process sequence. Its event payload contains a version identifier associated with the sequence. Terminal devices can utilize an event monitoring mechanism (such as a message queue or event bus) to parse and extract the version identifier from the event payload upon detecting this event, providing the necessary information for subsequent queries of the corresponding service version data.

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

[0041] The version database is a pre-built database for storing application version information, in which a mapping relationship between version identifiers and service version data is established.

[0042] In an embodiment of the present application, the terminal device can use the extracted version identifier as a query condition, search the database through a database query interface (such as an SQL query or an API call), and 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 subsequently parsed data is consistent with the actual version.

[0043] Step S503: parse the service version data to form a structured data packet.

[0044] Among them, the structured data package is a standardized data set that parses the original service version data into a specific format (such as JSON, XML) to facilitate subsequent program processing and analysis.

[0045] In the implementation manner of the present application, the terminal device can parse the data through a data parsing module (such as regular expression parsing or 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 JSON object or XML document), thereby converting the original data into a standardized format that is easy for the program to process, providing a clearly structured and easy-to-operate data foundation for the subsequent generation of Kubernetes configuration sets.

[0046] The implementation method of the present application extracts the version identifier by monitoring the executable process sequence completion event, thereby ensuring the accurate acquisition of version information; obtains the corresponding service version data by querying the version database, thereby avoiding the risk of manual input or incorrect association; and improves the processability of the data and the automation of subsequent processes by parsing the service version data. 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 that only contains state change services, avoiding release delays caused by data acquisition errors or inefficient processing in traditional solutions, thereby improving the efficiency and accuracy of application version releases.

[0047] Step S103: Generate a Kubernetes configuration set that only includes the state-changed service based on the application version identifier and the service version data.

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

[0049] In some specific implementations of the present application, generating a Kubernetes configuration set including only state-changed services based on the application version identifier and the service version data may specifically include steps S601 to S603.

[0050] Step S601: Filter out status-changed services from the service version data.

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

[0052] In the implementation manner of the present application, the terminal device can identify services whose status has changed by comparing with the service version data of the previous version (such as comparing whether the version number has changed, whether the configuration parameters have been adjusted). These services are status-changed services that need to be updated, thereby accurately locating the services that need to be updated, avoiding invalid processing of unchanged services, and providing a basis for the subsequent generation of targeted configuration sets.

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

[0054] Among them, the Kubernetes configuration template can be a pre-defined basic file that complies with the Kubernetes configuration specifications, containing the common configuration structure required for service deployment (such as container images, resource restrictions, service exposure methods, etc.), and can generate an executable configuration file by injecting specific data.

[0055] In the implementation manner of the present application, the terminal device can search 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 through service name matching or label filtering), thereby providing a standardized configuration basis for each state change service, ensuring that the generated configuration file complies with the Kubernetes specification requirements, and reducing repeated configuration work through template reuse.

[0056] 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.

[0057] In the implementation of this application, the terminal device can replace the specific version data of the state-changing service (such as the service name, container image version, resource request value, etc.) with the template variable to generate a specific configuration file. At the same time, the application version identifier is injected into the metadata portion of the configuration file (such as a label or annotation) to associate the version with the configuration. This operation is repeated for all state-changing services, and ultimately all generated configuration files are aggregated into a Kubernetes configuration set, thereby converting the abstract template into an executable configuration file. The configuration version is tracked using the version identifier, providing complete configuration data that only contains the changed service for subsequent synchronization to the Kubernetes cluster.

[0058] The implementation method of the present application avoids the full processing of irrelevant services by screening status change services, reducing the waste of computing resources; provides a standardized configuration basis through the template library, ensuring the standardization and consistency of the configuration; generates a Kubernetes configuration set that only contains changed services by injecting service version data and application version identifiers, and realizes the association between version and configuration. Compared with the traditional solution that requires full generation of configuration files for each release, the implementation method of the present application significantly reduces the complexity and resource consumption of configuration generation. At the same time, through the injection of version identifiers, it facilitates subsequent version tracking and rollback, thereby improving the efficiency and accuracy of application version releases and accelerating business iteration.

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

[0060] The change file is a new configuration file created by replacing the target file with a temporary file. It records the configuration changes required for the application release. The key-value structure converts file contents into a data structure stored as key-value pairs, facilitating efficient querying and access within a distributed storage system. Distributed storage, consisting of multiple independent storage nodes (such as etcd and Redis), offers high availability, scalability, and data consistency, and is used to persistently store the key-value structured data of change files.

[0061] In some specific implementations of the present 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.

[0062] Step S701: Write the Kubernetes configuration set into a temporary file.

[0063] In an embodiment of the present application, the terminal device can write the configuration set content into 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 an intermediate storage to avoid configuration errors caused by directly modifying the target file, thereby retaining the intermediate results of the configuration data and providing security for subsequent verification and replacement operations.

[0064] Step S702: read the source file and calculate the hash value of the source file.

[0065] 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.

[0066] In an embodiment of the present application, the terminal device can obtain the contents of the source file through a file reading operation (such as opening a file and reading the contents), and then use a hash algorithm (such as MD5) to calculate the contents 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.

[0067] Step S703: perform verification based on the hash value.

[0068] In the implementation of the present application, after generating the hash value of the source file, the terminal device can perform the same hash calculation on the temporary file (containing the new configuration data) to obtain the hash value of the temporary file. The hash value of the temporary file is then compared with the hash value of the source file. If the two match, it indicates that the new configuration data is the same as the old configuration data (perhaps due to an error that caused the same configuration to be generated repeatedly). If they do not match, it indicates that the new configuration data has been changed or has an error. This ensures that the newly generated configuration data contains the expected changes and avoids configuration data anomalies caused by program errors or external interference.

[0069] Step S704: When the verification passes, the target file is replaced with the temporary file to obtain the changed file.

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

[0071] In the implementation of this application, if the verification passes (the hash values ​​of the temporary file and the source file are inconsistent and meet the expected changes), 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 the replacement, the target file becomes a change file containing the new configuration data. This file records the specific configuration changes required for the application version release, ensuring that only the correct configuration data that has been verified is updated to the target file, avoiding release failures due to configuration errors.

[0072] Step S705: convert the file content of the changed file into a key-value structure, and persist the key-value structure to distributed storage.

[0073] In an embodiment of the present application, the terminal device can first read the content of the change file and 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 use the write interface of the distributed storage (such as the PUT operation of etcd) to persist the key-value structure data in the distributed storage system, thereby storing the configuration data in an efficient and reliable manner, facilitating subsequent monitoring and synchronization operations, and at the same time utilizing the high availability of distributed storage to ensure data security.

[0074] The implementation method of this application avoids the risk of directly modifying the target file by writing a temporary file, ensures the consistency and correctness of the configuration data through hash verification, achieves accurate updates by replacing the target file to generate a change file, and improves data reliability and synchronization efficiency by converting it into a key-value structure and persisting it to distributed storage. Compared with the traditional solution of directly modifying the configuration file and lacking verification, the implementation method of this application significantly reduces the probability of release failure caused by configuration errors. At the same time, it ensures the high availability of data through distributed storage, providing a reliable foundation for subsequent rapid synchronization to the Kubernetes cluster, thereby improving the stability and efficiency of application version releases.

[0075] Step S105: monitor key-value change events in distributed storage, extract file paths and contents from event payloads, and synchronize the changed files to the Kubernetes cluster.

[0076] In some specific implementations of the present application, the above synchronization of the application version and the target service version to the Kubernetes cluster may specifically include steps S801 to S803.

[0077] Step S801: monitoring a key value change event of a preset path.

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

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

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

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

[0082] In an embodiment of the present 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 (including the changed key-value pair data) through the event object, where the key is the file path (such as / 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 (file path locates the target file, and the content is the specific configuration), and provide specific data support for subsequent synchronization operations.

[0083] Step S803: Use the file path as a parameter to synchronize the changed file to the Kubernetes cluster.

[0084] In an implementation manner of the present application, the terminal device can use the extracted file path as an identifier to obtain the corresponding file content (specific configuration data of the change file) through the read interface of the distributed storage (such as the get API of etcd); 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), use the file content as the 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 change 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.

[0085] The implementation method of the present application accurately captures configuration changes related to application version releases by monitoring key value change events of preset paths, avoiding interference from irrelevant events; by extracting file paths and contents from event payloads, the accuracy and integrity of synchronized data are ensured; by directly using file paths and contents to synchronize to the Kubernetes cluster, configuration changes are made effective in real time, avoiding the release lag problem caused by manual synchronization or delayed synchronization in traditional solutions. Compared with traditional methods, the implementation method of the present application significantly improves the automation and real-time performance of configuration synchronization, reduces human operational errors, and at the same time utilizes 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.

[0086] Step S106: When the synchronization is successful, the application version is released.

[0087] In the implementation of this application, after synchronizing the changed files 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 completed.

[0088] In some specific implementations of the present application, after the synchronization is successful and the application version is released, the method may further include steps S901 to S903.

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

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

[0091] Step S902: When the startup status of all the Pods is in the ready state and the readiness probe pass rate reaches 100%, the monitoring indicator atomic process is triggered to continuously collect the service performance indicators of the application version.

[0092] In the implementation of the present application, the terminal device can determine whether the startup status of all Pods is Ready (ready state) and whether the service readiness probe pass rate is 100% (no failed probes) based on the extracted deployment status data. If the conditions are met, the API of the monitoring system (such as Prometheus) is called or the preset monitoring task (monitoring indicator atomic process) is triggered to continuously collect service performance indicators of the application version (such as collecting the total number of requests through http_requests_total, collecting response delays through http_request_duration_seconds, and collecting the number of failed requests through http_requests_failed_total), so as to ensure the health of the service before starting performance monitoring, providing a data foundation for subsequent fault detection.

[0093] In step S903, if the error rate is detected to exceed 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 abandoned, triggering 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.

[0094] In an embodiment of the present 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 indicators (e.g., number of error 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). At the same time, the application version is marked as "obsolete" in the version management system (i.e., subsequent operations are prohibited). The atomic process of historical version rollback is then triggered, and the key-value data of the previous stable version is retrieved through a distributed storage read interface (e.g., etcd's get API). The Kubernetes API (e.g., kubectl apply) is called 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 the fault on the business.

[0095] The implementation method of this application verifies the health of the service by parsing the deployment status data to ensure the service availability after release; continuously collects performance data by triggering the monitoring indicator atomic process to provide a real-time basis for fault detection; accurately identifies anomalies through preset time windows and error rate thresholds, and automatically adjusts traffic weights, marks abandoned status, and triggers historical version rollbacks, thereby achieving rapid isolation and automatic recovery of faults. Compared with the traditional solution that relies on manual verification and manual rollback, the implementation method of this application significantly improves the speed of fault response after release, reduces business interruption time, and reduces human operational errors through automated processes, ensuring the high availability and stability of application version releases.

[0096] Figure 2 The following is a schematic diagram showing the structure of a publishing device for an application version provided in an embodiment of the present application. The publishing device 2 for the application version can be configured on a terminal device. Specifically, the publishing device 2 for the application version can include: The receiving module 201 is configured to receive an instruction to create an application version and generate a topologically sorted executable process sequence according to the instruction; The parsing module 202 is configured to execute the executable process sequence and trigger an event, and when the executable process sequence completion event is monitored, parse the application version identifier and service version data in the executable process sequence; A generation module 203 is configured to generate a Kubernetes configuration set including only state-changed services based on the application version identifier and the service version data; The conversion module 204 is used to write the Kubernetes configuration set to a disk file to obtain a change file, convert the change file into a key-value structure, and persist it to distributed storage; A monitoring module 205 is used to monitor key-value change events in distributed storage, extract file paths and contents from event payloads, and synchronize the changed files to the Kubernetes cluster; The completion module 206 is used to complete the application version release when the synchronization is successful.

[0097] The beneficial effects of the embodiments of the present application compared with the prior art are as follows: the embodiments of the present application achieve orderly execution of the release process by dynamically generating a topologically sorted executable process sequence; by parsing the application version identifier and service version data to generate a Kubernetes configuration set that only contains state change services, it avoids the full processing of irrelevant service configuration files, reduces computing resource waste and synchronization delays; converts the change file into a key-value structure and persists it to distributed storage, and ensures data security by utilizing the high availability and reliability of distributed storage; monitors the key-value change events of the distributed storage and synchronizes them to the Kubernetes cluster, achieving real-time synchronization and rapid release of changes. These steps work together to effectively solve the problems of the traditional static script release process's inability to dynamically respond to changes in business needs, long release cycles, resource waste and synchronization delays, and significantly improves the speed of business iteration and the efficiency and reliability of application version releases.

[0098] In some embodiments of the present application, the receiving module 201 is further configured to: Parsing the target application name, version number, and service dependencies from the application version instruction; Build a directed graph based on service dependencies; The executable process sequence is generated according to the directed graph using a topological sorting algorithm.

[0099] In some embodiments of the present application, the parsing module 202 is further configured to: When monitoring the completion event of the executable process sequence, extract the version identifier in the event; Query the version database according to the version identifier to obtain all service version data of the corresponding version; The service version data is parsed to form a structured data packet.

[0100] In some embodiments of the present application, the generating module 203 is further configured to: Filtering out status-changed services from the service version data; For each state-changing service, 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.

[0101] In some embodiments of the present application, the conversion module 204 is further configured to: Write the Kubernetes configuration set to a temporary file; Read a source file and calculate a hash value of the source file; Perform verification according to the hash value; When the verification passes, the target file is replaced with the temporary file to obtain the changed file; The file content of the changed file is converted into a key-value structure, and the key-value structure is persisted to distributed storage.

[0102] In some embodiments of the present application, the monitoring module 205 is further configured to: Listen for key value change events of the preset path; When a new event is detected, the file path and content are extracted from the event payload; Use the file path as a parameter to synchronize the changed file to the Kubernetes cluster.

[0103] In some embodiments of the present application, the application version publishing device 2 further includes a rollback module for: Parse the deployment status data returned by the Kubernetes cluster to extract the Pod startup status, service readiness probe results, and resource usage indicators of the application version instance; When all the Pod startup states are in the ready state and the readiness probe pass rate reaches 100%, the monitoring indicator atomic process is triggered to continuously collect the service performance indicators of the application version; If the error rate is detected to exceed 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 abandoned, triggering the atomic process of historical version rollback, retrieving the key-value data of the previous stable version from the distributed storage and resynchronizing it to the cluster.

[0104] like Figure 3 FIG3 is a schematic diagram of a terminal device provided in an embodiment of the present 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 a program for publishing an application version. When the processor 301 executes the computer program 303, the steps in the above-mentioned embodiments of publishing each application version are implemented, such as Figure 1Steps S101 to S106 are shown.

[0105] The computer program can be divided into one or more modules / units, one or more of which are stored in the memory 302 and executed by the processor 301 to complete the present application. One or more modules / units can be a series of computer program instruction segments that can perform specific functions, and the instruction segments are used to describe the execution process of the computer program in the terminal device.

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

[0107] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), 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.

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

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

[0110] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by 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 embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0111] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method for publishing an application version can be implemented.

[0112] An embodiment of the present application provides a computer program product, which, when executed on a mobile terminal, enables the mobile terminal to implement the steps in the above-mentioned method for publishing an application version.

[0113] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0114] Those skilled in the art will appreciate that the units and algorithm steps of each example 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 performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0116] Units described as separate components may or may not be physically separate, and 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 these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0117] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0118] If the integrated module / unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the process steps in the above-mentioned method embodiments by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content of the computer-readable medium can be appropriately increased or decreased based on the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, based on legislation and patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0119] The above embodiments are intended only to illustrate the technical solutions of the present application and are not intended to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified or some of the technical features thereof may be replaced by equivalents. However, such modifications or replacements do not deviate from the spirit and scope of the technical solutions of the various embodiments of the present application and should be included within the scope of protection of the present application.

Claims

1. A method for publishing an application version, characterized in that: include: receiving an instruction to create an application version, and generating a topologically sorted executable process sequence according to the application version instruction; Executing the executable process sequence and triggering an event, and when monitoring the executable process sequence completion event, parsing the application version identifier and service version data in the executable process sequence; Generate a Kubernetes configuration set containing only the state-changed service based on the application version identifier and the service version data; Write the Kubernetes configuration set to a disk file to obtain a change file, convert the change file into a key-value structure, and persist it to distributed storage; Listen to key-value change events in distributed storage, extract file paths and contents from event payloads, and synchronize the changed files to the Kubernetes cluster. When the synchronization is successful, the application version is released.

2. The method for publishing an application version according to claim 1, wherein: Generating a topologically sorted executable process sequence according to the application version instruction includes: Parsing the target application name, version number, and service dependencies from the application version instruction; Build a directed graph based on service dependencies; The executable process sequence is generated according to the directed graph using a topological sorting algorithm.

3. The method for publishing an application version according to claim 1, wherein: When the executable process sequence completion event is monitored, parsing the application version identifier and service version data in the executable process sequence includes: When monitoring the completion event of the executable process sequence, extract the version identifier in the event; Query the version database according to the version identifier to obtain all service version data of the corresponding version; The service version data is parsed to form a structured data packet.

4. The method for publishing an application version according to claim 1, wherein: Generating a Kubernetes configuration set including only state-changed services based on the application version identifier and the service version data includes: Filtering out status-changed services from the service version data; For each state-changing service, 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.

5. The method for publishing an application version according to claim 1, wherein: Writing the Kubernetes configuration set to a disk file to obtain a change file, converting the change file into a key-value structure, and persisting the key-value structure to distributed storage includes: Write the Kubernetes configuration set to a temporary file; Read a source file and calculate a hash value of the source file; Perform verification according to the hash value; When the verification passes, the target file is replaced with the temporary file to obtain the changed file; The file content of the changed file is converted into a key-value structure, and the key-value structure is persisted to distributed storage.

6. The method for publishing an application version according to claim 1, wherein: The monitoring of key-value change events in distributed storage, extracting file paths and contents from event payloads, and synchronizing the changed files to the Kubernetes cluster include: Listen for key value change events of the preset path; When a new event is detected, the file path and content are extracted from the event payload; Use the file path as a parameter to synchronize the changed file to the Kubernetes cluster.

7. The method for publishing an application version according to claim 1, wherein: After the synchronization is successful and the application version is released, 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 indicators of the application version instance; When all the Pod startup states are in the ready state and the readiness probe pass rate reaches 100%, the monitoring indicator atomic process is triggered to continuously collect the service performance indicators of the application version; If the error rate is detected to exceed 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 abandoned, triggering the atomic process of historical version rollback, retrieving the key-value data of the previous stable version from the distributed storage and resynchronizing it to the cluster.

8. A device for publishing an application version, characterized in that: include: A receiving module, configured to receive an instruction to create an application version, and generate a topologically sorted executable process sequence according to the application version instruction; a parsing module, configured to execute the executable process sequence and trigger an event, and parse the application version identifier and service version data in the executable process sequence when monitoring the executable process sequence completion event; A generation module, configured to generate a Kubernetes configuration set including only state-changed services based on the application version identifier and the service version data; A conversion module is used to write the Kubernetes configuration set to a disk file to obtain a change file, convert the change file into a key-value structure, and persist it to distributed storage; A monitoring module is used to monitor key-value change events in distributed storage, extract file paths and contents from event payloads, and synchronize the changed files to the Kubernetes cluster; The completion module is used to complete the application version release when the synchronization is successful.

9. A terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method for publishing an application version according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method for publishing an application version according to any one of claims 1 to 7 are implemented.

Images