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

Abstract

The invention is applicable to the technical field of computers, and provides a software version publishing method which comprises the following steps: receiving a service version submitted by a developer; when a release instruction is received, analyzing the release instruction, and determining a target service version; creating an application version according to the target service version; generating a configuration file according to the application version; the configuration file is submitted to a GitOps warehouse; analyzing the configuration file to obtain an application version and a target service version; the application version and the target service version are synchronized to a Kubernetes cluster; after synchronization succeeds, application version release is completed. According to the embodiment of the invention, an automatic process from code submission to release is realized, the release process is greatly simplified, and manual intervention and error risks are reduced. And through the use of the automatic script and the tool chain, the time consumption and error possibility caused by manual operation are reduced, and the publishing efficiency and accuracy are improved.

Description

Technical Field

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

[0002] Currently, software releases are usually done through version control systems, such as Git. After developers complete new features or fix bugs, they create new version tags based on the code. After that, this new version is released to the test environment through the build and deployment process. After being tested and verified, it is released to the production environment for users to use.

[0003] However, existing technologies face some difficulties when releasing software versions. For example, version control can become complicated, especially in large projects or teams, and merging code and coordinating work across different branches can be time-consuming. In addition, the build and deployment process may involve multiple steps and tools, requiring manual operations or relying on unstable automated scripts, which may lead to release delays or errors. 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 a software version, which can solve the problem that the related technology is time-consuming and error-prone when publishing a software version.

[0005] In a first aspect, an embodiment of the present application provides a method for publishing a software version, including: Receive service versions submitted by developers; When receiving a release instruction, parse the release instruction and determine the target service version; Create an application version based on the target service version; Generate a configuration file based on the application version; Submit the configuration file to the GitOps repository; Parse the configuration file to obtain the application version and target service version; Synchronize the application version and target service version 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 software version publishing device, including: The receiving module is used to receive the service version submitted by the developer; A first parsing module is used to parse the publishing instruction and determine the target service version when receiving the publishing instruction; Create a module to create an application version based on the target service version; A generation module is used to generate a configuration file according to the application version; The submission module is used to submit the configuration files to the GitOps repository; The second parsing module is used to parse the configuration file to obtain the application version and the target service version; The synchronization module is used to synchronize the application version and the target service version to the Kubernetes cluster; The completion module is used to complete the application version release after the synchronization is successful.

[0007] In a third aspect, an embodiment of the present application provides a terminal device, including 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 software version publishing method 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, the steps of the above-mentioned software version publishing method are implemented.

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

[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 receive the service version submitted by the developer, parse the release instruction when receiving the release instruction, determine the target service version, create the application version according to the target service version, generate the configuration file according to the application version, submit the configuration file to the GitOps warehouse, parse the configuration file, obtain the application version and the target service version, synchronize the application version and the target service version to the Kubernetes cluster, and complete the application version release when the synchronization is successful. The embodiments of the present application integrate Git, GitOps warehouse and Kubernetes cluster to realize the automated process from code submission to release, greatly simplify the release process, reduce manual intervention and error risks. And through the use of automated scripts and tool chains, the time consumption and error possibility caused by manual operations are reduced, and the efficiency and accuracy of release are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. 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 paying creative labor.

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

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

[0014] Figure 3 It is a schematic diagram of the structure 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 the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work are protected by the present application.

[0016] It should be noted that the terms "include", "comprises" and "have" and any variations thereof in the specification and claims of the present 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 the present 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] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0018] Currently, software releases are usually done through version control systems, such as Git. After developers complete new features or fix bugs, they create new version tags based on the code. After that, this new version is released to the test environment through the build and deployment process. After being tested and verified, it is released to the production environment for users to use.

[0019] However, existing technologies face some difficulties when releasing software versions. For example, version control can become complicated, especially in large projects or teams, and merging code and coordinating work across different branches can be time-consuming. In addition, the build and deployment process may involve multiple steps and tools, requiring manual operations or relying on unstable automated scripts, which may lead to release delays or errors.

[0020] In view of this, the embodiment of the present application realizes an automated process from code submission to release by integrating Git, GitOps warehouse and Kubernetes cluster, greatly simplifying the release process and reducing manual intervention and error risks. And through the use of automated scripts and tool chains, the time consumption and error possibility caused by manual operations are reduced, and the efficiency and accuracy of release are improved.

