Assembly line publishing method and system supporting multiple deployment modes based on agile development

Abstract

The invention discloses an assembly line publishing method and system supporting multiple deployment modes based on agile development, the system comprises a basic software installation and deployment module, an application configuration module and an assembly line execution module, the basic software installation and deployment module is used for installation of Gitlab, Jenkins, Jenkins plug-ins, docker, kubectl and continuous delivery micro-applications; the application configuration module is used for continuously delivering configuration of related applications, assembly lines, servers, K8S clusters, mirror image warehouses and characteristic branches in the micro-applications; the assembly line execution module is used for submitting and releasing characteristic branches in the continuous delivery micro-application and operating an assembly line; the user does not need to concern about different deployment packages or mirror images caused by difference of operating environments such as system testing and production and the complexity of manual compiling, deployment and release, so that the operation risk is reduced, the deployment time is shortened, the workload of operation and maintenance personnel is reduced, the release efficiency of system update deployment is improved, and the time and labor cost is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software application deployment, and in particular to a pipeline publishing method and system based on agile development supporting multiple deployment modes. Background Art

[0002] With the advancement of Internet technology, the maturity of containerization technology and the popularization of microservice architecture, we have gradually transitioned from traditional deployment to the era of containerized deployment. As the deployment method of applications has changed, the content of deployment has increased, and the version iteration cycle has shortened, R&D and operation and maintenance personnel need to learn and master new technologies and quickly deploy and update applications to adapt to the agile development model of applications. However, in reality, an application deployment method must support containerized deployment while also being compatible with traditional deployment methods for the following reasons: 1. With the advancement of technology, containerized deployment has become a trend, but traditional deployment methods are still widely used, especially in some old systems or specific scenarios. Therefore, while supporting containerized deployment, it is also necessary to be compatible with traditional deployment methods to meet the needs of different system development iterations.

[0003] 2. Although containerized deployment provides higher flexibility and scalability, in some cases, traditional deployment methods may be more suitable, such as for some applications with extremely high performance requirements or requiring specific configurations. Therefore, compatibility with traditional deployment methods can increase the flexibility and scalability of the system.

[0004] 3. Many existing applications and systems are developed based on traditional deployment methods. In particular, the power industry started informatization relatively early, and some long-used information system architectures are relatively old. If traditional deployment methods are completely abandoned, these applications and systems may not be able to iterate and update normally. Therefore, while supporting containerized deployment, it is also necessary to be compatible with traditional deployment methods to ensure system stability and compatibility.

[0005] 4. Although containerized deployment can reduce hardware and operation and maintenance costs and improve resource utilization, for some small systems, containerized deployment is a waste of resources and budget. Therefore, compatibility with traditional deployment methods can meet the needs of these systems and reduce their costs.

[0006] In summary, supporting containerized deployment and being compatible with traditional deployment methods can meet the release requirements of different systems, improve the flexibility and scalability of the system, and ensure the stability and compatibility of the enterprise R&D system. However, the existing technical reserves of containerized deployment have certain shortcomings, such as: high learning costs, requiring developers and operation and maintenance personnel to learn docker and K8S related instructions, and learning mirror production and pod deployment, etc., which increases the learning cost of operators; long deployment cycles, more application service modules, and more operating environments and application packages that need to be deployed, which increases the workload of operation and maintenance personnel and the release efficiency of system update deployment is low. Summary of the invention

[0007] The main technical problem solved by the present invention is to provide a pipeline publishing method and system based on agile development and supporting multiple deployment modes, so as to solve the problems of high learning cost and long deployment cycle existing in the existing containerized deployment technology.

