An internal network environment product release server architecture, method, device and medium based on Jenkins

Abstract

The present invention discloses an internal network environment product release server architecture, method, device and medium based on Jenkins. The server architecture includes: a user development environment terminal, an SVN server, a GitLab server, a Jenkins server, a Linux server and a Windows server. Among them, user code products are submitted to the SVN server and the GitLab server. The Jenkins service status is polled to trigger a code pulling signal. The code pulling action is executed by deploying a Jenkins agent service compilation node, and the compilation action is executed to perform product packaging and release operations. The present invention provides an architecture and script set based on Jenkins, which can realize basic functions such as automatic code compilation, compilation error alarm, and compilation completion prompt, and also adds functions such as integration and release of multi-platform products and conditional packaging according to actual requirements.

Description

Technical Field

[0001] The present invention relates to the technical field of software code compilation and packaging in an intranet environment, and particularly relates to an intranet environment product release server architecture, method, device and medium based on Jenkins. Background Art

[0002] In the field of software code development, continuous integration and automated release have become core technologies for improving development efficiency and ensuring product quality. As an open-source continuous integration tool, Jenkins is widely used in the automated construction and deployment of Java projects due to its plug-in architecture and cross-platform characteristics. However, in scenarios involving compiled languages such as C++ and mixed multi-platform development, traditional Jenkins solutions face significant challenges:

[0003] (1) Insufficient language adaptability: Jenkins natively supports Java projects well, but lacks a standardized process for configuring the compilation environment for projects such as C++ (such as cross-platform compiler chains and dependency library management). A large amount of customized scripts need to be manually written. Especially in the SVN and GitLab mixed version control architecture, the complexity of code pulling and version synchronization increases significantly. (2) Defects in multi-platform collaboration: For projects that need to generate products for both Windows / Linux platforms simultaneously, existing solutions often require independent configuration of multiple Jenkins nodes, lacking a unified version number management and compilation product integration mechanism, resulting in fragmentation of the cross-platform release process and prone to version inconsistency problems. (3) Intranet environment restrictions: Enterprise intranets often have characteristics such as isolation from the external network and strict security policies, which hinder conventional operations such as plugin installation and dependency download. The traditional external network-oriented Jenkins deployment mode is difficult to directly migrate, and there is a lack of lightweight notification solutions (such as being unable to use cloud service email notifications). (4) Discontinuity of the automated process: Existing implementations are mostly limited to basic compilation functions, lacking an end-to-end automated chain. For example, when there are compilation errors, it relies on manual log viewing, multi-platform products need to be manually aggregated and packaged, and the version update log is disjointed from the release link, reducing the continuous delivery efficiency.

[0004] The invention application with the application number 202211519834.4 discloses a code packaging and verification method and device based on Jenkins. Using the solution of this application can verify code integrity, reduce workload, improve R & D efficiency, and avoid problems during code synchronization. However, its solution also has problems of insufficient language adaptability and defects in multi-platform collaboration.

[0005] Therefore, there is a need for a set of architectures and scripts based on Jenkins that can quickly set up a project automation compilation and release environment under the Jenkins architecture, achieve cross-platform code automatic compilation, compilation error alarm, compilation completion prompt, etc., and add functions such as integration and release of multi-platform products and conditional packaging. Summary of the Invention

[0006] Aiming at the above existing problems, the purpose of the present invention is to provide an intranet environment product release server architecture, method, device and medium based on Jenkins, so as to realize operation processes such as multi-platform collaboration, automatic code compilation, error alarm and packaging and release.

[0007] An embodiment of the present invention provides an intranet environment product release server architecture, method, device and medium based on Jenkins.

[0008] First aspect: An intranet environment product release server architecture based on Jenkins, including:

[0009] A user development environment terminal, which is used for users to develop to generate dynamic library product source code and executable program product source code;

[0010] An SVN server, connected to the user development environment terminal, and used to host the source code of the dynamic library product;

[0011] A GitLab server, connected to the user development environment terminal, and used to host the source code of the executable product;