[0021] In order to illustrate the technical solution of the present application, a specific embodiment is provided below for illustration.

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

[0023] Specifically, the software version publishing method may include the following steps S101 to S108.

[0024] Step S101: receiving a service version submitted by a developer.

[0025] Among them, the service version can be a code snapshot submitted by the developer in the version control system (such as Git), representing a specific state or set of functions of the software.

[0026] In the implementation of the present application, developers can complete code submission in the Git repository and trigger a Webhook event. The terminal device can monitor the Webhook event, and when receiving the event, parse the JSON data in the event, extract key information such as the identity of the submitter, the submitted branch, and the submitted hash value, and store the extracted key information in the database to establish a corresponding relationship with the service version.

[0027] Step S102: When a release instruction is received, the release instruction is parsed to determine the target service version.

[0028] The release instruction may be an instruction that triggers a software version release process, and usually includes information such as a target version and a release environment.

[0029] The target service version can be a specific service version specified in the release instruction that you want to release to the production environment or test environment.

[0030] In an implementation manner of the present application, a terminal device may provide a user interface that allows relevant personnel (such as product managers, operation and maintenance personnel, etc.) to submit release instructions. The release instruction may include key information such as the version number of the target service version, the release environment (such as a test environment, a production environment, etc.). After receiving the release instruction, the terminal device may parse the information in the instruction and search the database for the code submission record corresponding to the target service version. If a matching record is found, the record is determined to be the target service version to be released; if no matching record is found, an error message may be prompted and the release instruction may be required to be resubmitted, thereby ensuring that the released version is consistent with the version specified in the instruction and avoiding release errors.

[0031] Step S103: Create an application version according to the target service version.

[0032] The application version may be a software application instance built based on the target service version, which includes all resources and configurations required to run the software.

[0033] In some specific implementations, the above-mentioned creation of the application version according to the target service version may specifically include steps S401 to S403.

[0034] Step S401, retrieve the version code of the target service version.

[0035] The version code may refer to the source code used to implement a specific service version, including logic written in a programming language, configuration files, resource files, etc. The version code is the basis for creating an application version.

[0036] In the implementation mode of the present application, the terminal device can retrieve the corresponding version code from the code repository through Git or other version control systems according to the version number or branch name of the target service version, which may specifically include source code files, configuration files, resource files, etc. This ensures that the correct version code is used in subsequent steps to avoid release failures or quality problems caused by code errors.

[0037] Step S402, compile and package the version code into an application version.

[0038] In the implementation mode of the present application, the terminal device can use a build tool (such as Maven, Gradle, Docker, etc.) to compile and package the version code. The compilation process converts the source code into an executable file or bytecode, and the packaging process packages the compiled files, dependent libraries, configuration files and other resources into a complete application version to facilitate subsequent deployment and operation. At the same time, the packaging process can also perform necessary optimization and configuration on the application version to improve its performance and stability.

[0039] Step S403: perform automated testing on the application version.

[0040] In the implementation of the present application, the terminal device can use an automated testing framework (such as JUnit, Selenium, JMeter, etc.) to write test cases and test the application version. The testing process can include unit testing (verifying the functionality of a single module), integration testing (verifying the interaction between multiple modules), system testing (verifying the functionality and performance of the entire system), etc. By verifying the correctness, stability, and performance of the application version before release, it is ensured that it meets the release requirements. In addition, automated testing can significantly improve test efficiency and accuracy and reduce the risk of human error.

[0041] The implementation method of the present application can significantly shorten the release cycle of software versions and improve release efficiency by automating the compilation, packaging and testing process. In addition, through the automated testing process, problems and defects in the application version can be discovered and fixed in time before release, reducing the risk of release failure or quality problems.

[0042] Step S104: Generate a configuration file according to the application version.

[0043] The configuration file may be a file containing configuration information required for software operation, such as environment variables, database connection information, etc.

[0044] In some specific implementations, the above-mentioned generation of a configuration file according to the application version may specifically include steps S501 to S503.

[0045] Step S501, determining a configuration template according to the application version.

[0046] The configuration template may be a predefined configuration file template that includes placeholders or default values ​​for configuration items. The configuration template may be customized according to different application versions, deployment environments, or business requirements.