[0008] In order to solve the above technical problems, a technical solution adopted by the present invention is to provide a pipeline release method based on agile development and supporting multiple deployment modes, which is characterized by comprising the following steps: Step 1: Basic software installation and deployment: Under a single network condition, plan at least 3 servers, one with Gitlab installed as the source address of the code repository; one with continuous delivery micro-applications, Jenkins, and Jenkins plug-ins installed as the program compilation execution node. By creating continuous integration tasks, call plug-ins to complete program compilation and push the output to the server or push the container image to the image repository; one with docker and kubectl installed as the containerization-related execution node to build docker images and create, replace, and remotely start and stop K8S cluster pods; Step 2: Application configuration: Complete the maintenance of basic information including the application name, determine the development mode, and the source address of the Gitlab code repository; Step 3: Server resource configuration: As the target destination for compiled output in the traditional deployment mode, complete the maintenance of server resource name, IP address, port, user name, and password information, and synchronize them to SSH Servers in Jenkins; Step 4: Image repository resource configuration: As the destination for pushing the image generated in the containerized deployment mode, complete the maintenance of the image repository resource name, URL address, user name, and password information; Step 5. K8S cluster configuration: As a carrier for program release in containerized deployment mode, complete the maintenance of cluster name, Master address and Config file, and support native K8S clusters and mainstream container scheduling platforms such as Rancher and KubeSphere; Step 6: Application environment configuration: For the traditional deployment mode, associate the application with the server resources configured in step 3 as the environment for application release in the traditional deployment mode. At the same time, write a deployment script, and maintain the commands for starting and stopping the application after the output is released to the server in the deployment script, so as to facilitate the subsequent application pipeline to compile and release the output; Step 7. Create a new configuration pipeline: Create a continuous delivery pipeline for the application, set different task nodes in the pipeline, and most importantly, build deployment type nodes to ensure that the code is compiled and released. Different types of process tasks on the pipeline are implemented through different plug-ins. Step 8: Pipeline execution: Developers write business application code and provide the scripts and configuration files required for compiling and building the application code, upload it to the Gitlab code repository, and execute it manually, periodically, or automatically through the pipeline to deploy and release the application.

[0009] Furthermore, in the step 2, the development mode includes a free mode and a branch mode.

[0010] Furthermore, in step seven, the pipeline node types include: Build traditional deployment: Build and package in the traditional deployment mode, and deploy the build results to the configured environment for operation; Build containerized deployment: Build and package in containerized deployment mode, and build the build results into Docker images and deploy them to the configured environment or K8S cluster for operation; Manual checkpoints: tasks that require manual judgment to determine whether they are OK, used as checkpoints for manual testing and security review processes on the assembly line; Merge trunk: The operation of merging the feature branch into the master.

[0011] Furthermore, in the case of traditional deployment mode, configuration information including package tags, build commands, build package output, and deployment script files needs to be provided; Package labels are used to distinguish packages for different purposes, such as packages deployed to the test environment and packages deployed to the production environment. The name of the package label is passed into the build process as the value of the environment variable ENV_LABEL; The build command needs to be filled in with the command executed during the build. If a script is required, fill in the relative path of the script with the current project directory as the root directory; The usage of build package output and deployment script files is similar to that of build commands. Fill in the relative path of the build package and script files with the current project directory as the root directory.

[0012] Furthermore, in the case of containerized deployment mode, configuration information including DockerFile path, image repository, image address, image tag, K8S cluster, and deployment configuration file needs to be provided; The DockerFile path is the relative path of the DockerFile with the current project directory as the root directory; The image repository, image address, and image tag refer to the URL address of the Registry configured and authorized in step 4 and the Docker repo to be pushed after the Docker build is completed; K8S cluster refers to the Kubernates cluster that has been configured and authorized in step 5; There are two ways to select the deployment configuration file. For development and operation personnel with a high knowledge of Docker and K8S, choose the "custom path" method, place the written deployment YAML file in the code repository, and directly fill in the path relative to the root directory; for development and operation personnel with a low knowledge of Docker and K8S, configure the deployment file through the system's built-in templates.

