Jenkins-based intranet environment product release server architecture, method, equipment and medium

Abstract

The invention discloses a Jenkins-based intranet environment product release server architecture, method and device and a medium, and the server architecture comprises a user development environment end, an SVN server, a GitLab server, a Jenkins server end, a Linux server and a Windows server, and the server comprises a user code product; the method comprises the steps that a Jenkins service is submitted to an SVN server and a GitLab server, the state of the Jenkins service is polled, a code pulling signal is triggered, a code pulling action is executed by deploying a Jenkins proxy service compiling node, a compiling action is executed, and product packaging and publishing operation are carried out. The invention provides a Jenkins-based architecture and script set, basic functions such as automatic compiling of code submission, compiling error alarm and compiling completion prompt can be realized, and functions such as integration and release functions and conditional packaging of multi-platform products are added according to actual requirements.

Description

Technical Field

[0001] The present invention relates to the technical field of intranet environment software code compilation and packaging, and in particular to an intranet environment product publishing 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 features. However, when it comes to compiled languages ​​such as C++ and multi-platform mixed development scenarios, traditional Jenkins solutions face significant challenges: (1) Insufficient language adaptability: Jenkins is natively friendly to Java projects, but there is a lack of standardized processes for the compilation environment configuration of C++ and other projects (such as cross-platform compiler chains and dependency library management), which requires a large number of manual customized scripts. Especially under the hybrid version control architecture of SVN and GitLab, the complexity of code pulling and version synchronization is significantly increased. (2) Multi-platform collaboration defects: For projects that need to generate Windows / Linux dual-platform products at the same time, the existing solutions often require independent configuration of multiple Jenkins nodes, lack of unified version number management and compilation product integration mechanism, resulting in fragmentation of cross-platform release processes and prone to version inconsistency problems. (3) Intranet environment limitations: Enterprise intranets often have characteristics such as external network isolation and strict security policies, which hinder routine operations such as plug-in installation and dependency download. The traditional external network-oriented Jenkins deployment model is difficult to migrate directly, and lacks lightweight notification solutions (such as the inability to use cloud service email notifications). (4) Automated process discontinuity: Existing implementations are mostly limited to basic compilation functions and lack an end-to-end automated chain. For example, when compilation errors occur, manual log review is required; products on multiple platforms need to be manually aggregated and packaged; and version update logs are disconnected from the release process, which reduces the efficiency of continuous delivery.

[0003] The invention application with application number 202211519834.4 discloses a code packaging verification method and device based on Jenkins. The application scheme can verify the integrity of the code, reduce the workload, improve the efficiency of research and development, and avoid problems in code synchronization. However, the scheme also has the problems of insufficient language adaptability and multi-platform collaboration defects.

[0004] Therefore, a Jenkins-based architecture and script collection is needed to quickly complete the construction of an automated project compilation and release environment under the Jenkins architecture, realize cross-platform code automatic compilation, compilation error alarms, compilation completion prompts, etc., and increase the integration and release functions of multi-platform products, conditional packaging and other functions. Summary of the invention

[0005] In view of the above-mentioned problems, the purpose of the present invention is to provide an intranet environment product publishing server architecture, method, device and medium based on Jenkins to realize multi-platform collaboration, automatic code compilation, error alarm and packaging and publishing operations.

[0006] The embodiment of the present invention provides an intranet environment product publishing server architecture, method, device and medium based on Jenkins.

[0007] Aspect 1: An intranet environment product publishing server architecture based on Jenkins, including: User development environment end, used for users to develop and generate dynamic library product source code and executable program product source code; SVN server, connected to the user development environment, used to host the source code of dynamic library products; GitLab server, connected to the user development environment, is used to host the source code of executable products; The Jenkins server polls the status of the SVN server and GitLab server, monitors code updates, and triggers code pull signals; The Linux server is deployed with a Jenkins agent service compilation node. After receiving the code pull signal from Jenkins, it executes the code pull action. After the code pull is completed, it executes the compilation action; Windows server: A Jenkins agent service compilation node is deployed. After receiving the code pull signal from Jenkins, the code pull action is executed. After the code pull is completed, the compilation action is executed. After the compilation is completed, the product packaging and release operations are performed.

[0008] The second aspect: a method for releasing products in an intranet environment based on Jenkins, 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 GitLab server and trigger the code pull signal. S3, using the Linux server compilation node and / or the Windows server compilation node, according to the code pull signal, to execute the code pull action to the SVN server and / or the GitLab server, and after the code pull is completed, execute the code compilation action; S4. After the code is compiled, the code is packaged and released based on the Windows server compilation node.