[0047] In the implementation of the present application, the terminal device can select a suitable configuration template from the configuration template library according to information such as the type, version number and deployment environment of the application version. The configuration template library can be a collection of multiple configuration templates, each template corresponding to a specific application version and deployment environment. This ensures that a suitable configuration file is generated for each application version to avoid operational problems caused by configuration errors. By selecting a suitable configuration template, the efficiency and accuracy of generating configuration files can be greatly improved.

[0048] Step S502: Fill the relevant information of the application version into the configuration template to obtain a configuration file.

[0049] In the implementation mode of the present application, the terminal device can use a script or an automated tool to fill the relevant information of the application version (such as version number, deployment environment, database connection information, etc.) into the placeholder of the configuration template. Specifically, this can be achieved by reading the metadata, environment variables or configuration files of the application version. Thereby generating a configuration file containing specific information of the application version to ensure that the application version can run correctly in the target environment. By automating the filling process, the workload of manual configuration can be reduced and the accuracy and consistency of the configuration can be improved.

[0050] Step S503: verify the configuration file.

[0051] In the implementation mode of the present application, the terminal device can use a verification tool or script to check the correctness, completeness and consistency of the generated configuration file. The verification process may include syntax checking, value range checking, dependency checking, etc. If a configuration error or inconsistency is found, the relevant personnel can be notified immediately for processing. This ensures that the configuration file meets the release requirements and avoids operational problems caused by configuration errors. Through the verification process, configuration problems can be discovered and fixed in a timely manner, improving the stability and reliability of the software.

[0052] The implementation method of the present application can significantly improve the efficiency and accuracy of configuration file generation and reduce the workload of manual configuration by automating the process of generating and verifying configuration files. In addition, by selecting appropriate configuration templates, automating the filling and verification process, it can reduce operational problems caused by configuration errors and improve the stability and reliability of the software. It can also be convenient to modify and update configuration files, improving the maintainability and scalability of configuration files.

[0053] Step S105, submit the configuration file to the GitOps repository.

[0054] Among them, the GitOps repository is a version control system repository used to store and manage GitOps configuration files, which is usually integrated with a Kubernetes cluster to achieve declarative infrastructure and application management.

[0055] In some specific implementations of the present application, submitting the configuration file to the GitOps repository may specifically include steps S601 to S603.

[0056] Step S601, configure the GitOps repository.

[0057] In the implementation of the present application, the terminal device can first select a Git platform (such as GitHub, GitLab, Bitbucket, etc.) and create a new warehouse as a GitOps warehouse. Then, according to the needs of the project, configure the warehouse's access rights, branch policies, hooks (Hooks, a mechanism that is automatically triggered when a specific event occurs, can be used to trigger the CI / CD process.) and so on. This provides a centralized storage and management environment for configuration files, ensuring version control and traceability of configuration files. By configuring the warehouse's access rights and branch policies, the security and consistency of the configuration files can be ensured.

[0058] Step S602: Use the Git command to submit the configuration file to the GitOps repository.

[0059] In the implementation mode of the present application, in the local environment, the terminal device can use Git commands (such as git init, git add, git commit, git push, etc.) to add the configuration file to the Git repository and submit it to the specified branch. If the GitOps repository is configured with a hook, the hook will automatically trigger the CI / CD process after the submission is successful. By uploading the configuration file to the GitOps warehouse for version control and collaboration. Through the submission operation of the Git command, it can be ensured that the changes to the configuration file are correctly recorded and tracked.

[0060] Step S603: After the configuration file is successfully submitted, the CI / CD process is triggered to verify the configuration file.

[0061] In the implementation of the present application, the terminal device can configure a hook in the GitOps warehouse. When the configuration file is submitted to the specified branch, the hook will automatically trigger the CI / CD process. The CI / CD process may include stages such as building, testing, and deployment, in which the verification stage will perform syntax checks, value range checks, dependency checks, etc. on the configuration file. Thus, the configuration file is automatically verified after submission to ensure the correctness and consistency of the configuration file. Through the automated verification of the CI / CD process, configuration problems can be discovered and fixed in a timely manner, improving the stability and reliability of the software.