[0013] Furthermore, in step eight, the development mode adopts the branch mode, and the user needs to manually submit the branch to be released before running the pipeline; after the build deployment, the main branch merge operation is performed through the merge trunk type node.

[0014] Furthermore, in step eight, the development mode adopts the free mode, and the execution pipeline is automatically triggered by configuring the cron expression or by the Gitlab Webhook.

[0015] Furthermore, in step eight, in the case of a traditional deployment mode, the constructed program package is uploaded to a configured server resource for downloading or publishing.

[0016] Furthermore, in step eight, in the case of containerized deployment mode, after uploading the constructed Docker image to the configured image repository, it is pulled to the server or K8S cluster to create, replace, and start and stop pods.

[0017] In order to solve the above technical problems, a technical solution adopted by the present invention is to provide a pipeline release system based on agile development and supporting multiple deployment modes, characterized in that it includes a basic software installation and deployment module, an application configuration module and a pipeline execution module, wherein: Basic software installation and deployment module: used for the installation of Gitlab, Jenkins, Jenkins plug-ins, docker, kubectl, and continuous delivery micro-applications; Application configuration module: used for the configuration of related applications, pipelines, servers, K8S clusters, image repositories, and feature branches in continuous delivery of micro-applications, including: newly configured applications, servers, K8S clusters, image repositories, associated release environments in applications, and newly configured pipelines and feature branches; Pipeline execution module: used for the continuous delivery of feature branch submission and release and pipeline operation in micro-applications, including feature branch submission, compilation and release, manual nodes, and trunk merging.

[0018] The beneficial effects of the present invention are: The present invention realizes the deployment of application system in the form of Web visual page, and realizes the process of pulling, compiling, packaging and deploying the code from the project by integrating the most basic compilation task of Jenkins. Users do not need to worry about the differences in operating environments such as system testing and production, which lead to different deployment packages or images, as well as the complexity of manual compilation, deployment and release, thereby reducing operation risks and shortening deployment time. The present invention supports containerized deployment while supporting traditional deployment methods. During deployment, the application is built into a docker image, and the image is deployed to the K8S cluster, which can shield the differences in operating systems and reflect the advantages of load balancing and fault self-healing of the application system under the containerized deployment method. A private image warehouse is provided, and the image package of the application is automatically uploaded to the private warehouse, which is convenient for system migration and expansion. The component interfaces such as Jenkins, docker and K8S are integrated, and the corresponding resources can be directly configured and called on the Web visual interface to realize the release and management of applications, thereby simplifying the operation, reducing the workload of operation and maintenance personnel, and improving the release efficiency of system update deployment, thereby reducing time and labor costs.

[0019] In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the following specifically cites preferred embodiments and describes them in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only two of the drawings in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0021] Figure 1 It is a flowchart of the application method; Figure 2 This is the architecture diagram of this application system. DETAILED DESCRIPTION

[0022] In order to facilitate the understanding of the present invention, the present invention is described in more detail below in conjunction with the accompanying drawings and specific embodiments. Preferred embodiments of the present invention are provided in the accompanying drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described in this specification. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present invention more thorough and comprehensive.

[0023] It should be noted that, unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. The term "and / or" used in this specification includes any and all combinations of one or more related listed items.

