Method for automatically constructing and deploying configurable assembly line

Abstract

The invention relates to the technical field of software development, and discloses a method for automatically constructing and deploying a configurable assembly line, which comprises the following steps of: 1, creating a publication list in a user interface module of a publication system, simultaneously receiving publication list information input by a user, checking the validity of the publication list information by a publication list management module, the method comprises the following steps of: checking a Jenkins flow line task template, generating a release list with a unique release list ID after the check is passed, storing release list information and the release list ID into a database, and automatically matching the template, dynamically replacing an application name, a release branch and other variables by a system during release according to an application development language in the release list by pre-configuring the multi-language Jenkins flow line task template. And meanwhile, developers can autonomously create the release list and trigger the process through the release system, operation and maintenance do not need to intervene in task configuration each time, the construction and release efficiency of the whole process time from construction to deployment of the single application is improved, and a high-frequency iteration release scene is adapted.

Description

Technical Field

[0001] This invention relates to the field of software development technology, specifically to a configurable pipeline for automated build and deployment. Background Technology

[0002] With the continuous upgrading of software development processes, enterprises have an increasing demand for fast and stable software building and deployment. Traditional manual packaging and deployment methods, due to their low efficiency and high error rate, can no longer meet the requirements of modern software continuous integration and continuous delivery. Therefore, automated tool-based build and deployment solutions have emerged in the market. Jenkins, as a widely used open-source automation tool, is used by many teams to solve code building and deployment problems and has become one of the core tools in existing automated build and deployment solutions. However, current Jenkins-based solutions have some shortcomings in practical use, such as: First, each release requires operations personnel to manually configure the build task through Jenkins' built-in backend, which is repetitive and lacks flexibility, easily becoming a bottleneck in the development process in scenarios with frequent releases. Second, Jenkins' build log system is independent of the development environment, and developers need to switch to the Jenkins interface to view detailed logs, making it difficult to track the build status in a timely manner or quickly troubleshoot problems. Finally, because the solution is highly dependent on the technical capabilities of operations personnel, they need to be responsible for the configuration, debugging, and management of each task, which cannot achieve full automation. This not only consumes human resources but may also lead to inconsistent configurations or errors due to differences in operations personnel's operations.

[0003] To address the aforementioned issues, there is an urgent need for innovative design based on the existing software development process. Summary of the Invention

[0004] The purpose of this invention is to provide a configurable pipeline for automated build and deployment, in order to solve the problems mentioned in the background art, which require operators to manually configure tasks for each release, lacking flexibility and easily becoming a bottleneck. Furthermore, the method of viewing Jenkins build logs is relatively complex and independent of the development environment, making it difficult for developers to track the build status or troubleshoot in a timely manner.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a configurable pipeline for automated build and deployment, comprising the following steps: Step 1: Create a release order in the user interface module of the publishing system, and receive release order information input by the user. The release order management module checks the validity of the release order information. If the check is successful, a release order with a unique release order ID is generated, and the release order information and release order ID are stored in the database. The release order management module then passes the release order data to the API interaction module. Step 2: The pipeline template management module loads the pre-configured Jenkins pipeline task template according to the development language used in the release order in Step 1. The Jenkins pipeline task template includes standardized operation steps for code retrieval, dependency installation, compilation and building, packaging and deployment. The pipeline template management module uses the application name and release branch in the release order as dynamic variables to replace the preset variables in the Jenkins pipeline task template, generating the final pipeline task configuration data. The pipeline template management module then passes the configuration data to the API interaction module. Step 3: The API interaction module receives the pipeline task configuration data and release order ID. During the build phase, it calls the Jenkins service API interface, uses the pipeline task configuration data to create a Jenkins pipeline task and trigger its execution, and simultaneously receives the unique task ID returned by the Jenkins service. During the deployment phase, the K8S service API interface is called to save the container service and trigger the deployment operation based on the application configuration information. The Jenkins service API interface and the K8S service API interface are called periodically to obtain the build task status and deployment task status respectively. During this process, the task execution status and task ID are passed to the task status monitoring module to update the status of the release order in real time. Step 4: The task status monitoring module receives the task ID, task build status, and task deployment status from Step 3, parses them into readable progress information, and updates the status of the release order in the database. Task status monitoring module: Periodically obtains the build status of Jenkins tasks and the deployment status of K8S tasks through API interface, parses them into readable progress information and updates the status of release orders to the system database; Log display module: Obtains Jenkins build logs and Kubernetes deployment logs through the API interaction module, parses them into a visual format, and stores historical log data; Step 5: The user interface module receives the release status output by the task status monitoring module in Step 4 and the visual logs output by the log display module, and presents them to the user in an intuitive way. The user can view the detailed progress of task execution and key logs through the interface, and provides an entry point for task reconstruction and redeployment.

