Method, device and storage medium for version iteration of multiple applications

Abstract

Embodiments of the present application provide a method, device and storage medium for version iteration of multi-application. The method comprises: deploying a software configuration management tool on a k8s cluster where the multi-application is located; receiving and storing a configuration file to a location designated by the software configuration management tool; and performing batch operations on branches of the multi-application for version iteration by the software configuration management tool according to the configuration file. Through the present application, the workload of developers can be significantly reduced.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of computer technology, and more particularly, to a method, device and storage medium for version iteration of multiple applications. BACKGROUND

[0002] This section is intended to provide a background or context to the embodiments of the application recited in the claims. The description herein can include concepts that can be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the subject matter described in this section is not prior art to the claims in this application and is not admitted to be prior art by its inclusion in this section.

[0003] Currently, in some business platforms, multiple applications are often included, and some applications may be associated with each other and dependent on each other. For example, in a micro-service architecture, a large and complex business application is split into multiple micro-services for implementation, and the multiple micro-services can be regarded as multiple applications. A large business application can involve several hundred micro-services, and git (a distributed version control system) is usually used for version management of program codes of the micro-services. When performing daily business iteration, more than ten micro-service program codes are often changed. During the version iteration process, developers often need to switch to new branches one by one, then check dependencies one by one, release new version program codes of service providers, and upgrade version information of dependents.

[0004] A round of application iteration version development needs to go through multiple links such as testing, pre-release, testing and acceptance in an online environment. Corresponding developers need to create branches, merge program codes, and manage versions back and forth through a program code version management tool. For example, developers need to create new branches and merge program codes for the applications in iteration one by one, and if there is dependency between applications (for example, one application depends on an API (Application Programming Interface) of another application to obtain user information), then the developers also need to manually check jar package versions and upgrade versions one by one. With the increase of the number of iterations involved in engineering, the corresponding workload increases linearly, which cannot converge well, so that developers spend a lot of effort on program code management during iteration, and cannot focus on business implementation and code quality. SUMMARY

[0005] Looking at our existing version management tools, git only helps us solve the version management of program codes of a single application. Maven and gradle only solve the package dependency management of a single application. However, for the case of multiple applications such as micro-service architecture, there are the iteration management problems described above.

[0006] Therefore, it is highly desirable to have a method that can facilitate version iteration of multiple applications, such as microservice architecture, to reduce the workload of iteration management.

[0007] In this context, embodiments of the present application aim to provide a method, device and storage medium for version iteration of multiple applications.

[0008] In a first aspect of the embodiments of the present application, a method for version iteration of multiple applications is provided, comprising:

[0009] deploying a software configuration management tool on a k8s cluster where the multiple applications are located;

[0010] receiving a configuration file and storing it in a location designated by the software configuration management tool; and

[0011] performing batch operations on branches of the multiple applications for version iteration by the software configuration management tool according to the configuration file.

[0012] In an embodiment of the present application, the performing batch operations on branches of the multiple applications for version iteration by the software configuration management tool according to the configuration file comprises:

[0013] receiving user instructions for running a command for creating a test branch, wherein the command for creating a test branch contains a file path of the configuration file as a parameter;

[0014] reading the configuration file specified by the parameter of the command for creating a test branch to determine the application to be versioned;

[0015] obtaining the program code of the application to be versioned; and

[0016] creating a new test branch for the application to be versioned according to the obtained program code.

[0017] In another embodiment of the present application, the configuration file comprises an application configuration file, wherein the application configuration file includes information of a remote repository where the program code of the multiple applications is located, and the obtaining the program code of the application to be versioned comprises:

[0018] searching for the program code of the application to be versioned in a file directory for locally storing the program code of the versioned application;

[0019] if the program code of the application to be versioned is not found in the file directory, obtaining the application configuration file;

[0020] determining, from the application configuration file, a remote repository where program code of the application to be versioned resides;

[0021] retrieving the program code of the application to be versioned from the remote repository.

[0022] In yet another embodiment of the present application, the performing, by the software configuration management tool, batch operations on branches of the plurality of applications for versioning according to the configuration file further comprises:

[0023] receiving user instructions to run a create published branch command, wherein the create published branch command contains a file path of the configuration file as a parameter;

[0024] reading the configuration file specified by the parameter of the create published branch command to determine an application to be versioned;

[0025] retrieving program code from the new test branch of the application to be versioned;

[0026] creating a published branch for the application to be versioned according to the retrieved program code; and

[0027] publishing a snapshot package of the application to be versioned as an official jar package to dependent applications.

[0028] In yet another embodiment of the present application, the performing, by the software configuration management tool, batch operations on branches of the plurality of applications for versioning according to the configuration file further comprises:

[0029] receiving user instructions to run a re-publish command, wherein the re-publish command contains a file path of the configuration file as a parameter;

[0030] reading the configuration file specified by the parameter of the re-publish command to determine an application to be re-published;

[0031] retrieving the latest program code of the application to be re-published; and

[0032] generating a jar package of the application to be re-published according to the latest program code and re-publishing to dependent applications associated with the application to be re-published.

[0033] In yet another embodiment of the present application, the performing, by the software configuration management tool, batch operations on branches of the plurality of applications for versioning according to the configuration file further comprises:

[0034] receiving a user instruction of running a merge branch command, wherein a file path of the configuration file is included as a parameter in the merge branch command;

[0035] reading the configuration file specified by the parameter of the merge branch command to determine an application to be subjected to a merge branch operation;

[0036] obtaining program code from a release branch of the determined application to be subjected to the merge branch operation;

[0037] merging the obtained program code into a release branch of the determined application to be subjected to the merge branch operation; and

[0038] publishing the merged release branch to an online environment.