[0024] See also Figure 1 and Figure 2 As shown, Figure 1 The present invention shows a pipeline publishing method based on agile development and supporting multiple deployment modes, which is characterized by comprising the following steps: Step S1, basic software installation and deployment: Under a single network condition, plan at least 3 servers, one with Gitlab installed as the source address of the code repository; one with continuous delivery micro-applications, Jenkins, and Jenkins plug-ins installed as the program compilation execution node, which creates continuous integration tasks, calls plug-ins to complete program compilation and pushes the output to the server or pushes the container image to the image repository; one with docker and kubectl installed as the containerization-related execution node to build docker images and create, replace, and remotely start and stop K8S cluster pods; Step S2, application configuration: complete the maintenance of basic information including the application name, determine the development mode, and the Gitlab code repository source address; Step S3, server resource configuration: as the target destination for compiling outputs in the traditional deployment mode, complete the maintenance of server resource name, IP address, port, user name, and password information, and synchronize them to SSH Servers in Jenkins; Step S4, image warehouse resource configuration: as the destination for pushing the image generated in the containerized deployment mode, complete the maintenance of the image warehouse resource name, URL address, user name, and password information; Step S5, K8S cluster configuration: As a carrier for program release in containerized deployment mode, complete the maintenance of cluster name, Master address and Config file, and support native K8S cluster and mainstream container scheduling platforms such as Rancher and KubeSphere; Step S6, application environment configuration: For the traditional deployment mode, the application is associated with the server resources configured in step 3 as the environment for application release in the traditional deployment mode. At the same time, a deployment script is written, and the commands for starting and stopping the application after the output is released to the server are maintained in the deployment script, so as to facilitate the subsequent application pipeline to compile and release the output; Step S7, create a new configuration pipeline: create a continuous delivery pipeline under the application, set different task nodes in the pipeline, and most importantly, build deployment type nodes to ensure that the code is compiled and released. Different types of process tasks on the pipeline are implemented through different plug-ins; Step S8, pipeline execution: The developer writes the business application code and provides the scripts and configuration files required for compiling and building the application code, which are uploaded to the Gitlab code repository. The pipeline is executed manually, timed, or automatically triggered to deploy and release the application.

[0025] In the above step S2, the development mode includes a free mode and a branch mode.

[0026] Free mode: Developers can use any branch (including master) for coding, packaging, publishing and other operations. In free mode, the master branch is often used to carry out development, integration and release. This is called trunk development. In trunk development, there is only one master branch. Developers will first clone the remote repository to the local repository, and then make modifications and commits locally until the local code is pushed to the remote master at a suitable time. This development mode is more suitable for small teams and when the project has not yet been launched, because small teams may not have too much collaboration and convergence.

[0027] Branching mode: Development team members use feature branches created by continuous delivery micro-applications to carry out development work. Continuous delivery micro-applications provide strong support for branching mode: developers only need to care about which feature branches to integrate and release, and a series of tasks such as release branch creation and management, and merging between branches can be entrusted to continuous delivery micro-applications. A feature branch (i.e., feature branch) is usually used to carry the repair of a defect or the development of a new requirement (after decomposition). Generally speaking, a feature branch is created based on the latest version of the master branch. Then develop and test on the feature branch until the feature function is completed, and then integrate, release and test it. This development mode focuses on functional development. Instead of submitting code directly to the master to ensure that it is stable and clean, feature branches are pulled from the master for functional development, so that the work of each person in the R&D team can be isolated to the greatest extent. When the functional development is completed, the build and release of different environments are carried out through the set pipeline, and only the branch code that passes the test is allowed to be merged into the master. This development mode is more suitable for teams with more people or when the project has been launched, because a multi-person team may often need to collaborate and merge, and need to keep the master (trunk) branch stable. Both development modes can use the pipeline release method based on agile development and supporting multiple deployment modes for build and release.

[0028] In the above step S7, the pipeline node types include: Build traditional deployment (normal): Build and package in the traditional deployment mode, and deploy the build results to the configured environment (server) for operation; Build containerized deployment (Docker): Build and package in containerized deployment mode, and build the build results into a Docker image and deploy it to the configured environment (server) or K8S cluster for operation; Manual checkpoints: tasks that require manual judgment to determine whether they are OK, used as checkpoints for manual testing and security review processes on the assembly line; Merge trunk: The operation of merging the feature branch into the master.

