Custom continuous integration delivery platform

Abstract

The embodiment of the invention discloses a self-defined continuous integration delivery platform, which comprises a central publishing platform, a code warehouse, a private server warehouse and a mirror image warehouse, the central publishing platform comprises a process construction module; in use, a user selects a plurality of process construction modules from a user side interface of the central publishing platform according to a required publishing process, and establishes connection among the process construction modules to form the required publishing process; and the central publishing platform calls each process construction module in the publishing process in sequence, and publishing is completed by each process construction module. According to the embodiment of the invention, a user can construct a publishing process according to actual needs through a modular strategy.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a customized continuous integration delivery platform. Background Art

[0002] In the existing continuous integration and delivery, the newly submitted image of Harbor is usually used to trigger the webhook to call Jenkins, and then Jenkins executes the script function through the pipeline or ssh command to release and deploy.

[0003] This approach may have the following problems:

[0004] 1) Due to the use of fixed software, there are software vulnerabilities and great security issues; at the same time, due to software version and plug-in compatibility issues, it is necessary to update the plug-in online multiple times, which may cause poor compatibility and inability to start.

[0005] 2) Due to the use of fixed software, if you do not understand the software you are using, you may not be able to achieve the functions you need. Due to software function limitations, you can only implement the required projects within the framework of the software, resulting in incomplete functions or failure to achieve the desired purpose.

[0006] 3) By using ready-made software solutions, functions can be implemented quickly, but they cannot be modified better. Except for horizontal changes, additional requirements cannot be added at any time. Summary of the invention

[0007] An embodiment of the present invention provides a customized continuous integration delivery platform to solve at least one of the above problems.

[0008] A customized continuous integration delivery platform, including: central publishing platform, git / svn code repository, private server repository and mirror repository;

[0009] The central publishing platform includes a process building module, and the process building module includes a basic module and a custom module, wherein the basic module includes at least one of a compilation module, a packaging module, an image building module, a warehouse module, a container deployment module, a publishing module, a trigger module, and a pull module;

[0010] During use, the user selects multiple process building modules from the user interface of the central publishing platform according to the required publishing process, and establishes connections between the process building modules to form the required publishing process;

[0011] In response to the publishing requirements submitted by the user, the central publishing platform calls each process building module in the publishing process in turn, and each process building module calls at least one of the code repository, private service repository, and image repository, and pushes it to the vm / cluster server cluster, or the kubernetes / docker container cluster to complete the publishing.

[0012] This custom continuous integration delivery platform unifies different businesses and different release plans into one platform through a modular strategy, allowing users to choose different modules to build their own release process according to actual needs, without considering the rigid requirements of the existing release software for system version, software, underlying code type, etc. At the same time, by processing the cicd process through scripts or codes, ideal requirements can be added at any time, and software compatibility and vulnerability issues can be avoided, and only the code needs to be correct. In addition, this platform can be combined with more software, avoiding the problems of single software, different versions requiring different operating systems and third-party software, etc. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] Figure 1 It is a structural diagram of a custom continuous integration delivery platform provided by an embodiment of the present invention;

[0015] Figure 2 It is a classification diagram of a publishing process provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0016] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work belong to the scope of protection of the present invention.

[0017] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0018] In the description of the present invention, it is also necessary to explain that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0019] Figure 1 Schematic diagram of a customized continuous integration delivery platform provided by an embodiment of the present invention. Figure 1 As shown, the custom continuous integration delivery platform (or custom release platform) includes: a central release platform, a git / svn code repository, a private server repository, and a mirror repository.

[0020] Among them, the central publishing platform uses modular auditing to compile different build and release methods and release processes into different modules. Users can select the desired modules in the web page to form the release process they need. Specifically, this embodiment refers to these modules as process building modules, which include basic modules and custom modules. The basic modules include compilation modules, packaging modules, image building modules, warehouse modules, container deployment modules, publishing modules, trigger modules, pull modules, etc. Custom modules refer to special operations in software release that are customized by users and are used to increase or decrease build projects.