[0062] The implementation method of the present application can conveniently store, manage and track changes in configuration files through the use of GitOps warehouse and Git commands, thereby improving the efficiency and accuracy of configuration management. In addition, the GitOps warehouse provides version control and access rights management functions to ensure the traceability and security of configuration files. In addition, through the automated verification of the CI / CD process, configuration problems can be discovered and fixed in a timely manner, improving the stability and reliability of the software.

[0063] Step S106, parsing the configuration file to obtain the application version and the target service version.

[0064] In some specific implementations of the present application, the above-mentioned parsing of the configuration file to obtain the application version and the target service version may specifically include step S701 and step S702.

[0065] Step S701: Use a configuration file parsing tool to parse the configuration file to obtain the application version and the target service version.

[0066] In the implementation of the present application, the terminal device can select a suitable configuration file parsing tool, which should support the format of the configuration file (such as JSON, YAML, INI, etc.), and provide the configuration file to the parsing tool for reading. The parsing tool can extract the information of the application version and the target service version according to the format and structure of the configuration file, and then return the extracted information to the terminal device in a structured manner (such as an object, dictionary, etc.). In this way, the application version and the target service version information can be accurately extracted from the configuration file.

[0067] Step S702: verify the application version and the target service version.

[0068] In the implementation mode of the present application, the terminal device can check the parsed application version and target service version according to the preset verification rules. If any situation that does not comply with the rules is found, the error is immediately recorded and the relevant personnel are notified. If the verification is passed, the subsequent release process continues. This ensures that the parsed application version and target service version are correct, consistent and complete, avoiding release failure or service quality degradation caused by incorrect version information.

[0069] The implementation method of the present application reduces the workload of manual input and checking by automatically parsing and verifying the configuration file, thereby improving the automation level of the publishing process.

[0070] Step S107: Synchronize the application version and the target service version to the Kubernetes cluster.

[0071] Among them, the Kubernetes cluster is an open source container orchestration platform for automating the deployment, expansion, and management of containerized applications.

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

[0073] Step S801, generating a Kubernetes deployment file according to the application version and the target service version.

[0074] Among them, the Kubernetes deployment file is a file in YAML or JSON format, which defines the deployment configuration of the application in the Kubernetes cluster. It includes the application name, container image, number of replicas, resource limits, environment variables, etc.

[0075] In the implementation of the present application, the terminal device can determine the container image tag to be used according to the application version. And define the configuration of the service according to the target service version, such as service port, environment variables, resource restrictions, etc. Then use the Kubernetes API or command line tool (such as kubectl) to generate or update the Kubernetes deployment file.

[0076] Step S802: Apply the Kubernetes deployment file to the Kubernetes cluster.

[0077] In the implementation of the present application, the terminal device can use the kubectl command line tool to apply the generated Kubernetes deployment file to the Kubernetes cluster. You can also use kubectl apply -f <deployment-file>command, where <deployment-file>Is the path to the deployment file. By applying the defined deployment configuration to the Kubernetes cluster, start or update the corresponding applications and services to ensure that the application version and target service version are correctly deployed in the cluster.

[0078] Step S803, monitor the deployment process and verify the deployment result.

[0079] In the implementation mode of the present application, the terminal device can use the kubectl command line tool or the Kubernetes API to monitor the deployment process. You can also use commands such as kubectl get pods and kubectl get services to view the status of resources and services. After the deployment is completed, perform a series of checks and tests, such as verifying whether the service is reachable, checking the application logs and performance, etc. Specifically, you can use Kubernetes' readiness and liveness probes to verify the health status of the application. By real-time tracking and monitoring the deployment process, ensure that the deployment proceeds smoothly and any potential problems are discovered in time, verify the deployment results, ensure that the application runs correctly and meets expectations, and improve the reliability and stability of the deployment.

[0080] The implementation method of the present application reduces the workload of manual configuration and deployment and improves the automation of deployment by automatically generating and applying Kubernetes deployment files. And by monitoring the deployment process and verifying the deployment results, potential problems can be discovered and solved in a timely manner to ensure that the application runs correctly and meets expectations, thereby improving the reliability and stability of deployment. In addition, by defining the application version and target service version of the Kubernetes deployment file, the version management process can be simplified, and application upgrades and rollbacks can be easily performed.

[0081] Step S108: When the synchronization is successful, the application version is released.