[0029] In the case of the traditional deployment mode, configuration information including package tags, build commands, build package output, and deployment script files needs to be provided; Package labels are used to distinguish packages for different purposes, such as packages deployed to the test environment and packages deployed to the production environment; The name of the package label is passed into the build process as the value of the environment variable ENV_LABEL; The build command needs to be filled in with the command executed during the build. For example, for a Maven project, it is mvn -U cleanpackage. If a script is required, fill in the relative path of the script with the current project directory as the root directory. For example, sh cicd.sh, then cicd.sh needs to exist in the root directory of the project. The usage of build package output and deployment script files is similar to that of build commands. Fill in the relative path of the build package and script files with the current project directory as the root directory.

[0030] In the case of containerized deployment mode, configuration information including DockerFile path, image repository, image address, image tag, K8S cluster, and deployment configuration file needs to be provided; The DockerFile path is the relative path of the DockerFile with the current project directory as the root directory; The image repository, image address, and image tag refer to the URL address of the Registry (warehouse) configured and authorized in step S4 and the Docker repo to be pushed after the Docker build is completed; K8S cluster refers to the Kubernates cluster configured and authorized in step S5; There are two ways to select the deployment configuration file. For developers and operators with a high level of knowledge in Docker and K8S, choose "Custom Path": Place the prepared deployment YAML file in the code repository and directly fill in the path relative to the root directory, such as: base-server / gw-server-v1.deployment.yaml. In addition, for developers and operators with a low level of knowledge in Docker and K8S, use the system's built-in templates to configure the deployment file.

[0031] In the above-mentioned step S8, the development mode adopts the branch mode, and the user needs to manually submit the branch to be released before running the pipeline; after the build deployment, the main branch merge operation is performed through the node of the merge trunk type.

[0032] In the above-mentioned step S8, the development mode adopts the free mode, and the execution pipeline is automatically triggered by configuring the cron expression or by the Gitlab Webhook.

[0033] In the above-mentioned step S8, in the case of the traditional deployment mode, the constructed program package is uploaded to the configured server resources for downloading or publishing operations.

[0034] In the above-mentioned step S8, in the case of containerized deployment mode, after uploading the constructed docker image to the configured image repository, it is pulled to the server or K8S cluster to create, replace, and start and stop pods.

[0035] like Figure 2 As shown, in order to solve the above technical problems, a technical solution adopted by the present invention is: to provide a pipeline release system based on agile development and supporting multiple deployment modes, characterized in that it includes a basic software installation and deployment module, an application configuration module and a pipeline execution module, wherein: Basic software installation and deployment module: used for the installation of Gitlab, Jenkins, Jenkins plug-ins, docker, kubectl, and continuous delivery micro-applications; Application configuration module: used for the configuration of related applications, pipelines, servers, K8S clusters, image repositories, and feature branches in continuous delivery of micro-applications, including: newly configured applications, servers, K8S clusters, image repositories, associated release environments in applications, and newly configured pipelines and feature branches; Pipeline execution module: used for the continuous delivery of feature branch submission and release and pipeline operation in micro-applications, including feature branch submission, compilation and release, manual nodes, and trunk merging.

[0036] The following application consists of GitLab, Jenkins, Docker and continuous release of micro-applications. GitLab is used for code repository management, and developers submit their coding to Gitlab's code repository after completion.

[0037] Continuously releasing micro-applications provides developers with two development modes: free mode and branch mode.

[0038] In order to ensure the relative independence of each environment and save release time, the continuous release of micro-applications can create multiple JenkinsClient instances in different network environments (such as relatively isolated development and testing environments, external network production environments, and internal network production environments) to meet the different release requirements of multiple network environments. It only needs to use a dedicated network channel to ensure that Jenkins and continuous delivery micro-applications in different network environments are connected to the Gitlab code repository. There is no need for other servers and K8S clusters in different network environments to be connected to each other.