[0009] Furthermore, the Jenkins service in S2 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 extranet environment; S13. Install Jenkins service and plugin in Docker container; S14, packaging the installed Docker container into a system image; S15. Load the system image in the Docker environment of the intranet host server.

[0010] Further, said: The Linux server is deployed with a Jenkins agent service compilation node. The deployment directory includes: first-level directory, second-level directory and third-level directory, among which: The secondary directory is located in the primary directory, including the dynamic library product compilation directory, executable program compilation directory and script collection directory; The third-level directory is located in the script collection of the second-level directory, including the exception notification script file, the version information storage directory, the dynamic library product compilation and packaging script directory, and the executable program compilation and packaging script directory; The Windows server is deployed with 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 secondary directory is located in the primary directory, including the dynamic library product compilation directory, executable program compilation directory, package release working directory and script collection directory; The third-level directory is located in the second-level directory script collection, including exception notification script files, version information storage directory, dynamic library product compilation and packaging script directory, executable program compilation and packaging script directory and packaging and release script directory.

[0011] Furthermore, the dynamic library product compilation and packaging script directory or the executable program compilation and packaging script directory stores files including: md5.txt, buildproject.sh and package.sh script files for compilation and packaging, wherein: md5.txt is used to store the md5 value of the code; buildproject.sh is used to obtain, compare and compile code md5 values; package.sh is used for product packaging.

[0012] Furthermore, 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 they are consistent, end the process, if not, proceed to step S24; S24, compile the code and determine whether the code compilation is abnormal. If it is abnormal, trigger an abnormal message notification and end the process; if the code compilation is normal, proceed to step S25; S25. Call the packaging script to package the product.

[0013] Furthermore, the package release script directory stores files including: build.bat and sendmsg.py script files, which are used for Windows server compilation node packaging and release operations, wherein: build.bat is used to download the product to the package release working directory and package it into a compressed file; sendmsg.py is mainly used to publish information notifications of the working directory.

[0014] Furthermore, after the code is compiled, the code packaging and publishing operations are completed based on the Windows server compilation node. The process includes: S31. Obtain the complete version number of the package release; S32, obtaining the update log for packaged release; S33, copy the product compiled and packaged by Windows system to the package release working directory; S34, download the product compiled and packaged by the Linux system to the package release working directory; S35, writing the update log of S32 into the update log file in an appended manner; S36, packaging the products in the entire packaging and publishing working directory into a single compressed file; S37, uploading the packaged compressed file to the intranet shared directory; S38. Publish the completed notification information in the local area network.

[0015] A third aspect: An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method provided in the second aspect when executing the program.

[0016] A fourth aspect: A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in the second aspect.

[0017] Beneficial effects of the present invention: 1. The present invention provides a Jenkins-based architecture and script set to quickly deploy a set of project automation continuous integration and release services for the "SVN+GitLab hybrid hosted Qt project" structure in a local area network environment, which can realize basic functions such as automatic compilation of code submission, compilation error alarm, and compilation completion prompt, and according to actual needs, adds multi-platform product integration and release functions, conditional packaging and other functions, which is particularly suitable for complex project scenarios that need to manage dynamic libraries (SVN) and executable programs (GitLab) at the same time.

[0018] 2. The present invention realizes parallel compilation and automatic integration of multi-platform products through Linux / Windows dual-node architecture and platform-specific scripts. It significantly improves the efficiency of multi-environment construction, avoids the time cost of manually switching compilation environments, and realizes cross-platform compilation and automatic integration.

[0019] 3. The present invention adopts a pre-configured Docker image deployment solution. By pre-building images on the external network and directly loading them on the internal network, it breaks through the barriers of intranet environment dependence on installation and plug-in configuration, shortens the continuous integration environment deployment time from hours to minutes, and accelerates the rapid deployment capability of the intranet.

[0020] 4. The present invention realizes intelligent judgment of incremental compilation through md5 verification comparison and version number management, avoids repeated construction, combines conditional packaging trigger mechanism, reduces resource waste while ensuring code consistency, and realizes intelligent compilation optimization mechanism.