[0006] By adopting the above technical solution, the entire process of release order creation, template loading, task execution, status monitoring, and visual display is automated, reducing errors caused by human intervention and improving the efficiency of build and deployment.

[0007] Preferably, the release order information in step 1 also includes the application's source code address and build directory, and the same release order in the release order management module can be used for multiple build and deployment operations.

[0008] By adopting the above technical solution, the published information includes the source code address and the build directory, ensuring the accuracy of the data source.

[0009] Preferably, the release order management module manages the user's release operations, generates release orders associated with pipeline tasks, including selecting branches, filling in release parameters, and storing release order status and related information for tracking the release process.

[0010] By adopting the above technical solution, the release process can be traced, reducing reliance on operation and maintenance, and avoiding process chaos caused by non-standard operation.

[0011] Preferably, the Jenkins pipeline task template in step 2 is stored in a designated directory of the release system in FreeMarker template language format. The preset variables also include environment configuration parameters, which include test environment parameters and production environment parameters.

[0012] By adopting the above technical solution, pre-setting environmental parameters, adapting to the deployment needs of multiple environments, reducing configuration errors when manually switching environments, and improving template reusability.

[0013] Preferably, in step 2, the pipeline template management module matches the corresponding environment configuration parameters according to the environment type specified in the release order and performs variable replacement.

[0014] By adopting the above technical solution, parameters are automatically matched and replaced according to the environment type of the release, eliminating the need to manually adjust template variables, thus achieving automated deployment of multiple environments and avoiding deployment problems caused by environment configuration errors.

[0015] Preferably, in step 3, the API interaction module calls the Jenkins service API interface to trigger the execution of the pipeline task in order to obtain the real-time progress of the build task; Calling the K8S service API interface triggers the deployment operation, which is used to obtain the real-time status of the deployment task.

[0016] Using the above technical solution, the API interaction module can obtain the build or deployment status in real time without developers needing to switch to Jenkins or Kubernetes systems to view it, ensuring timely synchronization of process status and making it convenient for developers to keep track of task progress.

[0017] Preferably, after calling the K8S service API interface to perform the deployment operation in step 3, the step also includes an application health check: the API interaction module periodically calls the K8S service API interface to check the application running status. If the check fails N times in a row and the preset timeout period is reached, the deployment task is marked as "failed" and the timeout information is recorded in the log.

[0018] By adopting the above technical solution, post-deployment health checks and timeout failure marking can promptly identify application operation anomalies, avoid service failures caused by the deployment of unqualified applications, and improve deployment reliability.

[0019] Preferably, in step 4, when the log display module parses the build logs and deployment logs, historical log data is stored in association with the release order ID, supporting the query of historical build and deployment logs by release order ID.

[0020] Using the above technical solution, logs are stored in association with release IDs, supporting accurate querying of historical logs without the need to filter tasks in Jenkins, shortening troubleshooting time and enabling traceability of the release chain.

[0021] Preferably, the user interface module in step 5 is built using the ElementUI component library, and the interface includes a release list area, an application information display area, a task status progress bar area, and a log viewing area.

[0022] Using the above technical solution, the interface built by ElementUI contains multiple core areas, providing a unified and intuitive operation entry point, making it convenient for developers to quickly obtain release orders, application information, task status and logs, and improving the user experience.

[0023] Preferably, the user interface module integrates the results output by all modules.

[0024] By adopting the above technical solution, the user interface integrates the results of all modules, eliminating the need for developers to retrieve information across modules, enabling one-stop viewing and operation, reducing operation steps, and further improving efficiency.