[0039] In yet another embodiment of the present application, the batch operation of branches for version iteration of the multiple applications by the software configuration management tool according to the configuration file further comprises:

[0040] receiving a user instruction of running a merge branch command, wherein a file path of the configuration file is included as a parameter in the merge branch command;

[0041] reading the configuration file specified by the parameter of the merge branch command to determine an application to be subjected to a merge branch operation;

[0042] obtaining program code from a release branch of the determined application to be subjected to the merge branch operation; and

[0043] merging the obtained program code into a main branch of the determined application to be subjected to the merge branch operation.

[0044] In yet another embodiment of the present application, the deploying the software configuration management tool on the k8s cluster where the multiple applications are located comprises:

[0045] deploying the software configuration management tool on any node of the k8s cluster where the multiple applications are located.

[0046] In yet another embodiment of the present application, before the receiving the deployment file based on the Docker container, further comprising:

[0047] configuring the deployment file so that the deployed software configuration management tool comprises one or more of the following file directories:

[0048] a file directory for storing user configuration files;

[0049] a file directory for locally storing program code of an iterated application;

[0050] a file directory for storing information about a remote repository, wherein the remote repository stores the multi-application program code;

[0051] a file directory for storing application configuration files.

[0052] In yet another embodiment of the present application, before the receiving the Docker container based deployment file, further comprising:

[0053] configuring the deployment file to enable the deployed software configuration management tool to run one or more of the following commands:

[0054] a command for creating a test branch;

[0055] a command for creating a publish branch;

[0056] a command for republishing;

[0057] a command for merging branches.

[0058] In a second aspect of the embodiments of the present application, a method for deploying a software configuration management tool to perform version iteration on a multi-application is provided, comprising:

[0059] receiving a Docker container based deployment file;

[0060] building an image using a Docker build command according to the deployment file; and

[0061] deploying the software configuration management tool on a k8s cluster where the multi-application is located using a Docker run command based on the image.

[0062] In a third aspect of the embodiments of the present application, a computing device is provided, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, and wherein the processor executes the computer program to enable the computing device to implement the method for performing version iteration on a multi-application as described above.

[0063] In a fourth aspect of the embodiments of the present application, a computer readable storage medium is provided, wherein the computer readable storage medium stores a computer program, and wherein the computer program is executed by a processor to enable the processor to implement the method for performing version iteration on a multi-application as described above.

[0064] According to the method, device and storage medium for version iteration of multiple applications, the software configuration management tool is deployed in the platform where the multiple applications are located, and the tool runs the batch operation command for version iteration according to the user configuration file, so that the version iteration operation of the multiple applications can be batch processed without iteration one by one, thereby significantly reducing the workload of the developer and freeing the developer from tedious repetitive work. BRIEF DESCRIPTION OF DRAWINGS

[0065] The above and other objects, features and advantages of the present application exemplary embodiments will be more apparent from the following detailed description read in conjunction with the accompanying drawings, in which:

[0066] Figure 1 A block diagram of a computing device suitable for implementing embodiments of the present application is schematically shown;

[0067] Figure 2 A block diagram of an exemplary k8s cluster according to an embodiment of the present application is schematically shown;

[0068] Figure 3 A flowchart of a method for version iteration of multiple applications according to an embodiment of the present application is schematically shown;

[0069] Figure 4 A flowchart of a method for deploying a software configuration management tool for version iteration of multiple applications according to an embodiment of the present application is schematically shown;

[0070] Figure 5 A flowchart of a method for version iteration of multiple applications according to yet another embodiment of the present application is schematically shown;

[0071] Figure 6 A block diagram of a device for version iteration of multiple applications according to an embodiment of the present application is schematically shown.

[0072] In the drawings, identical or corresponding reference signs indicate identical or corresponding parts. DETAILED DESCRIPTION

[0073] The principles and spirits of the present application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are given only to enable those skilled in the art to better understand and implement the present application, and do not limit the scope of the present application in any way. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0074] Figure 1A block diagram of an exemplary computing device 100 suitable for implementing embodiments of the present application is shown. As shown Figure 1 The computing device 100 can include a central processing unit (CPU) 101, a random access memory (RAM) 102, a read only memory (ROM) 103, a system bus 104, a hard disk controller 105, a keyboard controller 106, a serial interface controller 107, a parallel interface controller 108, a display controller 109, a hard disk 110, a keyboard 111, a serial peripheral device 112, a parallel peripheral device 113, and a display 114. Of these devices, the CPU 101, RAM 102, ROM 103, hard disk controller 105, keyboard controller 106, serial controller 107, parallel controller 108, and display controller 109 are coupled to the system bus 104. The hard disk 110 is coupled to the hard disk controller 105, the keyboard 111 is coupled to the keyboard controller 106, the serial peripheral device 112 is coupled to the serial interface controller 107, the parallel peripheral device 113 is coupled to the parallel interface controller 108, and the display 114 is coupled to the display controller 109. It will be appreciated that Figure 1 The structural block diagram shown is merely for illustrative purposes and is not intended to limit the scope of the present application. In some cases, certain devices can be added or removed depending on the specific circumstances.

[0075] Those skilled in the art know that the embodiments of the present application can be implemented as a computing device, a method or a computer program product. Therefore, the present disclosure can be embodied in the form of a complete hardware, a complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, which is generally referred to herein as "device", "module" or "unit". In addition, in some embodiments, the present application can also be embodied in the form of a computer program product in one or more computer readable media, which contains computer readable program codes.

[0076] Any combination of one or more computer readable medium can be utilized. The computer readable medium can be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium can be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0077] A computer readable signal medium can include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal can take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium can be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0078] Program code embodied on a computer readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0079] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In an embodiment of the application, the remote computer can be a server or another desktop computer.