[0039] Each compilation and release task of the pipeline created by continuous delivery of micro-applications is generated based on the compilation tasks of three templates built in Jenkins in advance, namely tf (traditional deployment mode), td-e (container + traditional deployment mode), and td-k (containerized deployment mode). The key public properties are replaced by Jenkins' text parameters ${buildCommand} (compilation command), ${PACKAGE_LABEL} (package label), ${appName} (application name), ${outputFile} (output), ${branch} (branch name), and ${deployFile} (deployment script path), and parameters are specified at runtime; the rest of the required information is replaced by the elements in the config.xml of the template's compilation task to generate the config.xml of the new compilation task, which includes<Hudson.plugins.git.UserRemoteConfig> (code library address), <credentialsid>(Jenkins credential ID is generated by the code base account bound to the continuous delivery micro application, see Figure 1 first step),<Jenkins.plugins.publish__over_ssh.BapSshPublisher> (Deployment environment and environment configuration for traditional deployment mode, including SSH port, credentials, connection timeout settings of the publishing server, etc.)<org.jenkinsci.plugins.dockerbuildstep.DockerBuilder> (Related configurations for container image repositories in containerized deployment mode, such as Harbor) In particular, for containerized deployment mode, in order to remotely operate multiple K8S clusters, use<Jenkins.plugins.publish__over_ssh.BapSshPublisher> Specify the server with kubectl environment installed as the node machine for remotely operating multiple K8S clusters, and send the YAML file for creating or replacing pods (taking a.yaml as an example) and the config file of the K8S cluster to be operated to the node machine (the file named config in $HOME / .kube of the K8S cluster master node, taking b_config as an example). <execcommand>Use kubectlreplace --kubeconfigb_config--force –f a.yaml to create or replace the pod and start it.

[0040] The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other, and for the sake of brevity, this application will not go into details.

[0041] The above are only embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent structural transformations made using the contents of the present invention's specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.< / execcommand> < / credentialsid>

Claims

1. A pipeline release method based on agile development and supporting multiple deployment modes, characterized by: The following steps are involved: Step 1: Basic software installation and deployment: Under a single network condition, plan at least 3 servers, install Gitlab on one server as the source address of the code repository; 1 machine with continuous delivery micro-applications, Jenkins, and Jenkins plug-ins installed as the program compilation execution node. By creating continuous integration tasks, the plug-ins are called to complete program compilation and push the output to the server or push the container image to the image warehouse; 1 machine with docker and kubectl installed, serving as a container-related execution node to build docker images and create, replace, and remotely start and stop K8S cluster pods; Step 2: Application configuration: Complete the maintenance of basic information including the application name, determine the development mode, and the source address of the Gitlab code repository; Step 3: Server resource configuration: As the target destination for compiled output in the traditional deployment mode, complete the maintenance of server resource name, IP address, port, user name, and password information, and synchronize them to SSH Servers in Jenkins; Step 4: Image repository resource configuration: As the destination for pushing the image generated in the containerized deployment mode, complete the maintenance of the image repository resource name, URL address, user name, and password information; Step 5. K8S cluster configuration: As a carrier for program release in containerized deployment mode, complete the maintenance of cluster name, Master address and Config file, and support native K8S clusters and mainstream container scheduling platforms such as Rancher and KubeSphere; Step 6: Application environment configuration: For the traditional deployment mode, associate the application with the server resources configured in step 3 as the environment for application release in the traditional deployment mode. At the same time, write a deployment script, and maintain the commands for starting and stopping the application after the output is released to the server in the deployment script, so as to facilitate the subsequent application pipeline to compile and release the output; Step 7. Create a new configuration pipeline: Create a continuous delivery pipeline for the application, set different task nodes in the pipeline, and most importantly, build deployment type nodes to ensure that the code is compiled and released. Different types of process tasks on the pipeline are implemented through different plug-ins. Step 8: Pipeline execution: Developers write business application code and provide the scripts and configuration files required for compiling and building the application code, upload it to the Gitlab code repository, and execute it manually, periodically, or automatically through the pipeline to deploy and release the application.