[0021] 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 publishing mechanism of the intranet shared directory, it ensures the version alignment and centralized storage of multi-platform products, reducing the risk of version confusion caused by manual intervention. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a structural diagram of the server architecture for publishing products in an intranet environment based on Jenkins in the present invention; Figure 2 It is a flow chart of the intranet environment product publishing method based on Jenkins of the present invention; Figure 3 A schematic diagram of the deployment environment structure for the Jenkins service of the present invention; Figure 4This is a schematic diagram of the directory structure of the Jenkins proxy service node under the Linux system of the present invention; Figure 5 A schematic diagram of the script compilation and packaging process in the compilation and packaging script directory of the present invention; Figure 6 This is a schematic diagram of the directory structure of the Jenkins proxy service node under the Windows system of the present invention; Figure 7 A schematic diagram of a script packaging and publishing process in a packaged and published script directory of the present invention; Figure 8 It is a schematic diagram of the structure of the electronic device of the present invention. DETAILED DESCRIPTION

[0023] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar symbols throughout represent the same or similar elements or elements with the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0024] Currently, there is a lack of solutions and script sets for intranet environment product publishing servers 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.

[0025] In view of the above problems, the present invention provides an intranet environment product publishing server architecture and method based on Jenkins. Figure 1 A schematic diagram of the structure of an intranet environment product publishing server architecture based on Jenkins provided in an embodiment of the present invention, the architecture includes: The user development environment is used for users to develop and generate dynamic library product source code and executable program product source code.

[0026] SVN server, connected to the user development environment, used to host the source code of dynamic library products; GitLab server, connected to the user development environment, is used to host the source code of executable products; Jenkins server: Jenkins service mainly provides code monitoring and code compilation services. The code monitoring polls the status of SVN server and GitLab server through Jenkins server, queries the code hosting status of SVN server and GitLab server, and generates a code pull signal to send to the proxy service compilation node for code compilation if there is new hosted code.

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

[0028] The Linux server is deployed with a Jenkins agent service compilation node. After receiving the code pull signal from Jenkins, it executes the code pull action. After the code pull is completed, it executes the compilation action to obtain the compiled code product.

[0029] Windows server: A Jenkins agent service compilation node is deployed. After receiving the code pull signal from Jenkins, the code pull action is executed. After the code pull is completed, the compilation action is executed. After the compilation is completed, the compiled code product is obtained, and then the product is packaged and released.

[0030] Based on the above architecture, Figure 2 As shown, the present invention discloses a method for building an intranet environment product publishing server based on Jenkins, comprising: 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.

[0031] The user relies on the development environment to develop and generate dynamic library product source code and / or executable program product source code, and submits it to the SVN server or GitLab server.

[0032] S2. Use the Jenkins service to listen to the source code submitted to the SVN server or GitLab server and trigger the code pull signal.

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

[0034] like Figure 3 As shown in the figure, the services provided by the Jenkins service mainly include monitoring code and code compilation services. When configuring the intranet Jenkins server, you can use the Docker environment deployment solution, 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 of the intranet environment, isolates the connection between the internal and external networks, and has a high degree of confidentiality.

[0035] The following is an introduction to the configuration process of the Jenkins server. The main steps include: First, build a Docker environment on the intranet system host server; Then, create a Docker container in the external network system environment; After that, install the Jenkins service and plugin in the external Docker container; After that, package the Docker container after installing the Jenkins service and plug-in into a system image; Finally, load the system image in the Docker environment of the intranet host server.

[0036] The above configuration method completes the configuration of the Jenkins server. The code compilation service provided by Jenkins is completed by configuring the proxy service node in the Linux server or Windows server.

[0037] S3, Linux server compilation node and Windows service compilation node, according to the code pull signal, execute the code pull action to the SVN server and / or GitLab server, and execute the compilation action after the code pull is completed.

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

[0039] like Figure 4 As shown, taking the Linux server compilation node as an example, after configuring the Jenkins agent service node in the Linux server, the sub-directories formed include the first-level directory, the second-level directory, and the third-level directory.

[0040] Among them, the second-level directory is located in the first-level directory, including the dynamic library product compilation directory, the executable program compilation directory and the script collection directory; the third-level directory is located in 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 and the executable program compilation and packaging script directory.

[0041] Among them, in the third-level directory, the role of the exception notification script file is to use the intranet mail server or the built-in mail notification function of Jenkins for exception notification. If the intranet environment is just a LAN built by a switch and there is no mail server, you can use the python script to implement the message sending notification function of Feiqiu communication software. The main code is as follows: Sender = socker.socket(socket.AF_INET,socketSOCK_DGRAM) Sender.bind(('',9090)) Sender.sendto(('1:1:[custom user name]:[custom account]:32:[custom notification message]').encode('GBK'), ([target IP], 2425)) In actual use, you can specify the IP addresses of several main notification personnel and send notification information traversally.