[0080] The software modules or components can include the system 100 illustrated in FIG. 1. Moreover, the software modules or components can include micro instruction code that, when executed by the processor 102, carries out the functions or operations of the system 100. The software modules or components can include a high level procedure, a program, micro instruction code, a circuit, integration circuit, application specific integrated circuit, or processor that can carry out a predetermined function or an operation when executed by the processor 102. The software modules or components can include a computer program product that is executed by the processor 102. The computer program product can be stored in the memory 104 or can be stored in memory outside the system 100.

[0081] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions that are executed on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0082] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions that are executed on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0083] According to embodiments of the present application, a method, an apparatus, a computing device and a computer readable storage medium for version iteration of multiple applications are provided.

[0084] In this document, it is to be understood that the terms "software configuration management tool" or "SCM tool" refer to a tool for managing version iteration of multiple applications deployed according to embodiments of the present application, which can be replaced by any other appropriate naming, but all fall within the scope of the present application. Any number of elements in the accompanying drawings is used for illustration and not limitation, and any naming is only used for differentiation and does not have any limiting meaning.

[0085] The principles and spirits of the present application will be explained in detail below with reference to several representative embodiments of the present application. SUMMARY

[0087] In embodiments of the present application, a software configuration management tool is deployed in a platform where multiple applications are located, and the software configuration management tool runs batch operation commands for version iteration according to a user configuration file, so that batch processing of version iteration operations of multiple applications can be performed without iteration one by one, thereby significantly reducing the workload of developers and freeing developers from tedious repetitive work.

[0088] After introducing the basic principles of the present application, various non-limiting embodiments of the present application will be specifically introduced below.

[0089] Overview of Application Scenarios

[0090] With the development of container technology, people use containers more and more to deploy multi-application platforms such as micro-service architecture, and use k8s (kubernetes, an open source container cluster management system) to manage containers. Among them, Docker is a commonly used container engine, and using k8s+Docker to deploy multi-application is a common way. However, it can be understood that the present application is also applicable to other container technologies.

[0091] Figure 2 A block diagram of an exemplary k8s cluster 200 suitable for implementing embodiments of the present application is shown. As Figure 2 shown, the k8s cluster 200 can include one or more nodes 201 and a plurality of applications 202, wherein the plurality of applications 202 are shown as distributed on the plurality of nodes 201. It can be understood that the plurality of applications 202 can also be distributed on one node 201. In one example, the plurality of applications 202 belong to a plurality of microservices that constitute one or more large software applications in a micro-service architecture. Each node 201 runs a Docker module 203 for creating containers for the node 201 to deploy the applications 202.

[0092] In embodiments of the present application, a software configuration management (SCM) tool 204 for version iteration management of the plurality of applications 202 of the k8s cluster 200 can be deployed on any node 201 of the k8s cluster. In the case of deploying the k8s cluster using Docker technology, the SCM tool 204 can be deployed in the form of a Docker container on any node 201.

[0093] The node 201 can be a physical machine, a virtual machine, or a resource provided by a cloud service provider. Optionally, the node 201 on which the SCM tool 204 is deployed and run is all or part of a physical host, or all or part of multiple physical hosts, which can be logically regarded as a computing device. The computing device can be composed of structures as Figure 1 shown and described with reference to Figure 1 It can be understood that the present application is not limited to such specific structures.

[0094] Exemplary Method

[0095] The following will be combined with Figure 2 application scenarios, refer toFigures 3-5 A method for version iteration of multiple applications and a method of deploying a software configuration management tool to perform version iteration of multiple applications according to an example embodiment of the present application will be described. It should be noted that the above application scenarios are only shown for the purpose of facilitating understanding of the spirit and principles of the present application, and the embodiments of the present application are not limited in this respect. On the contrary, the embodiments of the present application can be applied to any applicable scenario.

[0096] Figure 3 A schematic flowchart of a method for version iteration of multiple applications according to an embodiment of the present application is shown. The example method can be performed by the node 101 shown in Figure 1 or the computing device 200 shown in Figure 2 . As shown in Figure 3 , the example method includes:

[0097] S301, deploying a software configuration management tool on a k8s cluster where the multiple applications are located.

[0098] At present, commonly used version management tools are git, Maven and Gradle, among which git only solves the version management of program code of a single application, and Maven and Gradle only solve the package dependency management of a single application. The embodiments of the present application deploy a software configuration management (SCM) tool on a k8s cluster where multiple applications are located to solve the problem of batch management of version iteration of multiple applications.

[0099] As described above, the SCM tool can be deployed on any node of the k8s cluster where the multiple applications are located. Exemplarily, Figure 4 A flowchart of a method of deploying a software configuration management tool on a node of a k8s cluster where multiple applications are located according to an embodiment of the present application is shown. As shown in Figure 4 , the example method includes:

[0100] S401, receiving a deployment file based on a Docker container;

[0101] S402, constructing an image using a Docker build command according to the deployment file; and

[0102] S403, deploying based on the image using a Docker run command.

[0103] As mentioned before, the SCM tool can be deployed on any node of the k8s cluster to perform version iteration on multiple applications. Steps S401-S403 can be performed by the node on which the SCM tool is to be deployed. Docker module 203 can be run to deploy the SCM tool in a Docker container of the node. For example, an image is built using a Docker build command, and the deployment is performed using a Docker run command.

[0104] Exemplarily, the deployment file is a file written by the developer, and in the k8s cluster based on Docker deployment, the deployment file is a Dockerfile written based on Docker. Therefore, before step S401, the example method can further include a step of writing, by the developer, a deployment file Dockerfile based on Docker.

[0105] In the Dockerfile, the directory of the SCM tool can be configured so that the deployed SCM tool has specific file directories to store corresponding files used in the version iteration process. For example, one or more of the following specific file directories can be configured:

[0106] (1) A file directory for storing user configuration files, for example, named itrationDocument, where the user configuration file refers to information written by the user about the version iteration project to be performed, for example, specifying which applications need to be versioned, how the new branch created for this version iteration project should be named, and the like. In some examples, the user configuration file can be in a simple yml (i.e., YAML, Yet Another Markup Language) file format, which is a programming language based on Unicode (Unified Code) to express data sequences, easy to read, easy to interact with scripting languages. An example of the content of the user configuration file is shown below:

[0107] projects:tiku-base,tiku-quiz,course-server,video-server

[0108] branch:feature / test-scm

[0109] Wherein, the first line specifies that the applications to be versioned are tiku-base, tiku-quiz, course-server, and video-server; the second line specifies that the name of the new branch to be created contains test-scm.

[0110] (2) A file directory for locally storing the program code of the application being iterated, for example, named projects, wherein when the program code of an application is needed during iteration, the SCM tool first looks in this file directory and if not found, goes to the remote repository to obtain. The remote repository is, for example, a remote git repository (gitlab).

[0111] (3) A file directory for storing information about the remote repository, for example, named git, which is used to store the program code of the application.

[0112] (4) A file directory for storing application configuration files (for example, named config), wherein the application configuration files are used to specify the corresponding repository address where the program code of each application is stored. An example of the content of an application configuration file is shown below:

[0113] tiku-base: https: / / github.com / xxx / tiku-baase

[0114] member-server: https: / / github.com / xxx / member-server

[0115] The first line above shows that the corresponding repository address where the program code of the tiku-base application is stored is “https: / / github.com / xxx / tiku-baase”; the second line shows that the corresponding repository address where the program code of the member-server application is stored is “https: / / github.com / xxx / member-server”.

[0116] The developer can also configure in the Dockerfile commands that can be run by the deployed SCM tool to perform batch operations in the version iteration of multiple applications. For example, one or more of the following commands are configured:

[0117] (1) A command to create a test branch.

[0118] Optionally, the command can be configured in the form of command name + parameter, and the SCM tool can be configured to perform the operation of creating a test branch upon receiving the command. Illustratively, the parameter can be the file name of the user configuration file, so that the deployed SCM tool can create a new test branch based on the user configuration file stored in a pre-set directory for version iteration according to the command. In another example, the parameter is a file path, so that the deployed SCM tool can create a new test branch based on the file stored in the file path for version iteration according to the command. The file path can point to a pre-set directory for storing user configuration files or other directories; the file can be a user configuration file or other files.

[0119] An example of a command for creating a new test branch is shown as follows:

[0120] create demo.yml

[0121] Wherein, create is the unique command name of the command, and demo.yml is the file name of the user configuration file as the parameter of the command. When the parameter of the command is only a file name, the SCM tool defaults that the file is stored in a specific directory for storing user configuration files; when the parameter is a file path, the SCM tool obtains the file from the file path.

[0122] By deploying the file, the SCM tool is configured to create a test branch according to the file specified by the parameter of the command for creating a test branch upon receiving the command. The file specifies the application to be versioned. In some examples, the file also specifies how the created test branch should be named. Specifically, the SCM tool is configured to perform the following processing upon receiving the command for creating a test branch:

[0123] A1, read the file specified by the parameter of the command to determine the application to be versioned. The application to be versioned can be one or more, and when there are multiple, the SCM tool performs batch operations on the multiple applications.

[0124] B1, obtain the program code of the application to be versioned. The SCM tool is configured to first look for the program code of the application to be versioned in the file directory for locally storing the program code of the iterated application, and if not found, obtain the application configuration file in the file directory for storing the application configuration file, determine the corresponding remote repository storing the program code of the application to be versioned, and obtain the program code from the corresponding remote repository according to the corresponding remote repository information in the file directory for storing the configuration, key, etc. information about the remote repository.

[0125] C1. Create a new test branch for the application to be versioned based on the obtained program code. Optionally, the SCM tool names the new test branch according to information about how to name the new branch in a file specified by the parameter.

[0126] (2) A command to create a publish branch.

[0127] Optionally, the command can be configured in the form of command name 1 + parameter + command name 2, and the SCM tool can be configured to perform the operation of creating a publish branch and publishing a snapshot package as a formal package (a jar package) when receiving the command. The command name 1 is the command name of creating a publish branch, and the command name 2 is the command of publishing a jar package. Exemplarily, the parameter can be the file name of a user configuration file, so that the deployed SCM tool can create a publish branch based on the user configuration file stored in a pre-set directory according to the command for version iteration. In another example, the parameter is a file path, so that the deployed SCM tool can create a publish branch based on the file stored in the file path according to the command for version iteration. The file path can point to a pre-set directory for storing a user configuration file, or can point to other directories; the file can be a user configuration file, or can be other files. An example of the command to create a publish branch is shown as follows:

[0128] generatePublish demo.yml publish

[0129] In which, generatePublish is the command name of command 1, demo.yml is the file name of a user configuration file as the parameter of the command, and publish is the command name of command 2. When the parameter of the command is only a file name, the SCM tool defaults that the file is stored in a specific directory for storing user configuration files; when the parameter is a file path, the SCM tool obtains the file in the file path.

[0130] By deploying a file, the SCM tool is configured to perform the following processing in response to receiving the command to create a publish branch:

[0131] A2. Read the file specified by the parameter of the command to determine the application to be versioned. The application to be versioned can be one or more, and when there are multiple, the SCM tool performs batch operations on the multiple applications.

[0132] B2. Obtain program code from the test branch of the application to be versioned. Optionally, the SCM tool can determine the branch name of the test branch of the application to be versioned according to the file specified by the parameter of the command, and obtain program code from the determined test branch.

[0133] C2, create a publish branch for the application to be versioned according to the obtained program code.