[0012] A Jenkins server, by polling the status of the SVN server and the GitLab server, listens for code updates and triggers a code pulling signal;

[0013] A Linux server, which is deployed with a Jenkins agent service compilation node. After receiving the code pulling signal from Jenkins, it executes the code pulling action. After the code pulling is completed, it executes the compilation action;

[0014] A Windows server: It is deployed with a Jenkins agent service compilation node. After receiving the code pulling signal from Jenkins, it executes the code pulling action. After the code pulling is completed, it executes the compilation action. After the compilation is completed, it performs product packaging and release operations.

[0015] Second aspect: An intranet environment product release method based on Jenkins, including:

[0016] S1. Submit the source code of the dynamic library product to the SVN server, and / or submit the source code of the executable product to the GitLab server;

[0017] S2. Use the Jenkins service to monitor the source code submitted to the SVN server or GitLab server, and trigger a code pulling signal;

[0018] S3. Use the Linux server compilation node and / or Windows server compilation node to perform a code pulling action on the SVN server and / or GitLab server according to the code pulling signal. After the code pulling is completed, perform a code compilation action;

[0019] S4. After the code compilation is completed, rely on the Windows server compilation node to complete the code packaging and publishing operations.

[0020] Furthermore, the Jenkins service in S2 is deployed in the Docker environment of the host server, and the deployment steps include:

[0021] S11. Build a Docker environment on the internal network host server;

[0022] S12. Create a Docker container in the external network environment;

[0023] S13. Install the Jenkins service and plugins in the Docker container;

[0024] S14. Package the installed Docker container into a system image;

[0025] S15. Load the system image in the Docker environment of the internal network host server.

[0026] Furthermore, the:

[0027] The Linux server is deployed with a Jenkins agent service compilation node, and the deployment directories include: a first-level directory, a second-level directory, and a third-level directory, where:

[0028] The second-level directory is located within the first-level directory and includes a dynamic library product compilation directory, an executable program compilation directory, and a script set directory;

[0029] The third-level directory is located within the script set of the second-level directory and includes an exception notification script file, a version information storage directory, a dynamic library product compilation and packaging script directory, and an executable program compilation and packaging script directory;

[0030] The Windows server is deployed with a Jenkins agent service compilation node, and the deployment directories include: a first-level directory, a second-level directory, and a third-level directory, where:

[0031] The second-level directory is located within the first-level directory and includes a dynamic library product compilation directory, an executable program compilation directory, a packaging and publishing working directory, and a script set directory;

[0032] The third-level directory is located within the second-level directory script collection, including the exception notification script file, the version information storage directory, the dynamic library product compilation and packaging script directory, the executable program compilation and packaging script directory, and the packaging and release script directory.

[0033] Furthermore, the files stored in the dynamic library product compilation and packaging script directory or the executable program compilation and packaging script directory include: the md5.txt, buildproject.sh, and package.sh script files for compilation and packaging, where:

[0034] md5.txt is used to store the md5 value of the code;

[0035] buildproject.sh is used to obtain, compare, and compile the md5 value of the code;

[0036] package.sh is used for product packaging.

[0037] Furthermore, relying on the md5.txt, buildproject.sh, and package.sh script files, the compilation and packaging process includes:

[0038] S21. Enter the code directory;

[0039] S22. Obtain the md5 value of the code;

[0040] S23. Verify whether the obtained md5 value is consistent with the cached md5 value file. If it is consistent, end the process. If it is inconsistent, proceed to step S24;

[0041] S24. Perform code compilation, and determine whether the code compilation is abnormal. If it is abnormal, trigger an exception message notification and then end the process; if the code compilation is normal, proceed to step S25;

[0042] S25. Call the packaging script to perform product packaging.

[0043] Furthermore, the files stored in the packaging and release script directory include: the build.bat and sendmsg.py script files for packaging and release operations on the Windows server compilation node, where:

[0044] build.bat is used to download the product to the packaging and release working directory and package it as a compressed file;