[0021] When using the custom continuous integration delivery platform, users can select multiple corresponding process building modules from the user interface of the central publishing platform according to the required release process, and establish the connection relationship between each process building module to form the required release process. For example, in image release, users can select a compilation module, a warehouse module, and a container deployment module. After creating the release process, you can upgrade and release it through this process. If the required module is not available, you can add a module display at any time and apply it to the upgrade release process. In contrast, the software tools in the existing technology require upgraded versions and have poor flexibility.

[0022] After the process is built, the user can submit the publishing requirements to the central publishing platform. The central publishing platform will call each process construction module in the publishing process in sequence according to the publishing process created by the user. Each process construction module will call at least one of the code repository, private service repository, and image repository, and push it to the vm / cluster server cluster, as well as the kubernetes / docker container cluster, etc. to complete the release.

[0023] It can be seen that with the help of this customized continuous integration delivery platform, users can build their own release process according to their needs to meet various code upgrade methods. At the same time, there is no need to consider software and system compatibility requirements, making deployment more convenient.

[0024] In general, the custom continuous integration delivery platform of this embodiment can cover two types of upgrade and release methods. One is that the developer directly submits the code and then submits the version, project and other parameters to be released. The operation and maintenance determines the project type through the release platform, automatically compiles, packages, and builds the image, and then releases it to the required project platform; the other is that the developer submits it to the image repository, and the release platform detects that there is a new image and automatically releases it to the required project environment. It can determine whether it is released automatically or manually in the middle.

[0025] For these two types of upgrade release methods, the custom continuous integration delivery platform uses its own basic modules to build the following three release processes, combined with Figure 1 and Figure 2 , they are:

[0026] The first is the image-triggered release process. In this release process, developers submit images to the image repository. After the central release platform detects the new image, it triggers the image repository to release the new image to the required project platform through the trigger module.

[0027] The second is to build a release-style release process. In this release process, after the developer submits the code to the code repository or private server repository, he submits the release requirements to the central release platform; the central release platform determines the project type, pulls the code from the code repository or private server repository through the pull module, and automatically compiles, packages and builds the image through the compilation module, packaging module and image construction module, and then publishes it to the required project platform through the container deployment module or the release module.

[0028] The third type is the direct publishing process. Under this publishing process, developers submit directly formed software (such as jar packages, PHP, Python executable programs, etc.) to the code warehouse or private service warehouse, or submit directly available images to the image warehouse, and then submit publishing requirements to the central publishing platform; the central publishing platform pulls the code from the code warehouse or private service warehouse, or pulls the image from the image warehouse through the pull module, and publishes it to the required project platform through the container deployment module or the release module.

[0029] Specifically, each publishing process can be subdivided into different types according to different project environments (such as Java, net, and static resources).

[0030] Furthermore, each module can be written using python+shell, and each process building module can reserve multiple dynamic locations, including version, address and package name. When submitting a publishing requirement, the user can enter the version, address and package name parameters, and submit the publishing requirement to the central publishing platform; the central publishing platform fills the parameters in the publishing requirement into the dynamic position of each process building module in the publishing process, and then calls each module in sequence according to the publishing process. Each major module can select one or two sub-modules. After the process is built, it can be tested first and then released for production after completion. If it fails, you can choose the fallback function.

[0031] Furthermore, the customized continuous integration delivery platform can also ensure business upgrade isolation through user permissions. The permissions of each user are managed by the super administrator, and the number of modules for each user can be limited. Ordinary users can only manage their own release processes. Administrators can also assign process permissions to other users to avoid the risk of misoperation. User information is stored in the database, and even if the platform crashes, user-related information will be retained after it is rebuilt.

