A method and system for software continuous integration and release in a global multi-network environment

Abstract

The present invention discloses a method and system for software continuous integration and release in a global multi-network environment. The method includes the following steps: Deploying gitlab service, application scheduler, and NAS storage service in the same network environment; During the compilation stage, the task executor associates the program source code on the gitlab service with the compilation configuration file stored in the NAS storage and compiles it into an executable application package for caching; During the image generation stage, the task executor generates an image with the name of the application package and pushes it to the main image repository; According to the synchronization policy configured in the main image repository, it is synchronously replicated to other slave image repositories deployed in different network environments in real time. The synchronized content includes the image with the name of the generated application package; During the software release stage, the task executor searches for the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by the release environment name in the associated NAS storage, then loads its API, makes a remote call, fills the variables defined in the application environment into the software release template, and performs software release.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and particularly relates to a method and system for software continuous integration and release in a global multi-network environment. Background Art

[0002] Nowadays, more and more domestic enterprises' Internet businesses are carrying out overseas services. In the operation and maintenance link, the original network services deployed only in China are facing the business requirements of global node deployment and global node release. In the prior art, for the release and deployment of such services distributed in various regions, multiple network areas, and multiple environments around the world, each Internet enterprise generally deploys a set of Jenkins in each region, which exist in isolation from each other, making management very difficult, extremely inefficient, and wasting machine resources.

[0003] For example, the code repositories of general enterprises are all in China (if there are multiple code repositories, management becomes more complex). To solve the problems of global compilation and release, although Jenkins can be deployed in various regions around the world, during the compilation process, code needs to be pulled from the source code repository. On the one hand, there are security issues with the code repository, and on the other hand, the network latency caused by cross-border access is also very obvious. A bigger problem is that the artifact repositories generated by each isolated Jenkins also exist independently, and the management cost is very high. This design defect is very large. Therefore, for the existence of overseas node environments, even a simple release often takes a long time to complete. Because each Jenkins compilation host exists independently and cannot form a linkage, a project that originally only needs to be compiled once has to be independently and repeatedly compiled multiple times because it needs to be deployed to multiple global environments, making it difficult for the software continuous integration (CI) / continuous deployment (CD) process to meet the release and deployment scenarios of such global services, dragging down the development iteration speed and seriously affecting development efficiency. In short, there are many problems, such as: (1) Multiple sets of independent Jenkins compilation hosts waste resources and require dedicated personnel for configuration and management; (2) There is a problem of pulling code from the code repository across networks, which poses a certain network security risk to the code repository. (3) Because there are multiple independent compilation hosts, the artifact repositories are independent of each other, and the management cost is very high. (4) A project is repeatedly compiled multiple times, wasting time. (5) Adding a new network area or a new environment makes the expansion process complex. Summary of the Invention

[0004] In view of the above problems, the present invention provides a method and system for software continuous integration and release in a global multi-network environment, which can be used to achieve multiple deployments across network environments with a single code compilation.

[0005] To solve the above technical problems, the present invention adopts the following technical solutions:

[0006] In a first aspect, an embodiment of the present invention provides a method for software continuous integration and release in a global multi-network environment, characterized by including the following steps:

[0007] Deploy a gitlab service, an application scheduler, and a NAS storage service in the same network environment. A task executor is set on the application scheduler, and configuration files are stored on the NAS storage service; the configuration files include compilation configuration files, Dockerfile files, kubeconfig, and software release templates;

[0008] In the compilation stage, the task executor associates the program source code on the gitlab service with the compilation configuration file stored in the NAS and compiles it into an executable application package for caching;

[0009] In the image generation stage, the application package is combined with a Dockerfile file associated on the NAS storage service, and the task executor generates an image with the name of the application package and pushes it to the main image repository; according to the synchronization policy configured in the main image repository, it is synchronously replicated to other slave image repositories deployed in different network environments in real time, and the synchronization content includes the image with the name of the generated application package;

[0010] In the software release stage, the task executor searches for the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by the release environment name in the associated NAS storage, then loads its API, makes a remote call, fills the variables defined in the application environment into the software release template, and performs software release.

[0011] In a possible implementation, the application package is a jar or war package.

[0012] In a possible implementation, the application scheduler is Kubernetes.