[0025] Compared with the prior art, the beneficial effects of the present invention are: the configurable pipeline automated build and deployment method: 1. This invention pre-configures multi-language Jenkins pipeline task templates. During deployment, the system can automatically match the template based on the application development language in the deployment order, dynamically replace variables such as application name and deployment branch to generate configurations, eliminating the need for repetitive operations. At the same time, developers can independently create deployment orders and trigger processes through the deployment system without the need for operations and maintenance to intervene in the configuration of each task. This significantly improves the efficiency of building and deploying a single application from build to deployment, especially suitable for high-frequency iterative deployment scenarios. 2. By automating the entire process, human intervention is avoided. From the verification of release order information to the automatic creation and execution of pipeline tasks, and then to the application health check after deployment, a closed loop of reliability assurance is formed, which effectively reduces the error rate of human operation. This can reduce the release error rate and avoid production risks such as service unavailability caused by operational errors. 3. Through deep integration of the log display module with the release system, one-stop access to logs and status is achieved. The log display module synchronizes Jenkins build logs and K8S deployment logs through the API interaction module, parses them into a visual format, and displays them directly on the release system interface. Developers can view them in real time without cross-system operations. At the same time, all logs are stored in association with a unique release order ID. When troubleshooting issues later, only the release order ID needs to be entered to quickly trace the corresponding full-process logs. 4. Through templated and automated design, operations and maintenance personnel are freed from high-frequency repetitive configuration. The pipeline template only needs to be configured once during system initialization or when a new development language is added. Subsequent releases do not require operations and maintenance intervention. Developers can independently complete operations such as creating release orders, triggering releases, and viewing logs. This facilitates seeking operations and maintenance support in abnormal scenarios, reduces the burden on operations and maintenance personnel, and allows them to focus on core tasks such as infrastructure maintenance and system optimization, thereby improving the overall team's work efficiency. Attached Figure Description