[0032] Furthermore, each process construction module can also embed monitoring tools for related businesses. Most of the existing publishing tools have single functions, and most of their functions are limited to publishing upgrades. The process construction module in this embodiment reserves the monitoring connection position in advance when it is produced. When publishing, the monitoring chart status of the business server or cluster in the stage of upgrading and publishing is captured through the API, and displayed on the front-end page. The different states of the server before and after publishing can be captured, so that developers can compare performance. Optionally, the central publishing platform can include a public monitoring module. After the user selects and connects each process construction module to form the required publishing process, the public monitoring module can be selected from the user-side interface, and it is connected with the process construction module that needs to be monitored to form the final publishing process. Correspondingly, when the central publishing platform calls the process construction module that needs to be monitored, it triggers the public monitoring module to connect to the monitoring tool embedded in the process construction module, and the monitoring tool captures the monitoring icon status of the business server or cluster in the current stage through the API and displays it on the user-side interface.

[0033] Furthermore, the custom continuous integration delivery platform can also add an automatic alarm function. Through the front-end site page, the functions of receiving information of conventional software such as publishing emails, short messages, and DingTalk are integrated in each process construction module, while other software in the prior art requires third-party tools or plug-ins to implement alarms. Users can select the alarm rules they need, and after selecting the release process, add the alarm module. When publishing, users will receive SMS or emails with detailed information of the release. Better monitoring process reduces recovery time after release failure.

[0034] Furthermore, the custom continuous integration delivery platform can also set up a fault recovery mechanism. Since the platform is not a large-scale product, even if it is deleted or missing due to uncontrollable reasons, it can be supplemented again. All module information is stored in the database, and the module information is stored in the warehouse or unused code warehouse. The platform includes a download source code page, which can download the customized process file script to the local. After the fault is recovered, you can upload your own process module file. The user only needs to wait for the basic module to be supplemented and it can be used normally. That is, when the custom publishing platform fails, in response to the user clicking the download source code function, the central publishing platform downloads the source code of the custom module and publishing process created by the user from the module warehouse or code warehouse; when the custom continuous integration delivery platform recovers from the fault, in response to the user uploading the source code file of the custom module and publishing process again, the central publishing platform supplements the source code of the basic module on the basis of the source code file to form a complete publishing process.

[0035] In summary, this embodiment provides a customized continuous integration delivery platform, which unifies different businesses and different release plans into one platform through a modular strategy, so that users can choose different modules to build their own release process according to actual needs, without considering the rigid requirements of the existing release software for system version, software, underlying code type, etc. At the same time, by processing the cicd process through scripts or codes, ideal requirements can be added at any time, and software compatibility and vulnerability issues can be avoided, and only the code needs to be correct. In addition, this platform can be combined with more software, avoiding the problems of single software, different versions requiring different operating systems and third-party software, etc.

[0036] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present invention.

Claims

1. A custom continuous integration delivery platform, characterized in that: include: Central publishing platform, git / svn code repository, private server repository and mirror repository; The central publishing platform includes a process building module, and the process building module includes a basic module and a custom module, wherein the basic module includes at least one of a compilation module, a packaging module, an image building module, a warehouse module, a container deployment module, a publishing module, a trigger module, and a pull module; During use, the user selects multiple process building modules from the user interface of the central publishing platform according to the required publishing process, and establishes connections between the process building modules to form the required publishing process; In response to the publishing requirements submitted by the user, the central publishing platform calls each process building module in the publishing process in turn, and each process building module calls at least one of the code repository, private service repository, and image repository, and pushes it to the vm / cluster server cluster, or the kubernetes / docker container cluster to complete the publishing.

2. The customized continuous integration delivery platform according to claim 1, characterized in that: Each process building module reserves multiple dynamic locations, including version, address and package name; In response to the publishing requirements submitted by the user, the central publishing platform sequentially calls each process building module in the publishing process, including: The user enters version, address and package name parameters in the publishing requirement and submits the publishing requirement to the central publishing platform; The central publishing platform fills the parameters in the publishing requirements into the dynamic positions of the process building modules in the publishing process and calls them.