[0013] In a possible implementation, the storage structure of the template file is as follows: under the Kubernetes folder of the NAS storage service, each Kubernetes cluster folder is stored, under the cluster folder, the Namespace folder of the cluster is stored, and under the Namespace folder, the orchestration file is stored, and there are hidden template files under the Kubernetes resource folder.

[0014] In a possible implementation, the content of the configuration file includes the deployed network area, API call configuration, and the pull address of the image repository.

[0015] In a second aspect, an embodiment of the present invention provides a system for continuous integration and release of software in a global multi-network environment, including a GitLab service, an application scheduler, a NAS storage service, a main image repository deployed in the same network environment, and a slave image repository in a different network.

[0016] The NAS storage service is used to store configuration files; the configuration files include compilation configuration files, Dockerfile files, kubeconfig, and software release templates.

[0017] A task executor is further set on the application scheduler, and the task executor is used to compile the program source code on the GitLab service in association with the compilation configuration file stored in the NAS into an executable application package for caching.

[0018] The main image repository is used to receive the application package and combine it with a Dockerfile file associated on the NAS storage service to generate an image with the name of the application package by the task executor; according to the synchronization policy configured in the main image repository, it is synchronously to other slave image repositories deployed in different network environments in real time, and the synchronization content includes the generated image with the name of the application package.

[0019] The task executor is used to find the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by the release environment name in the associated NAS storage, then load its API, make a remote call, fill the variables defined in the application environment into the software release template, and perform software release.

[0020] In a possible implementation manner, the application package is a jar or war package.

[0021] In a possible implementation manner, the application scheduler is Kubernetes.

[0022] In a possible implementation manner, the storage structure of the template file is as follows: under the Kubernetes folder of the NAS storage service, each Kubernetes cluster folder is stored, under the cluster folder, the Namespace folder of the cluster is stored, and under the Namespace folder, the orchestration file is stored, and there are hidden template files under the Kubernetes resource folder.

[0023] In a possible implementation manner, the content of the configuration file includes the deployed network area, API call configuration, and the pull address of the image repository.

[0024] In a third aspect, an embodiment of the present invention provides an electronic device, where the electronic device includes:

[0025] A processor and a memory storing computer-executable instructions, which when executed cause the processor to execute a method for software continuous integration and release according to the global multi-network environment described in any one of the above.

[0026] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by a processor, a method for software continuous integration and release of the global multi-network environment described in any one of the above is implemented.

[0027] Adopting the present invention has the following beneficial effects:

[0028] (1) Only one set of compilation environment is required, and all compilation actions are completed in one set of compilation environment. There is no problem of pulling code across networks. After compilation, the generated image is stored in the main image repository and then synchronized to each slave image repository globally.

[0029] (2) It can achieve multi-environment deployment with one compilation, and can release to a single environment at one time, or release multiple environments in parallel, which is very flexible.

[0030] (3) Adding new environments / network nodes is very simple to expand.

[0031] (4) Unified management without dispersion. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 is a flowchart of the steps of the method for software continuous integration and release of the global multi-network environment according to the embodiment of the present invention;

[0033] Figure 2 is a schematic structural diagram of the system for software continuous integration and release of the global multi-network environment according to the embodiment of the present invention;

[0034] Figure 3 is a schematic block diagram of the principle of the electronic device according to the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0035] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0036] Refer to Figure 1 , as shown in the flowchart of a method for software continuous integration and release of a global multi-network environment according to an embodiment of the present invention, including the following steps:

[0037] S10. Deploy the GitLab service, the application scheduler, and the NAS storage service in the same network environment. A task executor is set on the application scheduler, and configuration files are stored on the NAS storage service. The configuration files include compilation configuration files, Dockerfile files, kubeconfig, and software release templates.

[0038] S20. In the compilation stage, the task executor compiles the program source code on the GitLab service associated with the compilation configuration file stored on the NAS into an executable application package for caching.

[0039] S30. In the image generation stage, the application package is combined with a Dockerfile file associated on the NAS storage service, and the task executor generates an image with the name of the application package and pushes it to the main image repository. According to the synchronization policy configured in the main image repository, it is synchronously replicated to other slave image repositories deployed in different network environments in real time. The synchronized content includes the image with the name of the generated application package.