[0134] D2, publish the snapshot package of the application to be versioned as an official jar package to the dependent applications to replace the corresponding jar package of the dependent applications. Wherein, the SCM tool can determine the dependent applications according to the file specified by the parameter of the command. For example, the parameter is a user configuration file, and the user configuration file records the dependent applications associated with each application to be versioned. Through this process, "one-click pre-release" can be achieved, greatly saving time cost.

[0135] (3) Re-publishing command.

[0136] After executing the command of creating a publish branch, if the program code is modified again, the jar package needs to be modified accordingly and republished. Based on this need, the re-publication command can be configured when the SCM tool is deployed.

[0137] Optionally, the command can be configured in the form of command name 1 + parameter + command name 2, and the SCM tool can be configured to execute the operation of updating the publish branch and publishing the new jar package when receiving the command. Wherein, the command name 1 is the command name of updating the publish branch, and the command name 2 is the command of publishing the new jar package. Exemplarily, the parameter can be the file name of the user configuration file, so that the deployed SCM tool can update the publish branch based on the user configuration file stored in the pre-set directory for version iteration according to the command. In another example, the parameter is a file path, so that the deployed SCM tool can update the publish branch based on the file stored in the file path for version iteration. The file path can point to a pre-set directory for storing user configuration files, or it can point to other directories; the file can be a user configuration file, or it can be other files. One example of the re-publication command is shown as follows:

[0138] rePublish demo.yml publish

[0139] Wherein, rePublish is the command name of command 1, demo.yml is the file name of the user configuration file as the parameter of the command, and publish is the command name of command 2. When the parameter of the command is only a file name, the SCM tool defaults that the file is stored in a specific directory for storing user configuration files; when the parameter is a file path, the SCM tool obtains the file from the file path.

[0140] Through the deployment file, the SCM tool is configured to execute the following processing in response to receiving the re-publication command:

[0141] A3. Read the file specified by the parameter of the command to determine the applications to be re-published. When the parameter is a user configuration file, the command is executed for all the applications to be versioned, regardless of whether their program code has been modified after publication. Alternatively, the file specified by the parameter can be a user-defined file that specifies only certain applications, e.g., the applications whose program code has been modified after publication, to be re-published during the versioning process.

[0142] B3. Obtain the latest program code of the applications to be re-published. Exemplarily, the SCM tool can obtain the latest program code from the modified publication branch. In other examples, the latest program code can be obtained from other branches, e.g., the release branch, if program code modifications have been made in these other branches.

[0143] C3. Generate the jar files of the applications to be re-published from the latest program code and re-publish them to the dependent applications associated with the applications to be re-published to replace the corresponding jar files published before. The dependent applications can be determined by the SCM tool according to the file specified by the parameter of the command. For example, the parameter is a user configuration file in which the dependent applications associated with each application to be versioned are recorded.

[0144] (4) Merge Branch Command

[0145] The command is used to merge the program code of one branch to another branch, e.g., to merge the program code of the publication branch to the release branch of an application, or to merge the program code of the release branch to the main branch of an application.

[0146] Optionally, the command can be configured in the form of command name + parameter 1 + parameter 2 + parameter 3, and the SCM tool can be configured to perform the operation of merging the branch specified by parameter 2 into the branch specified by parameter 3 on the application specified by parameter 1 upon receiving the command. The command name is the command name of the merge branch command, parameter 1 is used to specify the application to which the merge operation is performed, parameter 2 is used to specify the branch to be merged into another branch, and parameter 3 is used to specify the branch to be merged into. For example, parameter 1 can be the file name of a user configuration file, so that the deployed SCM tool can perform the merge operation on the specified application based on the user configuration file stored in a pre-set directory according to the command. In another example, the parameter is a file path, so that the deployed SCM tool can perform the merge operation on the specified application based on the file stored in the file path according to the command. The file path can point to a pre-set directory for storing user configuration files, or it can point to other directories; the file can be a user configuration file, or it can be a custom file written by the user during the iteration process. An example of the merge branch command is shown as follows:

[0147] merge filepath branch1 branch2

[0148] Wherein, merge is the command name of the command, filepath is the path of the user configuration file, which is parameter 1 of the command, branch1 is parameter 2, and branch2 is parameter 3. When parameter 1 of the command is only a file name, the SCM tool defaults that the file is stored in a specific directory for storing user configuration files; when the parameter 1 is a file path, the SCM tool obtains the file from the file path.

[0149] By deploying the file, the SCM tool is configured to perform the following processing in response to receiving the merge branch command:

[0150] A4, read the file specified by parameter 1 of the command to determine the application to which the merge branch operation is performed. When the parameter specifies a user configuration file, the command is executed on all applications to be versioned. Optionally, the file specified by the parameter can also be a custom file written by the user during the version iteration process, which specifies that the merge branch operation is performed only on certain applications.

[0151] B4, determine the merged branch to be merged into another branch according to parameter 2 of the command, and obtain the program code from the merged branch of the application to which the merge branch operation is performed.

[0152] C4, determine the merge branch to be merged into according to parameter 3 of the command, and merge the program code obtained in step B4 into the merge branch of the application to which the merge branch operation is performed.

[0153] In one example, to facilitate the merging of the publication branch into the release branch and the merging of the release branch into the master branch, two specific merge branch commands are configured for the two operations respectively: a command for merging the publication branch into the release branch and a command for merging the release branch into the master branch.