[0082] In the implementation mode of the present application, after the terminal device receives the successful synchronization notification of the GitOps system, it can update the release status in the database. Specifically, a notification (such as email, SMS, etc.) can be sent to relevant personnel to inform them that the application version has been successfully released to the specified environment. A user interface or API interface can also be provided to allow relevant personnel to view the release status and log information.

[0083] The beneficial effects of the embodiments of the present application compared with the prior art are as follows: the embodiments of the present application receive the service version submitted by the developer, parse the release instruction when receiving the release instruction, determine the target service version, create the application version according to the target service version, generate the configuration file according to the application version, submit the configuration file to the GitOps warehouse, parse the configuration file, obtain the application version and the target service version, synchronize the application version and the target service version to the Kubernetes cluster, and complete the application version release when the synchronization is successful. The embodiments of the present application integrate Git, GitOps warehouse and Kubernetes cluster to realize the automated process from code submission to release, greatly simplify the release process, reduce manual intervention and error risks. And through the use of automated scripts and tool chains, the time consumption and error possibility caused by manual operations are reduced, and the efficiency and accuracy of release are improved.

[0084] In some specific implementations of the present application, the synchronization of the application version and the target service version to the Kubernetes cluster may specifically include the following steps: Perform a workspace cleanup operation on the GitOps repository.

[0085] A workspace can be a temporary area where GitOps tools can stage and prepare configurations before applying them to the cluster.

[0086] In the implementation of the present application, the terminal device may first determine what content needs to be cleaned up. Specifically, it may include old branches, merge requests (PRs), temporary files or directories that are no longer needed, etc. Then, an existing automated script or tool may be used to perform the cleanup operation. Specifically, it may be to execute a series of Git commands in the GitOps repository, such as deleting branches, merging requests, etc. After the cleanup operation is completed, the results of the operation are recorded and reported for tracking and auditing.

[0087] The implementation method of the present application can keep the GitOps workspace clean and consistent by cleaning up the content that is no longer needed, reduce potential confusion and errors, and also reduce the amount of content that the automation tool needs to process, thereby improving the efficiency of automated deployment and configuration updates.

[0088] Figure 2 The schematic diagram of the structure of a software version publishing device provided in an embodiment of the present application is shown. The software version publishing device 2 can be configured on a terminal device. Specifically, the software version publishing device 2 can include: Receiving module 201, used to receive the service version submitted by the developer; A first parsing module 202 is used to parse the publishing instruction and determine the target service version when receiving the publishing instruction; A creation module 203, used to create an application version according to the target service version; A generating module 204, configured to generate a configuration file according to the application version; A submission module 205 is used to submit the configuration file to the GitOps repository; A second parsing module 206, configured to parse the configuration file to obtain the application version and the target service version; A synchronization module 207 is used to synchronize the application version and the target service version to the Kubernetes cluster; The completion module 208 is used to complete the application version release when the synchronization is successful.

[0089] The beneficial effect of the embodiment of the present application compared with the prior art is: the embodiment of the present application receives the service version submitted by the developer, and when receiving the release instruction, parses the release instruction, determines the target service version, creates an application version according to the target service version, generates a configuration file according to the application version, submits the configuration file to the GitOps warehouse, parses the configuration file, obtains the application version and the target service version, synchronizes the application version and the target service version to the Kubernetes cluster, and completes the release of the application version after the synchronization is successful. The embodiment of the present application integrates Git, GitOps warehouse and Kubernetes cluster to realize the automated process from code submission to release, greatly simplifies the release process, and reduces manual intervention and error risks. And through the use of automated scripts and tool chains, the time consumption and error possibility caused by manual operations are reduced, and the efficiency and accuracy of release are improved.

[0090] In some implementations of the present application, the creation module 203 is further used to: Retrieving the version code of the target service version; Compile and package the version code into the application version; Automated testing is performed on the application version.

[0091] In some implementations of the present application, the generation module 204 is further used to: Determine a configuration template according to the application version; Fill the relevant information of the application version into the configuration template to obtain the configuration file; The configuration file is verified.

[0092] In some implementations of the present application, the submitting module 205 is further used to: Configure the GitOps repository; Use the Git command to submit the configuration file to the GitOps repository; After the configuration file is successfully submitted, the CI / CD process is triggered to verify the configuration file.

[0093] In some implementations of the present application, the second parsing module 206 is further used to: Parse the configuration file using a configuration file parsing tool to obtain the application version and the target service version; The application version and the target service version are verified.