[0040] S40. In the software release stage, the task executor searches for the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by the release environment name in the associated NAS storage, then loads its API, makes a remote call, fills the variables defined in the application environment into the software release template, and performs software release.

[0041] Through the method of software continuous integration and release in the above - set global multi - network environment, the program source code only needs to be edited once in a set of compilation environments. After generating the executable application package, it is generated into an image file and pushed to the main image repository, and at the same time, the image file is synchronously replicated to the slave image repositories set at different network nodes globally. When software deployment is required, the task executor searches for the API call configuration belonging to the corresponding release environment of the application, as well as the variables defined in the application environment, fills the template, and performs software release.

[0042] In an embodiment of the present invention, the application package is a jar or war package. A jar package allows multiple files to be packaged so that they can be used as libraries, plugins, or any type of application program. A war package is a package for JavaWeb programs. The war package includes class files compiled from the written code, configuration files, and all website pages.

[0043] In one embodiment of the present invention, the application scheduler is Kubernetes, also known as K8S. The essence of K8S is a group of server clusters, which can run specific programs on each node of the cluster to manage the containers in the nodes. In the automated application scenario of resource management, it has many advantages: (1) It can quickly self-repair. Once a container crashes, a new container can be quickly started in about 1 second. (2) It can scale elastically and automatically adjust the number of running containers in the cluster according to needs. (3) It has an automatic service discovery function, and a service can find the services it depends on in an automatic discovery form. (4) Load balancing: If a service starts multiple containers, it can automatically achieve load balancing of requests. (5) It can automatically create storage volumes according to the needs of the containers themselves.

[0044] The template file storage structure in a method for software continuous integration and release in a global multi-network environment according to an embodiment of the present invention is as follows: Under the Kubernetes folder of the NAS storage service, each Kubernetes cluster folder is stored. Under the cluster folder, the Namespace folder of the cluster is stored. Under the Namespace folder, the orchestration files are stored. Among them, there are hidden template files.*.tmpl under the Kubernetes resource folder. Such template files are the core files for management. That is to say, in the continuous improvement process, the creation of resources of each project in Kubernetes depends on these basic templates planned. If parameters need to be added or deleted in terms of business, it is also achieved by updating the templates. The Kubernetes resource folder can include configmap (configuration item), cronjob (scheduled task), deployment (stateless service), ingress (routing service), service (proxy service), secret (confidential configuration), and statefulset (stateful service), etc.

[0045] The content of the configuration file in a method for software continuous integration and release in a global multi-network environment according to an embodiment of the present invention includes the deployed network area, API call configuration, and the pull address of the image repository.

[0046] Corresponding to the method embodiment, see Figure 2As shown in the figure, an embodiment of the present invention provides a system for software continuous integration and release in a global multi-network environment, including a GitLab service, an application scheduler, a NAS storage service, and a main image repository deployed in the same network environment, as well as a slave image repository in different networks. The NAS storage service is used to store configuration files; the configuration files include compilation configuration files, Dockerfile files, kubeconfig, and templates for software release; a task executor is further set on the application scheduler, and the task executor is used to compile the program source code on the GitLab service in association with the compilation configuration files stored in the NAS into an executable application package for caching; the main image repository is used to receive the application package and combine it with a Dockerfile file associated on the NAS storage service to generate an image with the name of the application package generated by the task executor; according to the synchronization policy configured in the main image repository, it is synchronously replicated to other slave image repositories deployed in different network environments in real time, and the synchronized content includes the image with the name of the generated application package; the task executor is used to find the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application in the associated NAS storage by the release environment name, then load its API, make a remote call, fill the variables defined in the application environment into the software release template, and perform software release.

[0047] Through the system for software continuous integration and release in the global multi-network environment set above, the program source code only needs to be edited once in a set of compilation environments. After generating an image file from the edited executable application package, it is pushed to the main image repository, and at the same time, the image file is synchronously replicated to the slave image repositories set at different network nodes globally. When software deployment is required, the task executor finds the API call configuration belonging to the corresponding release environment of the application, as well as the variables defined in the application environment, fills the template, and performs software release.