[0026] Figure 1 This is a summary diagram of the module relationships in this invention; Figure 2 A flowchart for constructing this invention; Figure 3 This is a flowchart illustrating the deployment process of the present invention; Figure 4 This is a screenshot of the publishing page of the invention publishing system; Figure 5 The Jenkins build pipeline task diagram is configured for this invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Please see Figures 1-5 This invention provides a technical solution: a configurable pipeline for automated build and deployment, comprising the following steps: Step 1: Create a release order in the user interface module of the publishing system, and receive release order information input by the user. The release order management module checks the validity of the release order information. If the check is successful, a release order with a unique release order ID is generated, and the release order information and release order ID are stored in the database. The release order management module then passes the release order data to the API interaction module. The release order information mentioned in step 1 also includes the application's source code address and build directory. The same release order in the release order management module can be used for multiple build and deployment operations. The release order management module manages users' release operations, generates release orders associated with pipeline tasks, including selecting branches, filling in release parameters, and storing release order status and related information for tracking the release process; Step 2: The pipeline template management module loads the pre-configured Jenkins pipeline task template according to the development language used in the release order in Step 1. The Jenkins pipeline task template includes standardized operation steps for code retrieval, dependency installation, compilation and building, packaging and deployment. The Jenkins pipeline task template mentioned in step 2 is stored in a specified directory of the release system in the FreeMarker template language format. The preset variables also include environment configuration parameters, which include test environment parameters and production environment parameters. In step 2, the pipeline template management module matches the corresponding environment configuration parameters according to the environment type specified in the release order and performs variable replacement. The pipeline template management module uses the application name and release branch in the release order as dynamic variables to replace the preset variables in the Jenkins pipeline task template, generating the final pipeline task configuration data. The pipeline template management module then passes the configuration data to the API interaction module. Step 3: The API interaction module receives the pipeline task configuration data and release order ID. During the build phase, it calls the Jenkins service API interface, uses the pipeline task configuration data to create a Jenkins pipeline task and trigger its execution, and simultaneously receives the unique task ID returned by the Jenkins service. During the deployment phase, the K8S service API interface is called to save the container service and trigger the deployment operation based on the application configuration information. The Jenkins service API interface and the K8S service API interface are called periodically to obtain the build task status and deployment task status respectively. During this process, the task execution status and task ID are passed to the task status monitoring module to update the status of the release order in real time. In step 3, the API interaction module calls the Jenkins service API interface to trigger the execution of pipeline tasks in order to obtain the real-time progress of the build tasks. Calling the K8S service API interface triggers the deployment operation to obtain the real-time status of the deployment task; After the deployment phase in step 3 calls the K8S service API interface to perform the deployment operation, it also includes an application health check step: the API interaction module periodically calls the K8S service API interface to check the application running status. If the check fails N times in a row and the preset timeout period is reached, the deployment task is marked as "failed" and the timeout information is recorded in the log. Step 4: The task status monitoring module receives the task ID, task build status, and task deployment status from Step 3, parses them into readable progress information, and updates the status of the release order in the database. Task status monitoring module: Periodically obtains the build status of Jenkins tasks and the deployment status of K8S tasks through API interface, parses them into readable progress information and updates the status of release orders to the system database; Log display module: Obtains Jenkins build logs and Kubernetes deployment logs through the API interaction module, parses them into a visual format, and stores historical log data; In step 4, when the log display module parses the build logs and deployment logs, historical log data is stored in association with the release order ID, and historical build and deployment logs can be queried by release order ID; Step 5: The user interface module receives the release status output by the task status monitoring module in Step 4 and the visual log output by the log display module, and presents it to the user in an intuitive form. The user can view the detailed progress of the task execution and key logs through the interface, and provides an operation entry point for task reconstruction and redeployment. The user interface module described in step 5 is built using the ElementUI component library. The interface includes a release list area, an application information display area, a task status progress bar area, and a log viewing area. The user interface module integrates the output results of all modules; Referring to the attached diagrams in the instruction manual Figures 1-5 As shown, first, users fill in the release form information through the user interface module built on ElementUI, which includes the application name, development language, release branch, as well as the specific application source code address, build directory, and environment type; After receiving the input information, the release order management module performs validity checks according to its responsibilities of managing release operations and tracking processes. It checks whether the source code address is accessible, whether the release branch exists, and whether the build directory is valid. After the checks pass, a unique release order ID is generated, and the release order information, including the status "to be built", is stored in the database to ensure that the task is traceable. The release order management module passes the release order ID and all release order information to the API interaction module, marking the official start of the automated process. The same release order can be reused, and subsequent builds and deployments do not need to be created again. Historical information can be directly called, reducing repetitive operations for users. After receiving the release order ID and application development language from the API interaction module, the pipeline template management module loads the pre-configured Jenkins pipeline task templates in the specified directory of the release system. The templates are stored in FreeMarker template language format and have built-in standardized operation steps. Personalized parameters are added according to the task. The pipeline template management module extracts the application name and release branch from the release order as dynamic variables, replaces the preset variables in the template, and matches the corresponding environment configuration parameters according to the environment type specified in the release order to complete the full replacement of template variables and generate the final executable pipeline task configuration data. Simultaneously, the pipeline template management module connects to the execution module and sends the final pipeline task configuration data and release order ID back to the API interaction module, providing operation scripts for subsequent calls to Jenkins or K8S to execute tasks. The API interaction module connects to Jenkins builds and Kubernetes deployments, automatically executes tasks according to configuration, and synchronizes status to the monitoring module. The API interaction module uses the final pipeline task configuration data to call the Jenkins service API interface: First, a Jenkins pipeline task associated with the release order is created, the task is executed, the specified branch code is pulled, the dependencies are installed and packaged, and the unique task ID returned by Jenkins is received. The API interaction module periodically calls the Jenkins API to obtain the real-time build progress and passes the task ID and build status to the task status monitoring module. Then, Kubernetes is invoked to automate containerized deployment. Once Jenkins builds successfully, the API interaction module switches to the deployment process. By calling the K8S service API interface, container services are created or updated according to application configuration information, triggering deployment operations. The K8S API is periodically called to obtain the real-time deployment status and synchronized to the task status monitoring module. After deployment is triggered, the API interaction module periodically calls the K8SAPI to check the application's running status; If the health check fails N times in a row and the preset timeout period is reached, the deployment task will be marked as "failed" immediately, and the timeout information will be recorded in the log, namely [YYYY-MM-DDHH:MM:SS] Deployment Timeout: N consecutive health checks failed, to avoid invalid deployment occupying resources; After receiving the task ID, build status, and deployment status from the API interaction module, the task status monitoring module parses the raw status returned by Jenkins or K8S into user-readable progress information and updates the status of the corresponding release order in the database in real time to ensure that the release order status is consistent with the actual task progress. To ensure that issues are traceable: the log display module obtains Jenkins build logs and K8S deployment logs through the API interaction module. First, the logs are parsed into a visual format, sorted by timestamp to distinguish between build logs and deployment logs, and then the logs are associated with release order IDs and stored in the database. This allows for subsequent querying of historical logs by release order ID, providing a basis for troubleshooting. The user interface module integrates the output results of all modules. It receives the final status of the release order from the task status monitoring module and the visual logs from the log display module, and displays them in real time in the log viewing area. Meanwhile, the release list area displays basic information such as release ID and application name, while the application information display area displays details such as source code address and build directory; The user interface module provides entry points for rebuilding and redeploying based on the status of the release order. After the user clicks, the system directly reuses the current release order information and triggers the API interaction module to re-execute the corresponding process, eliminating the need to recreate the release order and further improving operational efficiency.