[0154] Optionally, the command for merging the publication branch into the release branch can be configured in the form of command name 1 + parameter + command name 2. Here, command name 1 refers to the command for merging the publication branch into the release branch, command name 2 refers to the command for publishing the merged release branch to the online environment, and the parameter is used to specify the application to which the command is directed. Illustratively, the parameter can be the file name of a user configuration file, so that the deployed SCM tool can merge the publication branch into the release branch and publish it to the online environment according to the command based on the user configuration file stored in a pre-set directory. In another example, the parameter is a file path, so that the deployed SCM tool can merge the publication branch into the release branch and publish it to the online environment according to the command based on the file stored in the file path. The file path can point to a pre-set directory for storing user configuration files or to other directories; the file can be a user configuration file or other files. An example of the command for merging the publication branch into the release branch is shown as follows:

[0155] merge2release demo.yml publish

[0156] Here, merge2release is the command name of command 1, demo.yml is the file name of a user configuration file, which is the parameter of the command, and publish is the command name of command 2. When the parameter of the command is only a file name, the SCM tool defaults that the file is stored in a specific directory for storing user configuration files; when the parameter is a file path, the SCM tool obtains the file from the file path.

[0157] Through the deployment file, the SCM tool is configured to perform the following processing in response to receiving the command for merging the publication branch into the release branch:

[0158] A5, read the file specified by the parameter of the command to determine the application to which the merge branch operation is to be performed. When the parameter specifies a user configuration file, the command is executed for all applications to be versioned. Optionally, the file specified by the parameter can also be a file customized by the user during the versioning process, which specifies that the merge branch operation is to be performed only for certain applications.

[0159] B5, obtain the program code from the publication branch of the application determined in step A5.

[0160] C5, merge the program code obtained in step B5 into the determined release branch of the application.

[0161] D5, release the merged release branch to the online environment.

[0162] Optionally, the command for merging the release branch into the master branch can be configured in the form of command name + parameter. The command name refers to the command for merging the release branch into the master branch, and the parameter is used to specify the application to which the command is directed. Illustratively, the parameter can be the file name of the user configuration file, so that the deployed SCM tool can merge the release branch into the master branch based on the user configuration file stored in the pre-set directory according to the command. In another example, the parameter is a file path, so that the deployed SCM tool can merge the release branch into the master branch based on the file stored in the file path according to the command. The file path can point to a pre-set directory for storing user configuration files, or it can point to other directories; the file can be a user configuration file, or it can be another file. An example of the command for merging the release branch into the master branch is shown as follows:

[0163] merge2master demo.yml

[0164] merge2master is the command name, and demo.yml is the file name of the user configuration file, which is the parameter of the command. When the parameter of the command is only a file name, the SCM tool defaults that the file is stored in a specific directory for storing user configuration files; when the parameter is a file path, the SCM tool obtains the file from the file path.

[0165] By deploying the file, the SCM tool is configured to perform the following processing in response to receiving the command for merging the release branch into the master branch:

[0166] A6, read the file specified by the parameter of the command to determine the application to which the merge branch operation is to be performed. When the parameter specifies a user configuration file, the command is executed for all applications to which version iteration is to be performed. Optionally, the file specified by the parameter can also be a file customized by the user during the version iteration process, which specifies that the merge branch operation is to be performed only for certain applications.

[0167] B6, obtain the program code from the release branch of the application determined in step A6.

[0168] C6, merge the program code obtained in step B6 into the main branch of the determined application. In one example, the program code of the main branch of the application is saved in a remote repository, and the correspondence between each application and the corresponding remote repository storing the program code (i.e., the program code of the main branch) of the application is recorded in the application configuration file as described above. The corresponding remote repository can be determined according to the application configuration file in C6.

[0169] By configuring the file directory and the command as described above in the deployment file, and deploying the SCM tool on the nodes of the k8s cluster according to the deployment file, the deployed SCM tool can perform batch operations such as creating a new branch, creating a publishing branch, merging branches, etc. on the multiple applications to be versioned during the version iteration process of the multiple applications, simplifying the version iteration process of the multiple applications, and saving the time and effort of the developers and users.

[0170] In the above-described embodiments, generally, the main branch and the release branch of the application are existing, and the test branch and the publishing branch need to be recreated during the version iteration process. For example, the program code of the main branch and the release branch of the application is generally saved in a remote repository, such as a remote git repository, and the different branches of the application can be managed by git, and the SCM tool (the server on which the SCM tool is deployed) can obtain the program code of the application, automatically update the code, and push the code to the remote end by using local git commands.

[0171] By step S301, the SCM tool can be deployed on the k8s cluster where the multiple applications are located, and when version iteration is needed, step S302 is performed next.

[0172] S302, receiving and storing the configuration file to the location specified by the software configuration management tool.

[0173] The configuration file can be one or more of the user configuration file, the application configuration file, and the file recording the configuration of the remote repository and the key information mentioned above.

[0174] The configuration file is written by the user before starting the version iteration according to the version iteration task, and the specific description of the various configuration files can be referred to the description in step S301 above. The user stores or transmits the written configuration file to the SCM tool / the node on which the SCM tool is deployed. In one example, the SCM tool automatically stores the configuration file in the corresponding specified file directory agreed when the SCM tool is deployed when the configuration file is received, and the description of the file directory can be referred to step S301, which will not be described here.

[0175] Optionally, the configuration file can also be a user-defined file, and the location specified by the SCM tool can also refer to the location specified by the user.

[0176] S303, performing batch operations on the branches of the multiple applications for version iteration according to the configuration file by the software configuration management tool.

[0177] Exemplarily, the user can issue a user instruction of batch operation through a human-computer interaction interface of the SCM tool. For example, the user can input the SCM tool command as described above in the interface, or click a corresponding menu button on the interface to trigger the corresponding batch operation. The batch operation performed by the SCM tool in the version iteration process will be described below with reference to the following Figure 5 Figure 5 As shown in FIG. 6, it is assumed that there are multiple applications, among which applications 1-6 are to be subjected to version iteration.