[0042] The version information storage directory contains two script files, lastversion and baseversion. The baseversion script file is used to store the manually specified major version number, while lastversion stores the submitted version number of the code obtained based on SVN and GitLab.

[0043] The dynamic library compilation and packaging script directory and the executable program compilation and packaging script directory mainly store three files: md5.txt, buildproject.sh and package.sh.

[0044] 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.

[0045] buildproject.sh mainly implements functions such as code md5 value acquisition, comparison, compilation, and packaging. At the same time, it can call the exception notification script file when a compilation error occurs.

[0046] In the secondary directory, the dynamic library product compilation directory and the executable program compilation directory create a project in the Jenkins service, and Jenkins can automatically create and pull the latest code. This is the normal operation of the Jenkins software and will not be explained in detail.

[0047] Automatic compilation and packaging of the code is achieved through the md5.txt, buildproject.sh and package.sh construction scripts in the compilation and packaging script directory in the third-level directory.

[0048] like Figure 5 As shown, taking the automatic compilation in Linux environment as an example: the automatic compilation and packaging process of the code includes: Step 1: Enter the code directory of the dynamic library product compilation directory and the executable program compilation directory; Step 2: Get the md5 value of the code in the code directory; Step 3: Verify whether the obtained md5 value is consistent with the cached md5 value file. If they are consistent, end the process. If not, proceed to step 4. Step 4: Compile the code and determine whether the code compilation is abnormal. If it is abnormal, the abnormal message notification will be triggered and the process will end; if the code compilation is normal, proceed to step 5; Step 5: Call the packaging script to package the product.

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

[0050] S4. After the code is compiled, the code is packaged and released based on the Windows server compilation node.

[0051] like Figure 6 As shown in the figure, 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, there is an additional packaging and publishing working directory in the second-level directory, and an additional corresponding packaging and publishing script directory in the third-level directory.

[0052] For the package release function, you need to create a new project on the Jenkins service and configure manual parameter triggering. The trigger script is the build script in the package release script directory. At this time, you can use the input parameter build function of the package release project on the Jenkins system page, fill in the update log, and package and release.

[0053] The following is an explanation of the scripts in the package release script directory based on the Windows server compilation node: The package release script directory mainly includes two scripts: build.bat script and sendmsg.py script.

[0054] The sendmsg.py script is similar to the exception notification script file in content, but it is mainly used for information notification during release. You need to obtain the update log of this package in the script, and then send the notification message. The build.bat script needs to download the dynamic library products and executable program products under the Linux server compilation node, and the Windows version of the dynamic library products and executable program products generated under the Windows server compilation node to the package release working directory, package them into a compressed file, and publish them to the intranet shared directory. After completion, call the sendmsg.py script to broadcast the message notification on the intranet, such as Figure 7 As shown, its main processes include: Step 1: Get the version number information stored locally in the version information directory and combine it into a complete version number; Step 2: Get the update log input on the package release project build page. In actual operation, this information is actively passed in when Jenkins calls the build script. At this time, you only need to obtain it through variables in the script. Step 3: Copy the locally compiled dynamic library products and executable program products to the package release working directory; Step 4: Download the dynamic library products and executable program products compiled and packaged in the Jenkins node under Linux to the package release working directory; Step 5: Write the information obtained in step 2 into the update log file in an appended manner; Step 6: Package the products in the entire packaging and publishing working directory into a single compressed file; Step 7: Upload the compressed file to the intranet shared directory; Step 8: Broadly publish the completed notification information within the local area network.

[0055] The present invention also provides an electronic device, Figure 8 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention, such as Figure 8 As shown, the electronic device may include: a processor, a communications interface, a memory, and a communications bus, wherein the processor, the communications interface, and the memory communicate with each other via the communications bus. The processor may call the logic instructions in the memory, for example, to execute the following method: 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 GitLab server and trigger the code pull signal. S3, using the Linux server compilation node and / or the Windows server compilation node, according to the code pull signal, to execute the code pull action to the SVN server and / or the GitLab server, and after the code pull is completed, execute the code compilation action; S4. After the code is compiled, the code is packaged and released based on the Windows server compilation node.