[0045] sendmsg.py is mainly used to publish the information notification of the working directory.

[0046] Furthermore, after the code compilation is completed, relying on the Windows server compilation node, the code packaging and release operations are completed, and the process includes:

[0047] S31. Obtain the complete version number for packaging and release;

[0048] S32. Obtain the update log for packaging and release;

[0049] S33. Copy the product compiled and packaged for the Windows system to the working directory for packaging and release;

[0050] S34. Download the product compiled and packaged for the Linux system to the working directory for packaging and release;

[0051] S35. Write the update log of S32 to the update log file in an appended manner;

[0052] S36. Package the products in the entire working directory for packaging and release into a single compressed file;

[0053] S37. Upload the packaged compressed file to the intranet shared directory;

[0054] S38. Publish the completion notice information within the local area network.

[0055] Third aspect: An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the steps of the method provided in the second aspect.

[0056] Fourth aspect: A non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the method provided in the second aspect.

[0057] Advantages of the present invention:

[0058] 1. By providing an architecture and a set of scripts based on Jenkins, the present invention realizes a service for rapid deployment of an automated continuous integration and release of a project with the structure of "Qt project with hybrid hosting of SVN + GitLab" in a local area network environment, and can implement basic functions such as automatic compilation upon code submission, compilation error alarm, and compilation completion prompt. Moreover, according to actual requirements, functions such as integration and release of multi-platform products and conditional packaging are added, which is particularly suitable for complex project scenarios that need to manage dynamic libraries (SVN) and executable programs (GitLab) simultaneously.

[0059] 2. Through the Linux / Windows dual-node architecture and platform-specific scripts, the present invention realizes parallel compilation and automatic integration of multi-platform products, significantly improves the construction efficiency in multiple environments, avoids the time cost of manual switching of the compilation environment, and realizes cross-platform compilation and automatic integration.

[0060] 3. The present invention adopts a pre-configured Docker image deployment solution. By pre-building the image through the external network and directly loading it in the internal network, it breaks through the obstacles of installation and plugin configuration relying on the internal network environment, shortens the continuous integration environment deployment time from hours to minutes, and speeds up the rapid deployment ability in the internal network.

[0061] 4. The present invention realizes the intelligent judgment of incremental compilation through md5 check comparison and version number management, avoids repeated construction, and combines the conditional packaging trigger mechanism to reduce resource waste while ensuring code consistency, realizing an intelligent compilation optimization mechanism.

[0062] 5. The present invention realizes the standardized management of compiled products, log files, and packaging scripts through a three-level directory structure and version control scripts; combined with the automatic release mechanism of the internal network shared directory, it ensures the version alignment and centralized storage of multi-platform products, reducing the risk of version chaos caused by manual intervention. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 It is a schematic structural diagram of the product release server architecture in the internal network environment based on Jenkins of the present invention;

[0064] Figure 2 It is a schematic flow diagram of the product release method in the internal network environment based on Jenkins of the present invention;

[0065] Figure 3 It is a schematic structural diagram of the deployment environment of the Jenkins service of the present invention;

[0066] Figure 4 It is a schematic structural diagram of the Jenkins proxy service node directory structure under the linux system of the present invention;

[0067] Figure 5 It is a schematic flow diagram of the script compilation and packaging process in the compilation and packaging script directory of the present invention;

[0068] Figure 6 It is a schematic structural diagram of the Jenkins proxy service node directory structure under the Windows system of the present invention;

[0069] Figure 7 It is a schematic flow diagram of the script packaging and release process in the packaging and release script directory of the present invention;

[0070] Figure 8 It is a schematic structural diagram of the electronic device of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0071] Embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the drawings are exemplary and are only used to explain the present invention and should not be construed as a limitation of the present invention.

[0072] Currently, there is a lack of a solution and script set for product release servers in the intranet environment based on Jenkins, and there is a lack of functions such as automatic compilation of code submissions, compilation error alarms, and compilation completion prompts for multi-platform collaboration.