[0178] In S501, the SCM tool creates a test branch for the multiple applications to be subjected to version iteration. Specifically, the SCM tool receives a user instruction of running a command of creating a test branch, wherein the file path of the configuration file is included as a parameter in the command of creating a test branch (when the file name of the user configuration file is specified as a parameter, the file path thereof is the default file directory, and only the file name needs to be specified without giving the file path), and executes the steps of A1-C1 described above.

[0179] In S502, code development or update is performed on the test branch, the test branch is tested in a test environment, and the program code is adjusted according to the test result until the test is passed.

[0180] In S503, the test is completed, and the test branch and the snapshot package after the program code is updated are obtained.

[0181] In S504, the SCM tool creates a publication branch for the multiple applications to be subjected to version iteration. Specifically, the SCM tool receives a user instruction of running a command of creating a publication branch, wherein the file path of the configuration file is included as a parameter in the command of creating a publication branch (when the file name of the user configuration file is specified as a parameter, the file path thereof is the default file directory, and only the file name needs to be specified without giving the file path), and executes the steps of A2-D2 described above.

[0182] In S505, the publication branch is tested in a pre-release environment, and if the test fails, the program code is adjusted according to the test result until the test is passed.

[0183] ​If the program code is adjusted in step S505 (assuming that the program codes of the applications 1-6 are all adjusted), a new jar package containing the adjusted program code needs to be republished to the dependent applications by the SCM tool in S506. Specifically, the SCM tool receives a user instruction of running the command of merging branches, in which the file path of the configuration file is included as a parameter in the command of creating a publishing branch (when the file name of the user configuration file is included as a parameter, the file path thereof is the default file directory, and only the file name needs to be specified without giving the file path thereof), and executes the steps of A3-C3 as described above. It can be understood that if the program code of the application is not adjusted after publishing the jar package, step S506 is not needed.

[0184] In S507, the publishing branch of the application to be versioned is merged into the release branch by the SCM tool. Specifically, the SCM tool receives a user instruction of running the command of merging branches, in which the file path of the configuration file is included as a parameter in the command (when the file name of the user configuration file is included as a parameter, the file path thereof is the default file directory, and only the file name needs to be specified without giving the file path thereof), and executes the steps of A4-C4 or A5-C5 as described above. Exemplarily, the command of merging branches can be in the form of command name + parameter 1 + parameter 2 + parameter 3 as described above, in which the command name is merge, parameter 1 is the file path of the configuration file, parameter 2 is the publishing branch, and parameter 3 is the release branch. Alternatively, the command of merging branches can also be in the form of command name 1 + parameter + command name 2 as described above, in which the command name 1 is merge2release, the command name 2 is publish, and the parameter is the file path of the configuration file.

[0185] In S508, the online verification of the release branch of the application to be versioned is completed.

[0186] In S509, the release branch of the application to be versioned is merged into the master branch by the SCM tool. Specifically, the SCM tool receives the user instruction of the command of merging the branch, and performs the steps of A4-C4 or A6-C6 described above, wherein the file path of the configuration file is contained as a parameter in the command (when the file name of the user configuration file is specified as a parameter, its file path is the default file directory, only the file name needs to be specified, and its file path does not need to be given). Exemplarily, the command of merging the branch can be in the form of command name+parameter 1+parameter 2+parameter 3 as described above, wherein the command name is merge, parameter 1 is the file path of the configuration file, parameter 2 is the release branch, and parameter 3 is the master branch. Alternatively, the command of merging the branch can also be in the form of command name+parameter as described above, wherein the command name is merge2master, and the parameter is the file path of the configuration file. Through step S509, the program code after version iteration can be updated to the remote repository.

[0187] As described above, the user instruction described in the above steps can be sent by the user to the SCM tool through the man-machine interactive interface of the SCM tool.

[0188] Exemplary Device

[0189] After introducing the method of the exemplary embodiment of the present application, next, with reference to Figure 6 The apparatus for version iteration of multiple applications of the exemplary embodiment of the present application is described. As shown in the figure, the apparatus 600 includes a deployment unit 610, a receiving unit 620, and a batch operation execution unit 630. Figure 6

[0190] The deployment unit 610 is configured to deploy a software configuration management tool on a k8s cluster where the multiple applications are located.

[0191] The receiving unit 620 is configured to receive and store a configuration file to a location specified by the software configuration management tool.

[0192] The batch operation execution unit 630 is configured to perform batch operations on branches of the multiple applications for version iteration by the software configuration management tool according to the configuration file.

[0193] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process and functions of the apparatus and each unit thereof described above can refer to the corresponding process in the foregoing method embodiments, which will not be described herein.

[0194] ​In addition, the embodiments of the present application further provide a computing device, which can include a memory and a processor, the memory storing a computer program executable on the processor, and the processor executing the computer program to enable the computing device to implement the method for version iteration of multi-application or the method for deploying a software configuration management tool to perform version iteration of multi-application as described above. The computing device can or can not have the structure as shown in Figure 1

[0195] In addition, as mentioned above, the method for version iteration of multi-application or the method for deploying a software configuration management tool to perform version iteration of multi-application or the device thereof according to the present application can also be implemented in the form of a computer readable storage medium, which will not be described herein again.

[0196] It should be noted that although several units or modules of the device are mentioned in the foregoing detailed description, such division is merely not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided into units embodied by multiple units.

[0197] Further, although the operations of the method of the present application are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all of the illustrated operations must be performed to achieve the desired results. On the contrary, the steps depicted in the flowcharts can be changed in execution order. Additionally or alternatively, some steps can be omitted, multiple steps can be combined into one step, and / or one step can be divided into multiple steps.

[0198] The use of the verb "comprise", "comprising", and words of similar meaning in the application file does not exclude the presence of elements other than those listed in the application file. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements.