[0094] In some implementations of the present application, the synchronization module 207 is further used to: Generate a Kubernetes deployment file according to the application version and the target service version; Apply the Kubernetes deployment file to the Kubernetes cluster; Monitor the deployment process and verify the deployment results.

[0095] In some implementations of the present application, the software version publishing device 2 further includes an execution module for: Perform a workspace cleanup operation on the GitOps repository.

[0096] like Figure 3 FIG. 3 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 software version publishing program. When the processor 301 executes the computer program 303, the steps in the above-mentioned software version publishing embodiments are implemented, such as Figure 1 Steps S101 to S108 are shown.

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

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

[0099] 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, etc.

[0100] The memory 302 may be an internal storage unit of the terminal device, such as a hard disk or memory of the terminal device. The memory 302 may also be an external storage device of the terminal device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the terminal device. Further, the memory 302 may also include both an internal storage unit of the terminal device and an external storage device. The memory 302 is used to store computer programs and other programs and data required by the terminal device. The memory 302 may also be used to temporarily store data that has been output or is to be output.

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

[0102] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be 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 in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in 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, which will not be repeated here.

[0103] An embodiment of the present application also 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 software version publishing method can be implemented.

[0104] An embodiment of the present application provides a computer program product. When the computer program product runs on a mobile terminal, the steps in the above-mentioned software version publishing method can be implemented when the mobile terminal executes the computer program product.

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

[0106] Those of ordinary skill 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 to be beyond the scope of this application.

[0107] In the embodiments provided in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, 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.

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

[0109] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0110] If the integrated module / unit is implemented in the form of 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, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, 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 contained in the computer-readable medium can be appropriately increased or decreased 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 electric carrier signals and telecommunication signals.

[0111] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application is described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features can be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for publishing a software version, characterized in that: include: Receive service versions submitted by developers; When receiving a release instruction, parsing the release instruction to determine a target service version; Creating an application version according to the target service version; Generate a configuration file according to the application version; Submit the configuration file to the GitOps repository; Parse the configuration file to obtain the application version and the target service version; Synchronize the application version and the target service version to the Kubernetes cluster; When the synchronization is successful, the application version is released.

2. The method for publishing a software version according to claim 1, characterized in that: The creating an application version according to the target service version includes: Retrieving the version code of the target service version; Compile and package the version code into the application version; Automated testing is performed on the application version.

3. The method for publishing a software version according to claim 1, characterized in that: The generating a configuration file according to the application version includes: Determine a configuration template according to the application version; Fill the relevant information of the application version into the configuration template to obtain the configuration file; The configuration file is verified.

4. The method for publishing a software version according to claim 1, characterized in that: Submitting the configuration file to the GitOps repository includes: Configure the GitOps repository; Use the Git command to submit the configuration file to the GitOps repository; After the configuration file is successfully submitted, the CI / CD process is triggered to verify the configuration file.

5. The method for publishing a software version according to claim 1, characterized in that: The parsing the configuration file to obtain the application version and the target service version includes: Parse the configuration file using a configuration file parsing tool to obtain the application version and the target service version; The application version and the target service version are verified.

6. The method for publishing a software version according to claim 2, characterized in that: The synchronizing the application version and the target service version to the Kubernetes cluster includes: Generate a Kubernetes deployment file according to the application version and the target service version; Apply the Kubernetes deployment file to the Kubernetes cluster; Monitor the deployment process and verify the deployment results.

7. The method for publishing a software version according to claim 1, characterized in that: After synchronizing the application version and the target service version to the Kubernetes cluster, the method further includes: Perform a workspace cleanup operation on the GitOps repository.

8. A software version publishing device, characterized in that: include: The receiving module is used to receive the service version submitted by the developer; A first parsing module is used to parse the publishing instruction and determine the target service version when receiving the publishing instruction; A creation module, used to create an application version according to the target service version; A generation module, used to generate a configuration file according to the application version; A submission module, used to submit the configuration file to the GitOps repository; A second parsing module, used to parse the configuration file to obtain the application version and the target service version; A synchronization module, used to synchronize the application version and the target service version to the Kubernetes cluster; The completion module is used to complete the release of the application version after 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 software version publishing method as claimed in 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 a software version according to any one of claims 1 to 7 are implemented.

Images