[0073] In view of the above problems, the present invention provides an architecture and method for a product release server in an intranet environment based on Jenkins. Figure 1 FIG. is a schematic structural diagram of an architecture of a product release server in an intranet environment based on Jenkins provided by an embodiment of the present invention. The architecture includes:

[0074] A user development environment terminal for generating source code of dynamic library products and source code of executable program products by users for development.

[0075] An SVN server connected to the user development environment terminal for hosting the source code of dynamic library products;

[0076] A GitLab server connected to the user development environment terminal for hosting the source code of executable products;

[0077] A Jenkins server. The Jenkins service mainly provides services for listening to code and code compilation. Among them, listening to code polls the status of the SVN server and the GitLab server through the Jenkins server to query the hosting situation of the code on the SVN server and the GitLab server. If there is new code to be hosted, a code pulling signal is generated and sent to the proxy service compilation node for code compilation.

[0078] Code compilation is achieved by deploying a Jenkins proxy service compilation node on a Linux server and deploying a Jenkins proxy service compilation node on a Windows server.

[0079] A Linux server is deployed with a Jenkins proxy service compilation node. After receiving the code pulling signal from Jenkins, it performs a code pulling action. After the code pulling is completed, it performs a compilation action to obtain the compiled code product.

[0080] Windows server: A compilation node with a Jenkins agent service is deployed. After receiving the code pulling signal from Jenkins, it performs the code pulling action. After the code pulling is completed, it performs the compilation action. After the compilation is completed, it obtains the compiled code product, and then performs product packaging and release operations.

[0081] Based on the above architecture, as Figure 2 shown, the present invention discloses a method for building a product release server in an intranet environment based on Jenkins, including:

[0082] S1. Submit the source code of the dynamic library product to the SVN server, and / or submit the source code of the executable product to the GitLab server.

[0083] Users rely on the development environment to develop the source code of the dynamic library product and / or the source code of the executable program product, and submit it to the SVN server or the GitLab server.

[0084] S2. Use the Jenkins service to monitor the source code submitted to the SVN server or the GitLab server and trigger a code pulling signal.

[0085] The Jenkins service polls the status of the SVN server and the GitLab server to query the managed update situation of the code on the SVN server and the GitLab server. If there is new code to be managed, it triggers a code pulling signal and sends it to the proxy service compilation node for code compilation.

[0086] As Figure 3 shown, the services provided by the Jenkins service mainly include code monitoring and code compilation services. When configuring the intranet Jenkins server, a Docker environment deployment solution can be adopted, that is, first build a Docker environment on the Jenkins service host server, and then import the Docker system image file that has been installed and configured in the external network environment and load it as a container. This solution simplifies the deployment work in the intranet environment, isolates the internal and external network connections, and has high confidentiality.

[0087] The following introduces the configuration process of the Jenkins server, and the main steps include:

[0088] First, build a Docker environment on the intranet system host server;

[0089] Then, create a Docker container in the external network system environment;

[0090] After that, install the Jenkins service and plugins in the external network Docker container;

[0091] After that, the Docker container after installing the Jenkins service and plugins is packaged as a system image;

[0092] Finally, the system image is loaded in the Docker environment of the intranet host server.

[0093] The configuration of the Jenkins server is completed through the above configuration method. Among them, the code compilation service provided by Jenkins is completed by configuring proxy service nodes in Linux servers or Windows servers.

[0094] The S3, Linux server compilation node, and Windows service compilation node perform code pulling actions on the SVN server and / or GitLab server according to the code pulling signal. After the code pulling is completed, the compilation action is executed.

[0095] When configuring the Jenkins proxy service node on a Linux server or Windows server, the server needs to first install necessary software packages, such as: GitLab client, SVN client, and Python environment, etc.; the basic deployment method has a detailed tutorial in the relevant Jenkins literature and will not be elaborated here.

[0096] As Figure 4 shown, taking the Linux server compilation node as an example, after configuring the Jenkins proxy service node in the Linux server, the formed subdirectories include the first-level directory, second-level directory, and third-level directory.