[0199] Although the spirit and principles of the present application have been described with reference to several specific embodiments, it should be understood that the present application is not limited to the disclosed specific embodiments, and the division of aspects does not mean that the features in these aspects cannot be combined for the benefit. This division is only for the convenience of expression. The present application is intended to cover various modifications and equivalent arrangements included in the spirit and scope of the appended claims. The scope of the appended claims is the broadest interpretation in accordance with the widest possible interpretation, so as to include all such modifications and equivalent structures and functions.​

Claims

1. A method of version iteration for multiple applications, characterized by, The method comprises: deploying a software configuration management tool in the form of a Docker container on any node of a k8s cluster where the plurality of applications are located; receiving a configuration file and storing it in a location designated by the software configuration management tool; and performing batch operations on branches of the plurality of applications for version iteration by the software configuration management tool according to the configuration file; wherein the deploying a software configuration management tool in the form of a Docker container on any node of a k8s cluster where the plurality of applications are located comprises: receiving a Docker container-based deployment file; building an image using a Docker build command according to the deployment file; and deploying based on the image using a Docker run command; before the receiving a Docker container-based deployment file, the method further comprises: configuring a directory of the software configuration management tool in the deployment file, so that the deployed software configuration management tool has a specific file directory to store corresponding files used in the version iteration process, and configuring a command run by the deployed software configuration management tool for performing batch operations in the version iteration of the plurality of applications in the deployment file; the batch operation command comprises one or more of the following commands: a command for creating a test branch; a command for creating a publication branch; a command for re-publication; a command for merging branches.

2. The method of claim 1, wherein, the performing batch operations on branches of the plurality of applications for version iteration by the software configuration management tool according to the configuration file comprises: receiving a user instruction for running a command for creating a test branch, wherein the command for creating a test branch contains a file path of the configuration file as a parameter; reading the configuration file specified by the parameter of the command for creating a test branch to determine the application to be versioned; obtaining the program code of the application to be versioned; and creating a new test branch for the application to be versioned according to the obtained program code.

3. The method of claim 2, wherein, the configuration file comprises an application configuration file, wherein the application configuration file includes information of a remote repository where the program code of the plurality of applications is located, and the obtaining the program code of the application to be versioned comprises: searching for the program code of the application to be versioned in a file directory for locally storing the program code of the versioned application; if the program code of the application to be versioned is not found in the file directory, obtaining the application configuration file; determining the remote repository where the program code of the application to be versioned is located according to the application configuration file; obtaining the program code of the application to be versioned from the remote repository.

4. The method of claim 2, wherein, the performing batch operations on branches of the plurality of applications for version iteration by the software configuration management tool according to the configuration file further comprises: receiving a user instruction for running a command for creating a publication branch, wherein the command for creating a publication branch contains a file path of the configuration file as a parameter; reading the configuration file specified by the parameter of the command for creating a publication branch to determine the application to be versioned; obtaining program code from the new test branch of the application to be versioned; creating a publish branch for the application to be versioned according to the obtained program code; and publishing a snapshot package of the application to be versioned as an official jar package to dependent applications.

5. The method of claim 4, wherein, The batch operation of branches for version iteration of the multiple applications by the software configuration management tool according to the configuration file further comprises: receiving user instruction of running a re-publishing command, wherein the re-publishing command contains a file path of the configuration file as a parameter; reading the configuration file specified by the parameter of the re-publishing command to determine the application to be re-published; obtaining the latest program code of the application to be re-published; and generating a jar package of the application to be re-published according to the latest program code and re-publishing to dependent applications associated with the application to be re-published.

6. The method of claim 4, wherein, The batch operation of branches for version iteration of the multiple applications by the software configuration management tool according to the configuration file further comprises: receiving user instruction of running a merge branch command, wherein a file path of the configuration file is contained as a parameter in the merge branch command; reading the configuration file specified by the parameter of the merge branch command to determine the application to be operated by the merge branch; obtaining program code from the publish branch of the determined application to be operated by the merge branch; merging the obtained program code into the release branch of the determined application to be operated by the merge branch; and publishing the merged release branch to an online environment.

7. The method of claim 6, wherein, The batch operation of branches for version iteration of the multiple applications by the software configuration management tool according to the configuration file further comprises: receiving user instruction of running a merge branch command, wherein a file path of the configuration file is contained as a parameter in the merge branch command; reading the configuration file specified by the parameter of the merge branch command to determine the application to be operated by the merge branch; obtaining program code from the release branch of the determined application to be operated by the merge branch; and merging the obtained program code into the master branch of the determined application to be operated by the merge branch.

8. The method according to any one of claims 1-7, characterized in that, The deploying the software configuration management tool on the k8s cluster where the multiple applications are located comprises: deploying the software configuration management tool on any node of the k8s cluster where the multiple applications are located.

9. The method of claim 1, wherein, Before the receiving the deployment file based on the Docker container, further comprising: configuring the deployment file so that the software configuration management tool after deployment comprises one or more of the following file directories: a file directory for storing user configuration files; a file directory for locally storing program code of the iterated application; a file directory for storing information about a remote repository, wherein the remote repository stores program code of the multiple applications; a file directory for storing application configuration files.

10. The method of claim 1, wherein, Before the receiving the deployment file based on the Docker container, further comprising: The deployment file is configured to enable the software configuration management tool, after deployment, to run the commands of the bulk operation.

11. A computing device comprising a memory and a processor, the memory having stored therein a computer program executable on the processor, the computer program comprising: The computer program, when executed by the processor, causes the computing apparatus to implement the method for version iteration of multiple applications according to any one of claims 1 to 10.

12. A computer-readable storage medium, the computer-readable storage medium storing a computer program, characterized in that, The computer program, when executed by the processor, causes the processor to implement the method for version iteration of multiple applications according to any one of claims 1 to 10.

Images