3. The customized continuous integration delivery platform according to claim 1, characterized in that: Each process building module has a built-in monitoring tool, and the central publishing platform also includes a public monitoring module; The user selects multiple process building modules from the user interface of the central publishing platform according to the required publishing process, and establishes connections between the process building modules to form the required publishing process, including: The user selects multiple process building modules from the user interface of the central publishing platform according to the required publishing process, and establishes connections between the process building modules to form the required publishing process; For the process building module that needs to be monitored, the user selects a public monitoring module from the user-side interface and connects it with the process building module that needs to be monitored to obtain the final release process.

4. The customized continuous integration delivery platform according to claim 3, characterized in that: In response to the publishing requirements submitted by the user, the central publishing platform sequentially calls each process building module in the publishing process, and each process building module calls at least one of the code warehouse, the private server warehouse, and the image warehouse, including: In response to the publishing requirements submitted by the user, the central publishing platform sequentially calls each process building module in the publishing process, and each process building module calls at least one of the code warehouse, private server warehouse, and image warehouse; When the process construction module that needs to be monitored is called, the public monitoring module is triggered to connect to the monitoring tool embedded in the process construction module. The monitoring tool captures the monitoring icon status of the business server or cluster at the current stage through the API and displays it on the user-side interface.

5. The customized continuous integration delivery platform according to claim 1, characterized in that: Each process building module has an embedded alarm rule, and the central publishing platform also includes an alarm module; The user selects multiple process building modules from the user interface of the central publishing platform according to the required publishing process, and establishes connections between the process building modules to form the required publishing process, including: The user selects multiple process building modules from the user interface of the central publishing platform according to the required publishing process, and establishes connections between the process building modules to form the required publishing process; For the process construction module that needs an alarm, the user selects an alarm module from the user-side interface and connects it with the process construction module that needs an alarm to obtain a final release process.

6. The customized continuous integration delivery platform according to claim 5, characterized in that: In response to the publishing requirements submitted by the user, the central publishing platform sequentially calls each process building module in the publishing process, and each process building module calls at least one of the code warehouse, the private server warehouse, and the image warehouse, including: In response to the publishing requirements submitted by the user, the central publishing platform sequentially calls each process building module in the publishing process, and each process building module calls at least one of the code warehouse, private server warehouse, and image warehouse; When the process construction module requiring an alarm is called, the alarm module is triggered to call the alarm rule embedded in the process construction module, and an alarm message is sent via SMS or email when the alarm rule is triggered.

7. The customized continuous integration delivery platform according to claim 1, characterized in that: The fault recovery mechanism of the custom continuous integration delivery platform is: Storing each process building module in a module repository or a code repository, and providing a source code download function on the user interface; When the custom publishing platform fails, in response to the user clicking the download source code function, the central publishing platform downloads the source code of the custom module and publishing process created by the user from the module warehouse or code warehouse; When the custom continuous integration delivery platform recovers from a failure, in response to the user uploading the source code files of the custom module and the release process again, the central release platform supplements the source code of the basic module on the basis of the source code files to form a complete release process.

8. The customized continuous integration delivery platform according to claim 1, characterized in that: The release process required by users includes mirror triggering: The developer submits the image to the image repository. After the central publishing platform detects the new image, it triggers the image repository to publish the new image to the required project platform through the trigger module.

9. The customized continuous integration delivery platform according to claim 1, characterized in that: The release process required by users includes building a release-style: After the developer submits the code to the code repository or private server repository, he / she submits the publishing requirements to the central publishing platform; The central publishing platform determines the project type, pulls the code from the code repository or private server repository through the pulling module, and automatically compiles, packages and builds the image through the compilation module, packaging module and image building module, and then publishes it to the required project platform through the container deployment module or the publishing module.

10. The customized continuous integration delivery platform according to claim 1, characterized in that: The publishing process required by users includes direct publishing: After the developer submits a directly available program package to the code warehouse or private server warehouse, or submits a directly available image to the image warehouse, he submits a publishing requirement to the central publishing platform; The central publishing platform pulls the code from the code repository or the private server repository through the pulling module, or pulls the image from the image repository, and then publishes it to the required project platform through the container deployment module or the publishing module.

Images