[0097] Among them, the second-level directory is located within the first-level directory and includes the dynamic library product compilation directory, executable program compilation directory, and script set directory; the third-level directory is located within the script set of the second-level directory and includes the exception notification script file, version information storage directory, dynamic library product compilation and packaging script directory, and executable program compilation and packaging script directory.

[0098] Among them, in the third-level directory, the role of the exception notification script file is that it can use the intranet mail server or the built-in mail notification function of Jenkins for exception notification. If the intranet environment is only a local area network built by switches and there is no mail server, the message sending notification function of the Feiqiu communication software can be implemented using a python script. The main code is as follows:

[0099] Sender = socker.socket(socket.AF_INET,socketSOCK_DGRAM)

[0100] Sender.bind((‘’,9090))

[0101] Sender.sendto((‘1:1:[Custom Username]:[Custom Account]:32:[Custom Notification Message]’).encode(‘GBK’),

[0102] ([Target IP], 2425))

[0103] In actual use, the IP addresses of several main notification recipients can be specified to traverse and send notification messages.

[0104] In the version information storage directory, two script files, lastversion and baseversion, are stored. The baseversion script file is used to store the manually specified major version number, while the lastversion stores the commit version numbers obtained from SVN and GitLab.

[0105] Under the dynamic library compilation and packaging script directory and the executable program compilation and packaging script directory, three files are mainly stored: md5.txt, buildproject.sh, and package.sh.

[0106] Among them, md5.txt and package.sh are used to store the md5 value of the code directory and the dynamic library packaging script respectively.

[0107] buildproject.sh mainly implements functions such as obtaining, comparing, compiling, and packaging the md5 value of the code, and can call the exception notification script file when a compilation error occurs.

[0108] Among them, in the secondary directory, projects are created in the Jenkins service for the dynamic library product compilation directory and the executable program compilation directory, and Jenkins can automatically create and pull the latest code. This is a regular operation of the Jenkins software and will not be elaborated here.

[0109] By constructing scripts using md5.txt, buildproject.sh, and package.sh in the compilation and packaging script directory in the tertiary directory, automatic compilation and packaging of the code are achieved.

[0110] As Figure 5 shown, taking the automatic compilation in the linux environment as an example: the process of automatic compilation and packaging of the code includes:

[0111] The first step: Enter the code directory of the dynamic library product compilation directory and the executable program compilation directory;

[0112] The second step: Obtain the md5 value of the code in the code directory;

[0113] Step 3: Verify whether the obtained MD5 value is consistent with the cached MD5 value file. If they are consistent, the process ends; if not, proceed to Step 4.

[0114] Step 4: Perform code compilation and determine whether the code compilation is abnormal. If it is abnormal, trigger an exception message notification and then end the process; if the code compilation is normal, proceed to Step 5.

[0115] Step 5: Call the packaging script to package the product.

[0116] Through the above method, code compilation and packaging can be achieved, and at the same time, repeated compilation and packaging of existing code can be avoided, and only updated code is processed.

[0117] S4. After the code compilation is completed, relying on the Windows server compilation node, complete the code packaging and release operations.

[0118] As Figure 6 shown, the configuration of the Windows server compilation node is similar to that of the Linux server compilation node. The difference is that the build script under Windows is a bat script, and there is an additional packaging and release working directory in the secondary directory, and an additional corresponding packaging and release script directory in the tertiary directory.

[0119] For the packaging and release function, a new project needs to be created on the Jenkins service and configured to be triggered manually. The trigger script is the build script in the packaging and release script directory. At this time, through the input parameter construction function of the packaging and release project in the Jenkins system page, fill in the update log and perform packaging and release.

[0120] Next, relying on the Windows server compilation node, the scripts in the packaging and release script directory are described as follows:

[0121] The packaging and release script directory mainly includes two scripts: build.bat and sendmsg.py.