[0048] In an embodiment of the present invention, the application package is a JAR or WAR package. The JAR package allows multiple files to be packaged so that they can be used as libraries, plugins, or any type of application. The WAR package is a package for JavaWeb programs. The WAR package includes class files compiled from the written code, configuration files, and all website pages.

[0049] In an embodiment of the present invention, the application scheduler is Kubernetes, also known as K8S. The essence of K8S is a group of server clusters, which can run specific programs on each node of the cluster to manage the containers in the nodes. In the automated application scenario of resource management, it has many advantages: (1) It can quickly self-repair. Once a container crashes, a new container can be quickly started in about 1 second. (2) It can be elastically scaled, automatically adjusting the number of running containers in the cluster according to needs. (3) It has an automatic service discovery function, and a service can find the services it depends on in an automatic discovery form. (4) Load balancing: If a service starts multiple containers, it can automatically achieve load balancing of requests. (5) It can automatically create storage volumes according to the needs of the containers themselves.

[0050] The template file storage structure in a software continuous integration and release system with a global multi-network environment in an embodiment of the present invention is as follows: Under the Kubernetes folder of the NAS storage service, each Kubernetes cluster folder is stored. Under the cluster folder, the Namespace folder of the cluster is stored. Under the Namespace folder, the orchestration files are stored. Among them, there are hidden template files.*.tmpl under the Kubernetes resource folder. Such template files are the core files for management. That is to say, in the continuous improvement process, the creation of resources of each project in Kubernetes depends on these basic templates planned. If parameters need to be added or deleted in business, it is also achieved by updating the templates. The Kubernetes resource folder can include configmap (configuration item), cronjob (timed task), deployment (stateless service), ingress (routing service), service (proxy service), secret (confidential configuration), and statefulset (stateful service), etc.

[0051] The content of the configuration file in a software continuous integration and release system with a global multi-network environment in an embodiment of the present invention includes the deployed network area, API call configuration, and the pull address of the image repository.

[0052] To make the implementation process of the embodiments of the present invention clearer, taking the business being deployed in 5 regions globally, namely Mainland China, Hong Kong, China, the United States, Europe, and India as an example, the Kubernetes service clusters are distributed in these locations. The network where the code repository gitlab is located is in Mainland China (such as the Hangzhou node), so the planned gitlab-ci (the task executor is also in the Hangzhou node). Since the code needs to be downloaded from the code repository in each edge stage of CI / CD, considering security and download speed, it is best practice to deploy a task executor and the code repository in the same network area. At the same time, the configured NAS storage service is also in this environment and is automatically mounted and associated in the instances of the task executor. For example, to publish a Java project business-accoun to the dev environment, on the pipeline page of gitlab, pass a variable NS = dev and click publish, and the CI / CD process will start immediately:

[0053] In the first stage, the task executor runs the compilation task, pulls the code, loads the compilation configuration files in the NAS disk, and finally generates a package named business-accoun.jar and caches it temporarily;

[0054] In the second stage, in the task executor, use the business-accoun.jar file cached in the first stage and combine it with the mirror configuration file Dockerfile in the NAS disk to generate a software package mirror business-accoun:18cb517f (mirror version) of this application;

[0055] In the third stage, in the task executor, according to the passed NS = dev, find the Kubernetes directory belonging to the dev environment, then load its configuration kubeconfig, load some variable parameters (such as mirror version, environment variables, base image, number of replicas, memory configuration, etc.) to fill the application deployment template associated with this kubernetes, and then remotely call the target kubernetes API to complete the kubernetes deployment of the dev. If the location of dev is the United States at this time, the software release and deployment will be in the United States.

[0056] Refer to Figure 3 FIG. is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. Figure 3The displayed electronic device 300 is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of the present invention. The electronic device 300 is presented in the form of a general computing device. The components of the electronic device 300 may include, but are not limited to: at least one processing unit 310, a bus connecting different device components (including the storage unit 320 and the processing unit 310), an I / O interface 330, a display unit 340, etc. Among them, the storage unit stores program codes, and the program codes can be executed by the processing unit 310, so that the processing unit 310 executes the steps according to various exemplary embodiments of the present invention described in the method part of the software continuous integration and release in the above global multi-network environment. For example, the processing unit 310 may execute the following steps:

[0057] S10, Deploy the gitlab service, the application scheduler, and the NAS storage service in the same network environment. There is a task executor on the application scheduler, and configuration files are stored on the NAS storage service; the configuration files include compilation configuration files, Dockerfile files, kubeconfig, and software release templates;

[0058] S20, In the compilation stage, the task executor associates the program source code on the gitlab service with the compilation configuration file stored in the NAS and compiles it into an executable application package for caching;

[0059] S30, In the image generation stage, the application package is combined with a Dockerfile file associated on the NAS storage service, and the task executor generates an image with the name of the application package and pushes it to the main image repository; according to the synchronization policy configured in the main image repository, it is synchronously updated to other slave image repositories deployed in different network environments in real time, and the synchronized content includes the image with the name of the generated application package;

[0060] S40, In the software release stage, the task executor searches for the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by the release environment name in the associated NAS storage, then loads its API, makes a remote call, fills the variables defined in the application environment into the software release template, and performs software release.

[0061] The storage unit 320 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 3201 and / or a cache storage unit 3202, and may further include a read-only storage unit (ROM) 3203. The storage unit 320 may also include a program / utilities having a set (at least one) of program modules. The program modules include, but are not limited to: an operating device, one or more application programs, other program modules, and program data. Each or some combination of these examples may include the implementation of the network environment.

[0062] The bus can represent one or more of several bus architectures, including a memory unit bus or a memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of the multiple bus architectures.

[0063] The electronic device 300 can also communicate with one or more external devices 400 (such as a keyboard, a pointing device, a Bluetooth device, etc.), and can also communicate with one or more devices that enable a user to interact with the electronic device 300, and / or communicate with any device (such as a router, a modem, etc.) that enables the electronic device 300 to communicate with one or more other computing devices. Such communication can be carried out through an input / output (I / O) interface. Moreover, the electronic device 300 can also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network (the Internet)) through the network adapter 350. The network adapter 350 can communicate with other modules of the electronic device 300 through the bus. The electronic device 300 displays the information that needs to be displayed through the display unit 340. It should be understood that although Figure 3 not shown in the figure, other hardware and / or software modules can be used in combination with the electronic device 300, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID devices, tape drives, and data backup storage devices, etc.

[0064] Through the description of the above embodiments, those skilled in the art can easily understand that the exemplary embodiments described in the present invention can be implemented by software, or can be implemented by the way of software combined with necessary hardware. Therefore, the technical solutions according to the embodiments of the present invention can be embodied in the form of a software product, and the software product can be stored in a computer-readable storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the method for software continuous integration and release in the global multi-network environment according to the present invention. When the computer program is executed by a data processing device, the computer-readable medium can implement the above method for software continuous integration and release in the global multi-network environment according to the present invention, that is, it includes the following steps:

[0065] S10, deploy the gitlab service, the application scheduler, and the NAS storage service in the same network environment. There is a task executor set on the application scheduler, and configuration files are stored on the NAS storage service; the configuration files include compilation configuration files, Dockerfile files, kubeconfig, and templates for software release;

[0066] S20. During the compilation stage, the task executor compiles the program source code on the GitLab service with the compilation configuration file stored in the NAS storage into an executable application package for caching.

[0067] S30. During the image generation stage, the application package combines with a Dockerfile file associated on the NAS storage service. The task executor generates an image with the name of the application package and pushes it to the main image repository. According to the synchronization policy configured in the main image repository, it is synchronously replicated to other slave image repositories deployed in different network environments in real time. The synchronized content includes the image with the generated application package name.

[0068] S40. During the software release stage, the task executor searches for the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by the release environment name in the associated NAS storage, then loads its API and makes a remote call to fill the variables defined in the application environment into the software release template for software release.

[0069] A computer program may be stored on one or more computer-readable media. The computer-readable media may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor device, apparatus, or device, or any combination of the above. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, 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 above.

[0070] The computer-readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries the readable program code. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable storage medium may also be any readable medium other than the readable storage medium, which can send, propagate, or transmit a program used by or in conjunction with an instruction execution device, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination of the above.

[0071] The program code for performing the operations of the embodiments of the present invention can be written in any combination of one or more programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, executed as a stand-alone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (e.g., using an Internet service provider to connect through the Internet).