2. According to claim 1, the pipeline release method based on agile development supporting multiple deployment modes is characterized by: In the step 2, the development mode includes a free mode and a branch mode.

3. According to claim 1, the pipeline release method based on agile development supporting multiple deployment modes is characterized in that: In step 7, the pipeline node types include: Build traditional deployment: Build and package in the traditional deployment mode, and deploy the build results to the configured environment for operation; Build containerized deployment: Build and package in containerized deployment mode, and build the build results into Docker images and deploy them to the configured environment or K8S cluster for operation; Manual checkpoints: tasks that require manual judgment to determine whether they are OK, used as checkpoints for manual testing and security review processes on the assembly line; Merge trunk: The operation of merging the feature branch into the master.

4. The pipeline release method based on agile development supporting multiple deployment modes according to claim 3 is characterized in that: In the case of traditional deployment mode, configuration information including package tags, build commands, build package output, and deployment script files needs to be provided; Package labels are used to distinguish packages for different purposes, such as packages deployed to the test environment and packages deployed to the production environment. The name of the package label is passed into the build process as the value of the environment variable ENV_LABEL; The build command needs to be filled in with the command executed during the build. If a script is required, fill in the relative path of the script with the current project directory as the root directory; The usage of build package output and deployment script files is similar to that of build commands. Fill in the relative path of the build package and script files with the current project directory as the root directory.

5. The pipeline release method based on agile development supporting multiple deployment modes according to claim 3 is characterized in that: In the case of containerized deployment mode, you need to provide configuration information including DockerFile path, image repository, image address, image tag, K8S cluster, and deployment configuration file; The DockerFile path is the relative path of the DockerFile with the current project directory as the root directory; The image repository, image address, and image tag refer to the URL address of the Registry configured and authorized in step 4 and the Docker repo to be pushed after the Docker build is completed; K8S cluster refers to the Kubernates cluster that has been configured and authorized in step 5; There are two ways to select the deployment configuration file. For development and operation personnel with a high knowledge of Docker and K8S, choose the "custom path" method, place the written deployment YAML file in the code repository, and directly fill in the path relative to the root directory; for development and operation personnel with a low knowledge of Docker and K8S, configure the deployment file through the system's built-in template.

6. The pipeline release method based on agile development supporting multiple deployment modes according to claim 1, characterized in that: In step eight, the development mode adopts the branch mode, so the user needs to manually submit the branch to be released before running the pipeline; After building and deploying, the main branch merge operation is performed through the node of the merge trunk type.

7. The pipeline release method based on agile development supporting multiple deployment modes according to claim 1, characterized in that: In step eight, the development mode adopts the free mode, and the execution pipeline is automatically triggered by configuring the cron expression or by the Gitlab Webhook.

8. The pipeline release method based on agile development supporting multiple deployment modes according to claim 1, characterized in that: In step eight, in the case of a traditional deployment mode, the constructed program package is uploaded to a configured server resource for downloading or publishing.

9. The pipeline release method based on agile development supporting multiple deployment modes according to claim 1, characterized in that: In step eight, in the case of containerized deployment mode, the built Docker image is uploaded to the configured image repository, and then pulled to the server or K8S cluster to create, replace, and start and stop pods.

10. A pipeline release system based on agile development and supporting multiple deployment modes, characterized by: It includes basic software installation and deployment module, application configuration module and pipeline execution module, among which: Basic software installation and deployment module: used for the installation of Gitlab, Jenkins, Jenkins plug-ins, docker, kubectl, and continuous delivery micro-applications; Application configuration module: used for the configuration of related applications, pipelines, servers, K8S clusters, image repositories, and feature branches in continuous delivery of micro-applications, including: newly configured applications, servers, K8S clusters, image repositories, associated release environments in applications, and newly configured pipelines and feature branches; Pipeline execution module: used for the continuous delivery of feature branch submission and release and pipeline operation in micro-applications, including feature branch submission, compilation and release, manual nodes, and trunk merging.

Images