[0122] Among them, the content of the sendmsg.py script is basically similar to that of the exception notification script file, but this script is mainly used for information notification during release. It is necessary to obtain the update log of this packaging in the script and then send a notification message; in the build.bat script, the dynamic library products and executable program products under the Linux server compilation node, as well as the dynamic library products and executable program products of the Windows version generated under the Windows server compilation node, need to be downloaded to the packaging and release working directory, packaged into a compressed file, and released to the intranet shared directory. After completion, call the sendmsg.py script to send an intranet broadcast message notification. As Figure 7 shown, its main process includes:

[0123] Step 1: Obtain the version number information stored locally in the version information directory and combine it into a complete version number;

[0124] Step 2: Obtain the update log input on the packaging and release project construction page; in actual operation, this information is actively passed in when Jenkins calls the build script, and at this time, it only needs to be obtained through variables in the script;

[0125] Step 3: Copy the locally compiled and packaged dynamic library products and executable program products to the packaging and release working directory;

[0126] Step 4: Download the dynamic library products and executable program products compiled and packaged in the Jenkins node under Linux to the packaging and release working directory;

[0127] Step 5: Write the information obtained in Step 2 to the update log file in an appended manner;

[0128] Step 6: Package the products in the entire packaging and release working directory into a single compressed file;

[0129] Step 7: Upload the packaged compressed file to the intranet shared directory;

[0130] Step 8: Broadcast the completion notice information within the local area network.

[0131] The present invention also provides an electronic device, Figure 8 which is a schematic structural diagram of the electronic device provided by the embodiment of the present invention, as Figure 8 shown. The electronic device may include: a processor, a communication interface, a memory, and a communication bus. Among them, the processor, the communication interface, and the memory complete mutual communication through the communication bus. The processor can call the logical instructions in the memory, for example, to execute the following method:

[0132] S1: Submit the source code of the dynamic library product to the SVN server, and / or submit the source code of the executable product to the GitLab server;

[0133] S2: Use the Jenkins service to monitor the source code submitted to the SVN server or GitLab server and trigger a code pull signal;

[0134] S3: Use the Linux server compilation node and / or the Windows server compilation node to execute a code pull action to the SVN server and / or GitLab server according to the code pull signal. After the code pull is completed, execute a code compilation action;

[0135] S4. After the code compilation is completed, relying on the Windows server compilation node, complete the code packaging and release operations.

[0136] In addition, when the logical instructions in the above-mentioned memory are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art or part of the technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0137] The embodiments of the present invention also provide a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it is configured to execute the methods provided in the above-mentioned embodiments, for example, including:

[0138] S1. Submit the source code of the dynamic library product to the SVN server, and / or submit the source code of the executable product to the GitLab server;

[0139] S2. Use the Jenkins service to monitor the source code submitted to the SVN server or the GitLab server and trigger a code pulling signal;

[0140] S3. Use the Linux server compilation node and / or the Windows server compilation node to perform a code pulling action on the SVN server and / or the GitLab server according to the code pulling signal. After the code pulling is completed, perform a code compilation action;

[0141] S4. After the code compilation is completed, relying on the Windows server compilation node, complete the code packaging and release operations.

[0142] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement it without creative labor.