[0056] In addition, the logic instructions in the above-mentioned memory can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0057] An embodiment of the present invention further provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the method provided in each of the above embodiments is implemented, for example, 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 GitLab server and trigger the code pull signal. S3, using the Linux server compilation node and / or the Windows server compilation node, according to the code pull signal, to execute the code pull action to the SVN server and / or the GitLab server, and after the code pull is completed, execute the code compilation action; S4. After the code is compiled, the code is packaged and released based on the Windows server compilation node.

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

[0059] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for 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.

[0060] 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 make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A Jenkins-based intranet environment product publishing server architecture, characterized in that: include: User development environment end, used for users to develop and generate dynamic library product source code and executable program product source code; SVN server, connected to the user development environment, used to host the source code of dynamic library products; GitLab server, connected to the user development environment, is used to host the source code of executable products; The Jenkins server polls the status of the SVN server and GitLab server, monitors code updates, and triggers code pull signals; The Linux server is deployed with a Jenkins agent service compilation node. After receiving the code pull signal from Jenkins, it executes the code pull action. After the code pull is completed, it executes the compilation action; Windows server: A Jenkins agent service compilation node is deployed. After receiving the code pull signal from Jenkins, the code pull action is executed. After the code pull is completed, the compilation action is executed. After the compilation is completed, the product packaging and release operations are performed.

2. The product release server architecture according to claim 1, characterized in that: The product publishing method of the product publishing server architecture comprises the following steps: 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 GitLab server and trigger the code pull signal. S3, using the Linux server compilation node and / or the Windows server compilation node, according to the code pull signal, to execute the code pull action to the SVN server and / or the GitLab server, and after the code pull is completed, execute the code compilation action; S4. After the code is compiled, the code is packaged and released based on the Windows server compilation node.

3. The product release server architecture according to claim 2, characterized in that: The Jenkins service in S2 is deployed in the Docker environment of the host server. The deployment steps include: S11. Build a Docker environment on the intranet host server; S12. Create a Docker container in the extranet environment; S13. Install Jenkins service and plugin in Docker container; S14, packaging 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 server architecture according to claim 2, characterized in that: Said: The Linux server is deployed with a Jenkins agent service compilation node. The deployment directory includes: first-level directory, second-level directory and third-level directory, among which: The secondary directory is located in the primary directory, including the dynamic library product compilation directory, executable program compilation directory and script collection directory; The third-level directory is located in the script collection of the second-level directory, including the exception notification script file, the version information storage directory, the dynamic library product compilation and packaging script directory, and the executable program compilation and packaging script directory; The Windows server is deployed with 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 secondary directory is located in the primary directory, including the dynamic library product compilation directory, executable program compilation directory, package release working directory and script collection directory; The third-level directory is located in the second-level directory script collection, including exception notification script files, version information storage directory, dynamic library product compilation and packaging script directory, executable program compilation and packaging script directory and packaging and release script directory.

5. The product release server architecture according to claim 4, characterized in that: The dynamic library product compilation and packaging script directory or the executable program compilation and packaging script directory stores files including: md5.txt, buildproject.sh and package.sh script files for compilation and packaging, wherein: md5.txt is used to store the md5 value of the code; buildproject.sh is used to obtain, compare and compile code md5 values; package.sh is used for product packaging.

6. The product release server architecture according to claim 5, 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 they are consistent, end the process, if not, proceed to step S24; S24, compile the code and determine whether the code compilation is abnormal. If it is abnormal, an abnormal message notification is triggered and the process ends; if the code compilation is normal, go to step S25; S25. Call the packaging script to package the product.

7. The product release server architecture according to claim 4, characterized in that: The package release script directory stores files including: build.bat and sendmsg.py script files, which are used for Windows server compilation node packaging and release operations, where: build.bat is used to download the product to the package release working directory and package it into a compressed file; sendmsg.py is mainly used to publish information notifications of the working directory.

8. The product release server architecture according to claim 7, characterized in that: After the code is compiled, the code is packaged and published based on the Windows server compilation node. The process includes: S31. Obtain the complete version number of the package release; S32, obtaining the update log for packaged release; S33, copy the product compiled and packaged by Windows system to the package release working directory; S34, download the product compiled and packaged by the Linux system to the package release working directory; S35, writing the update log of S32 into the update log file in an appended manner; S36, packaging the products in the entire packaging and publishing working directory into a single compressed file; S37, uploading the packaged compressed file to the intranet shared directory; S38. Publish the completed notification information in the local area network.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the product publishing method of the product publishing server architecture according to any one of claims 2 to 8 are implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the product publishing method of the product publishing server architecture according to any one of claims 2 to 8 are implemented.

Images