[0029] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A method for configurable pipelined automated build and deployment, characterized in that, Includes the following steps: Step 1: Create a release order in the user interface module of the publishing system, and receive release order information input by the user. The release order management module checks the validity of the release order information. If the check is successful, a release order with a unique release order ID is generated, and the release order information and release order ID are stored in the database. The release order management module then passes the release order data to the API interaction module. Step 2: The pipeline template management module loads the pre-configured Jenkins pipeline task template according to the development language used in the release order in Step 1. The Jenkins pipeline task template includes standardized operation steps for code retrieval, dependency installation, compilation and building, packaging and deployment. The pipeline template management module uses the application name and release branch in the release order as dynamic variables to replace the preset variables in the Jenkins pipeline task template, generating the final pipeline task configuration data. The pipeline template management module then passes the configuration data to the API interaction module. Step 3: The API interaction module receives the pipeline task configuration data and release order ID. During the build phase, it calls the Jenkins service API interface, uses the pipeline task configuration data to create a Jenkins pipeline task and trigger its execution, and simultaneously receives the unique task ID returned by the Jenkins service. During the deployment phase, the K8S service API interface is called to save the container service and trigger the deployment operation based on the application configuration information. The Jenkins service API interface and the K8S service API interface are called periodically to obtain the build task status and deployment task status respectively. During this process, the task execution status and task ID are passed to the task status monitoring module to update the status of the release order in real time. Step 4: The task status monitoring module receives the task ID, task build status, and task deployment status from Step 3, parses them into readable progress information, and updates the status of the release order in the database. Task status monitoring module: Periodically obtains the build status of Jenkins tasks and the deployment status of K8S tasks through API interface, parses them into readable progress information and updates the status of release orders to the system database; Log display module: Obtains Jenkins build logs and Kubernetes deployment logs through the API interaction module, parses them into a visual format, and stores historical log data; Step 5: The user interface module receives the release status output by the task status monitoring module in Step 4 and the visual logs output by the log display module, and presents them to the user in an intuitive way. The user can view the detailed progress of task execution and key logs through the interface, and provides an entry point for task reconstruction and redeployment.

2. The method for configurable pipeline automated build and deployment according to claim 1, characterized in that: The release order information mentioned in step 1 also includes the application's source code address and build directory. The same release order in the release order management module can be used for multiple build and deployment operations.

3. The method for configurable pipeline automated build and deployment according to claim 1, characterized in that: The release order management module manages users' release operations, generates release orders associated with pipeline tasks, including selecting branches, filling in release parameters, and storing release order status and related information for tracking the release process.

4. The method for configurable pipeline automated build and deployment according to claim 1, characterized in that: The Jenkins pipeline task template mentioned in step 2 is stored in a specified directory of the release system in the FreeMarker template language format. The preset variables also include environment configuration parameters, which include test environment parameters and production environment parameters.

5. The method for configurable pipeline automated build and deployment according to claim 1, characterized in that: In step 2, the pipeline template management module matches the corresponding environment configuration parameters according to the environment type specified in the release order and performs variable replacement.

6. The method for configurable pipelined automated build and deployment according to claim 1, characterized in that: In step 3, the API interaction module calls the Jenkins service API interface to trigger the execution of pipeline tasks in order to obtain the real-time progress of the build tasks. Calling the K8S service API interface triggers the deployment operation, which is used to obtain the real-time status of the deployment task.

7. A configurable pipeline automated build and deployment method according to claim 1, characterized in that: After the deployment phase in step 3 calls the K8S service API interface to perform the deployment operation, it also includes an application health check step: the API interaction module periodically calls the K8S service API interface to check the application running status. If the check fails N times in a row and the preset timeout period is reached, the deployment task is marked as "failed" and the timeout information is recorded in the log.

8. A method for configurable pipelined automated build and deployment according to claim 1, characterized in that: In step 4, when the log display module parses the build logs and deployment logs, historical log data is stored in association with the release order ID, and historical build and deployment logs can be queried by release order ID.

9. A method for configurable pipelined automated build and deployment according to claim 1, characterized in that: The user interface module described in step 5 is built using the ElementUI component library. The interface includes a release list area, an application information display area, a task status progress bar area, and a log viewing area.

10. A method for configurable pipelined automated build and deployment according to claim 1, characterized in that: The user interface module integrates the output results of all modules.

Images