[0143] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the essence of the above technical solution, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A product release server system for an intranet environment based on Jenkins, characterized in that, Including: The user development environment side is used for users to develop and generate the source code of the dynamic library product and the source code of the executable program product; The SVN server is connected to the user development environment side and is used to host the source code of the dynamic library product; The GitLab server is connected to the user development environment side and is used to host the source code of the executable product; The Jenkins server listens for code updates by polling the status of the SVN server and the GitLab server and triggers a code pull signal; The Linux server deploys a Jenkins agent service compilation node. After receiving the code pull signal from Jenkins, it performs a code pull action. After the code pull is completed, it performs a compilation action; The Windows server deploys a Jenkins agent service compilation node. After receiving the code pull signal from Jenkins, it performs a code pull action. After the code pull is completed, it performs a compilation action. After the compilation is completed, it performs product packaging and release operations; The Linux server deploys a Jenkins agent service compilation node, and the deployment directory includes: a first-level directory, a second-level directory, and a third-level directory, where: The second-level directory is located within the first-level directory and includes a dynamic library product compilation directory, an executable program compilation directory, and a script set directory; The third-level directory is located within the second-level directory script set and includes an exception notification script file, a version information storage directory, a dynamic library product compilation and packaging script directory, and an executable program compilation and packaging script directory; The Windows server deploys a Jenkins agent service compilation node, and the deployment directory includes: a first-level directory, a second-level directory, and a third-level directory, where: The second-level directory is located within the first-level directory and includes a dynamic library product compilation directory, an executable program compilation directory, a packaging and release working directory, and a script set directory; The third-level directory is located within the second-level directory script set and includes an exception notification script file, a version information storage directory, a dynamic library product compilation and packaging script directory, an executable program compilation and packaging script directory, and a packaging and release script directory.

2. A product release method applied to the product release server system in the intranet environment based on Jenkins described in claim 1, characterized in that, Including: S1. The source code of the dynamic library product is submitted to the SVN server, and / or the source code of the executable product is submitted to the GitLab server; S2. Use the Jenkins service to monitor the source code submitted to the SVN server or the GitLab server and trigger a code pull signal; S3. Use the Linux server compilation node and / or the Windows server compilation node to perform a code pull action on the SVN server and / or the GitLab server according to the code pull signal. After the code pull is completed, perform a code compilation action; S4. After the code compilation is completed, rely on the Windows server compilation node to complete the code packaging and release operations.

3. The product release method according to claim 2, wherein In step S2, the Jenkins service is deployed in the Docker environment of the host server, and the deployment steps include: S11. Build a Docker environment on the intranet host server; S12. Create a Docker container in the external network environment; S13. Install the Jenkins service and plugins in the Docker container; S14. Package the installed Docker container into a system image; S15. Load the system image in the Docker environment of the intranet host server.

4. The product release method according to claim 2, characterized in that The files stored in the dynamic library product compilation and packaging script directory or the executable program compilation and packaging script directory include: md5.txt, buildproject.sh, and package.sh script files for compilation and packaging. Among them: md5.txt is used to store the md5 value of the code; buildproject.sh is used to obtain, compare, and compile the md5 value of the code; package.sh is used for product packaging.

5. The product release method according to claim 4, characterized in that Relying on the md5.txt, buildproject.sh, and package.sh script files, the compilation and packaging process includes: S21. Enter the code directory; S22. Obtain the md5 value of the code; S23. Verify whether the obtained md5 value is consistent with the cached md5 value file. If it is consistent, end the process. If it is inconsistent, proceed to step S24; S24. Perform code compilation, and determine whether the code compilation is abnormal. If it is abnormal, trigger an exception message notification and then end the process. If the code compilation is normal, proceed to step S25; S25. Call the packaging script to package the product.

6. The product release method according to claim 2, characterized in that, The files stored in the packaging and release script directory include: build.bat and sendmsg.py script files for packaging and release operations on the Windows server compilation node. Among them: build.bat is used to download the product to the packaging and release working directory and package it into a compressed file; sendmsg.py is mainly used to publish the information notification of the working directory.

7. The product release method according to claim 6, characterized in that, After the code compilation is completed, relying on the Windows server compilation node, complete the code packaging and release operations. The process includes: S31. Obtain the complete version number of the packaging and release; S32. Obtain the update log of the packaging and release; S33. Copy the product compiled and packaged by the Windows system to the packaging and release working directory; S34. Download the product compiled and packaged by the Linux system to the packaging and release working directory; S35. Write the update log in S32 to the update log file in an appended manner; S36. Package the products in the entire packaging and release working directory into a single compressed file; S37. Upload the packaged compressed file to the intranet shared directory; S38. Publish the completion notification information within the local area network.

8. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the product release method described in any one of claims 2-7.

9. A non-transitory computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the product release method described in any one of claims 2-7.

Images