[0072] In summary, the present invention can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. Those skilled in the art should understand that general-purpose data processing devices such as microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and a computer program product) for performing part or all of the methods described herein. Such a program implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0073] It should be understood that the exemplary embodiments described herein are illustrative and not restrictive. Although one or more embodiments of the present invention have been described in conjunction with the accompanying drawings, those of ordinary skill in the art should understand that various changes in form and detail can be made without departing from the spirit and scope of the present invention as defined by the appended claims.

Claims

1. A method for continuous integration and release of software in a global multi-network environment, characterized in that, It includes the following steps: Deploy the gitlab service, application scheduler, and NAS storage service in the same network environment. There is a task executor set on the application scheduler, and configuration files are stored on the NAS storage service; the configuration files include compilation configuration files, Dockerfile files, kubeconfig, and software release templates; In the compilation stage, the task executor compiles the program source code on the gitlab service associated with the compilation configuration file stored in the NAS storage into an executable application package for caching; In the image generation stage, the application package combines with a Dockerfile file associated on the NAS storage service, and the task executor generates an image with the name of the application package and pushes it to the main image repository; according to the synchronization policy configured in the main image repository, it is synchronously to other slave image repositories deployed in different network environments in real time, and the synchronization content includes the generated image with the name of the application package; In the software release stage, the task executor searches for the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by the release environment name in the associated NAS storage, then loads its API, makes a remote call, fills the variables defined in the application environment into the software release template, and performs software release; Wherein the application scheduler is Kubernetes; The storage structure of the template file is as follows: under the Kubernetes folder of the NAS storage service, each Kubernetes cluster folder is stored, under the cluster folder, the Namespace folder of the cluster is stored, and under the Namespace folder, the orchestration file is stored, and there are hidden template files under the Kubernetes resource folder.

2. The method for software continuous integration and release in a global multi-network environment according to claim 1, wherein, The application package is a jar or war package.

3. The method for continuous integration and release of software in a global multi-network environment according to claim 1, wherein, The content of the configuration file includes the deployed network area, API call configuration, and the pull address of the image repository.

4. A system for continuous integration and release of software in a global multi-network environment, characterized in that, It includes the gitlab service, application scheduler, NAS storage service, and main image repository deployed in the same network environment, as well as slave image repositories in different networks, The NAS storage service is used to store configuration files; the configuration files include compilation configuration files, Dockerfile files, kubeconfig, and software release templates; A task executor is set on the application scheduler, and the task executor is used to compile the program source code on the gitlab service associated with the compilation configuration file stored in the NAS storage into an executable application package for caching; The main image repository is used to receive the image generated by the task executor with the name of the application package combined with a Dockerfile file associated on the NAS storage service; According to the synchronization policy configured in the main image repository, it is synchronously to other slave image repositories deployed in different network environments in real time, and the synchronization content includes the generated image with the name of the application package; The task executor is used to find the Kubernetes configuration kubeconfig belonging to the corresponding release environment of the application by publishing the environment name in the associated NAS storage, then load its API, make a remote call, fill the variables defined in the application environment into the software release template, and perform software release; wherein the application scheduler is Kubernetes; The storage structure of the template file is as follows: under the Kubernetes folder of the NAS storage service, each Kubernetes cluster folder is stored, under the cluster folder, the Namespace folder of the cluster is stored, and under the Namespace folder, the orchestration file is stored. There are hidden template files under the Kubernetes resource folder.

5. The system for continuous integration and release of software in a global multi-network environment according to claim 4, characterized in that, The application package is a jar or war package.

6. The system for software continuous integration and release in a global multi-network environment according to claim 4, characterized in that, The content of the configuration file includes the deployed network area, the API call configuration, and the pull address of the image repository.

7. An electronic device, wherein, The electronic device includes: a processor and a memory storing computer-executable instructions, and the executable instructions, when executed, cause the processor to execute the method for software continuous integration and release in a global multi-network environment according to any one of claims 1-3.

8. A computer-readable storage medium, wherein, The computer-readable storage medium stores one or more programs, and the one or more programs, when executed by a processor, implement the method for software continuous integration and release in a global multi-network environment according to any one of claims 1-3.

Images