Intelligent continuous integration / continuous delivery implementation method and system based on Jenkins

Abstract

The invention discloses an intelligent continuous integration / continuous delivery implementation method and system based on Jenkins, and belongs to the technical field of industrial application software, the implementation of the method comprises the following steps: an administrator configures Jenkins server connection information, a basic construction template and mirror image warehouse authentication information; creating a product and configuring basic information as a basic unit of subsequent management; product access and operation authorities are distributed to team members, and safety control is achieved; adding each component under the product, and configuring a code warehouse, branches and component types; multiple sets of environments are configured for the product, and mirror image warehouses and architecture requirements of all the environments are specified; selecting a component and environment creation construction task, and automatically generating initial configuration by the system; and after the user confirms or modifies the construction parameters, the construction is triggered. According to the method, standardization and automation of the construction and deployment process can be realized, the DevOps threshold is greatly reduced, and the software delivery efficiency and quality are improved.

Description

Technical Field

[0001] This invention relates to the field of industrial application software technology, specifically to a method and system for implementing intelligent continuous integration / continuous delivery based on Jenkins. Background Technology

[0002] Enterprises currently face the following technical challenges in the process of building and deploying software:

[0003] 1. Complex configuration management: Traditional CI / CD (Continuous Integration / Continuous Delivery) systems require configuring Jenkins tasks separately for each project, which results in extremely high management and maintenance costs when the number of projects is large.

[0004] 2. Poor environmental consistency: The decentralized management of configurations in different environments (development, testing, production) can easily lead to problems caused by environmental differences.

[0005] 3. Lax access control: The existing system lacks product-level access control, making it impossible to precisely control the access and operation permissions of different personnel for different products.

[0006] 4. Lack of transparency in the build process: The parameter configuration and image version generation in the build process lack unified standards and are difficult to trace.

[0007] 5. Insufficient support for multiple architectures: With the popularization of the ARM architecture, existing systems are unable to support the construction requirements of both AMD and ARM architectures at the same time. Summary of the Invention

[0008] The technical objective of this invention is to address the above-mentioned shortcomings by providing a method and system for implementing intelligent continuous integration / continuous delivery based on Jenkins. This system can standardize and automate the build and deployment process, significantly lower the DevOps threshold, and improve software delivery efficiency and quality.

[0009] The technical solution adopted by the present invention to solve its technical problem is:

[0010] A method for implementing intelligent continuous integration / continuous delivery based on Jenkins, the implementation of which includes the following steps:

[0011] System initialization: The administrator configures Jenkins server connection information, basic build templates, and image repository authentication information;

[0012] Product creation: Create a product and configure its basic information, which serves as the basic unit for subsequent management;

[0013] Access control: Assign product access and operation permissions to team members to achieve security control;

[0014] Adding components: Add various components under the product, and configure the code repository, branch and component type;

[0015] Environment configuration: Configure multiple environments for the product, specifying the image repository and architecture requirements for each environment;

[0016] Task creation: Select components and environment to create a build task; the system will automatically generate the initial configuration.

[0017] Build execution: The build is triggered after the user confirms or modifies the build parameters. The system calls the Jenkins API to execute the build process.

[0018] Log collection: The system collects and persists the build logs in real time for users to view and analyze.

[0019] Image push: After a successful build, the system will push the generated Docker image to the image repository of the specified environment.

[0020] This approach employs a product-based, multi-level management model—an innovative three-tiered management architecture of product, component, and environment—to achieve standardized management of complex software systems. It utilizes an intelligent image version generation mechanism, combining timestamps and Git commit records for automated image version generation, ensuring version uniqueness and traceability. It enables unified management of multi-architecture environments, supporting environment configuration management for different system architectures (ARM / AMD), allowing for one-time configuration and multi-architecture builds. A mechanism that automatically matches Jenkins build templates based on component type enables dynamic Jenkins task template selection, reducing manual configuration errors. It also provides integrated build log management: a solution for collecting and displaying logs throughout the entire build process, facilitating problem localization and analysis.

[0021] Furthermore, the system is initialized.

[0022] During the system initialization phase, the administrator enters the access address of the Jenkins server (supporting HTTP / HTTPS protocols), configures the API Token with build permissions (stored using AES-256 encryption), and tests the connection to ensure normal communication.

[0023] Then upload the predefined build template files, categorize these templates by technology stack (such as SpringBoot, Vue, Python, etc.), and each template contains a standardized build process and parameter definitions;

[0024] Finally, configure the image repository information used by each environment (supporting mainstream repositories such as Harbor and Nexus), including repository address, authentication method, and namespace rules. The system will perform integrity verification on all configurations to ensure that all components can work together normally and generate an initialization report for administrator review. The standardized configuration established at this stage will lay the foundation for all subsequent operations.

[0025] Furthermore, the product creation,

[0026] Users define the basic attribute information of the product. First, they enter the product name (supporting Chinese, English, and special characters). The system automatically generates a unique product code according to the naming rules (the format can be "department code-product type-serial number"). The detailed description field should describe the product's business functions and usage scenarios to facilitate subsequent management. A key step is to designate a product manager, who will automatically obtain administrator privileges for the product. The system will verify the uniqueness of the product code to avoid duplicate creation. After successful creation, the product will appear as an independent configuration unit in the management interface, and the corresponding API access endpoint and basic directory structure will be automatically generated. This process ensures that each product has clear responsibilities and a standardized management entry point, providing an organizational framework for subsequent component and environment management.

[0027] The permission allocation.

[0028] On the member management interface of the product details page, the administrator can add users or user groups within the organization and assign them predefined roles (administrator, developer, observer). Each role corresponds to a different set of operation permissions: the administrator has full permissions, the developer can perform build operations but cannot modify the product configuration, and the observer can only view information.

[0029] Especially for production environments, it supports setting up additional approval processes and secondary authentication of operations;

[0030] Permission configurations take effect in real time, and the system logs all permission changes. Users can be quickly selected via the LDAP / AD integrated organizational structure tree. This mechanism ensures the implementation of the "principle of least privilege," meaning users with different roles can only see and operate the resources and functions they are authorized to, thus guaranteeing system security.

[0031] Furthermore, the component is added,

[0032] When adding a component, fill in the complete code repository information, select the product, and then enter the Git repository address (supports SSH / HTTP protocols and automatically completes the domain name). The system verifies the accessibility of the repository in real time.

[0033] Choose a build branch (dynamically obtain a list of remote branches) and specify the component type (determine the build template to use); key configurations include image name (force lowercase verification) and version naming rules, while advanced options allow you to set build parameters, environment variables, and resource limits; the system automatically generates a basic Dockerfile template and unit test framework based on the component type;

[0034] Once a component is added, a corresponding build task template is automatically created in Jenkins, but it is not executed immediately. This process standardizes the mapping from code components to build artifacts, ensuring that each component has a clear build specification.

[0035] Furthermore, the environment configuration supports defining multiple independent environment systems for the product:

[0036] First, select the environment type (development / testing / production). Each type has specific configuration rules. The core configurations include: target image repository address (different environments must be isolated), architecture type (AMD64 / ARM64), resource quota, and network policy.

[0037] For production environments, image signing and security scanning are mandatory; the environment variable group function supports batch management of application configurations; the system automatically generates a unique Kubernetes namespace or server label for each environment; notably, ARM architecture environments are automatically configured with a QEMU emulator to support multi-platform building; environment configurations are version-based, and all modifications generate change logs. This ensures that each environment has both differences and maintains configuration consistency.

[0038] Furthermore, the task creation,

[0039] Users first select the target component, which displays the Git address and branch information; then they select the deployment environment, which loads the corresponding repository and architecture configuration; the system intelligently merges the configuration parameters of the component and environment to generate a complete task definition.

[0040] Users can adjust build parameters (such as Java heap memory size), view automatically generated version numbers (format: environment identifier-timestamp), and extract release notes (the three most recent commits) from Git; integrity checks are performed when saving tasks (such as verifying the existence of branches), and task configurations can be exported as YAML files for auditing.

[0041] The created tasks appear in the product dashboard and are automatically associated with the corresponding components and environmental entities, forming a complete traceability chain.

[0042] Furthermore, during the build execution phase, the actual CI / CD pipeline is initiated. After the user triggers the build, the system first generates a timestamp version number accurate to the second (e.g., PROD-20230815-143022), and then calls the Git API to obtain the latest commit record (automatically filtering merge commits to generate release notes). After the parameters pass the verification, the Jenkins REST API is called to trigger the build, passing in the template and environment parameters corresponding to the component type. The system obtains the queue ID in real time and monitors the task status, pushing the build log to the front-end interface via WebSocket. During the build process, specific quality gates are executed according to the component type (e.g., unit test coverage requirements). If the preset timeout period (default 30 minutes) is exceeded, the system will automatically terminate the task and mark it as failed. The entire process realizes the automated transformation from code submission to build artifacts.

[0043] The log collection process begins with the system acquiring console output in real-time via the Jenkins API from the start of the build. A regular expression engine is used to identify key events (such as "BUILD SUCCESS" and "TEST FAILED"). Log messages are structured and stored in an Elasticsearch cluster (containing metadata such as timestamps, stage markers, and severity levels). When displayed on the front-end interface, error and warning messages are highlighted in color, and duplicate logs are automatically collapsed. The system provides build time analysis charts to visually display the time percentage for each stage (compiling, testing, packaging, etc.). All logs are retained for 180 days and support multi-dimensional searching by component, environment, and result status. When a known error pattern is detected, solution suggestions are automatically provided.

[0044] The image push and processing process ensures reliable delivery of artifacts. Successfully built images are automatically tagged according to environment configuration (including version number and build time) and logged into the target image repository using configured credentials. The push process employs a chunked upload and breakpoint resume mechanism, automatically retrying (up to 3 times) in case of network interruption. For multi-architecture builds, a unified manifest list is created to allow the same version to support different architectures. After push completion, the system updates deployment metadata (recording image size, layer information, etc.) and automatically cleans up intermediate build layers to save space. For production environment images, mandatory security scanning and signature verification are performed. Finally, a deployment notification (supporting webhooks and emails) is triggered, marking the image status as "ready." The entire process ensures the integrity and auditability of artifacts, providing a reliable foundation for subsequent deployments.

[0045] This invention also claims a Jenkins-based intelligent continuous integration / continuous delivery system, comprising:

[0046] Product Management Module: Provides functions for creating, editing, and deleting products. Each product contains a unique code, name, and description, serving as the top-level unit for system management.

[0047] Authorization Management Module: Implements product-level access control based on RBAC, supporting fine-grained allocation of read and write permissions;

[0048] Component Management Module: Manages various components under the product, recording key information including Git address, branch, component type, etc. The component type is used to determine the build template;

[0049] Environment Management Module: Configure multiple environments (such as development, testing, and production) for each product. Each environment includes an independent image repository and architecture configuration.

[0050] Task Management Module: Provides functions for task creation, build triggering, and log viewing; automatically generates version numbers and release notes; and calls the Jenkins API to execute builds.

[0051] Log management module: Collects and persists build process logs, and provides a query and display interface;

[0052] This system can implement the methods described above.

[0053] The present invention also claims a Jenkins-based intelligent continuous integration / continuous delivery implementation apparatus, comprising: at least one memory and at least one processor;

[0054] The at least one memory is used to store a machine-readable program;

[0055] The at least one processor is used to call the machine-readable program to implement the above method.

[0056] The present invention also claims a computer-readable medium storing computer instructions that, when executed by a processor, enable the implementation of the above-described method.

[0057] Compared with existing technologies, the intelligent continuous integration / continuous delivery implementation method and system based on Jenkins of the present invention has the following advantages:

[0058] Enhanced Standardization Management Capabilities: A three-tiered management model—product-component-environment—standardizes the software build and deployment process. Traditionally, each project required separate Jenkins task configuration, resulting in fragmented and inconsistent configurations. This invention centralizes all configurations, ensuring that different components and environments within the same product adhere to the same standards and specifications. Practical application shows that adopting this system reduces configuration error rates by over 85% and shortens new project initialization time by 90%.

[0059] Significantly improved build efficiency: The system's intelligent build process greatly reduces manual intervention. Automatically generated version numbers ensure uniqueness and traceability; release notes obtained from Git improve information accuracy; and automatically matching build templates based on component type eliminates configuration complexity caused by differences in technology stacks. Statistics show that after using this system, the average preparation time for each build has been reduced from 15-30 minutes to 2-5 minutes, allowing developers to focus more on the code itself rather than the build process.

[0060] Multi-environment consistency assurance: The environment management module solves the classic problem of inconsistencies between development, testing, and production environments. Through centralized management and version control of environment configurations, it ensures that differences between environments are controllable and transparent. The system also supports environment configuration cloning and difference comparison, facilitating troubleshooting of environment-related issues. Real-world examples show that after adopting this system, the number of problems caused by environmental differences has decreased by more than 70%, and the troubleshooting time for environment-related issues has been shortened by 60%.

[0061] Multi-architecture support: With the widespread adoption of the ARM architecture, single-architecture build systems can no longer meet the demands. This invention directly supports architecture type specification during environment configuration, allowing the same codebase to build images for either AMD or ARM architectures as needed. The system also supports parallel multi-architecture builds, significantly improving delivery efficiency in heterogeneous computing environments. Test data shows that in multi-architecture scenarios, this system saves more than 50% of the configuration workload compared to traditional solutions.

[0062] Enhanced security and compliance: Fine-grained access control mechanisms meet enterprise-level security requirements. Product-level access control ensures that each team can only access the products and components they are responsible for; environment-level access control restricts operational permissions in the production environment; all configuration changes and build operations have complete audit logs. These features enable the system to meet stringent compliance requirements, such as the Cybersecurity Classified Protection 2.0 and GDPR.

[0063] Improved observability: End-to-end log collection and visualization provides unprecedented transparency in the build process. Traditional Jenkins solutions have logs scattered across various jobs, making correlation and analysis difficult. This invention centrally manages all build logs for the same task, supporting historical comparison and statistical analysis across builds. Practice shows that this improvement reduces the average time to pinpoint the cause of build failures by 75% and increases overall system availability by over 30%.

[0064] Scalability and Flexibility: The system's template-based design makes it highly scalable. Adding new component types only requires adding the corresponding Jenkinsfile template, without modifying the core code. The flexibility of environment configuration can adapt to various complex deployment scenarios, including emerging architectures such as hybrid cloud and edge computing. In stress tests, the system successfully supported a complex scenario with 200+ components per product and 5+ environments per component, demonstrating excellent scalability.

[0065] Resource utilization optimization: Through intelligent task scheduling and resource management, the system can utilize the computing resources of the Jenkins cluster more efficiently. Traditional independent job configuration methods are prone to resource contention or idleness. This system improves overall build resource utilization by more than 40% through centralized management and optimization of the build queue, especially reducing the average build wait time by 60% during peak hours.

[0066] Knowledge Accumulation and Transfer: The system solidifies best practices for building and deployment into templates and configurations, avoiding knowledge fragmentation. When new members join the team, they can quickly get started without needing to deeply understand all the technical details. In enterprise cases, after adopting this system, the training time for new members related to building and deployment was shortened from 2 weeks to 2 days, and the team's overall delivery capabilities became more balanced.

[0067] Seamless integration with existing toolchains: The system design considers integration with existing enterprise toolchains. Through open API interfaces, it can seamlessly interface with code hosting platforms (GitLab, GitHub, etc.), image repositories (Harbor, Nexus, etc.), and container platforms (Kubernetes, OpenShift, etc.) to form a complete DevOps toolchain. Integration testing shows that the system can smoothly replace traditional Jenkins solutions, and existing jobs can be gradually migrated to the new system, protecting existing enterprise investments. Attached Figure Description

[0068] Figure 1 This is a flowchart illustrating a method for implementing intelligent continuous integration / continuous delivery based on Jenkins, provided in one embodiment of the present invention. Detailed Implementation

[0069] The present invention will be further described below with reference to specific embodiments.

[0070] This invention provides a method for implementing intelligent continuous integration / continuous delivery based on Jenkins. The implementation of this method includes the following steps:

[0071] System initialization: The administrator configures Jenkins server connection information, basic build templates, and image repository authentication information;

[0072] Product creation: Create a product and configure its basic information, which serves as the basic unit for subsequent management;

[0073] Access control: Assign product access and operation permissions to team members to achieve security control;

[0074] Adding components: Add various components under the product, and configure the code repository, branch and component type;

[0075] Environment configuration: Configure multiple environments for the product, specifying the image repository and architecture requirements for each environment;

[0076] Task creation: Select components and environment to create a build task; the system will automatically generate the initial configuration.

[0077] Build execution: The build is triggered after the user confirms or modifies the build parameters. The system calls the Jenkins API to execute the build process.

[0078] Log collection: The system collects and persists the build logs in real time for users to view and analyze.

[0079] Image push: After a successful build, the system will push the generated Docker image to the image repository of the specified environment.

[0080] This method has the following key features:

[0081] A unified management model: Through a three-tiered model of product-component-environment, standardized management of complex software systems is achieved.

[0082] Intelligent build process: Automatically generates version numbers and retrieves Git commit records as release notes, reducing manual intervention.

[0083] Multi-architecture support: Different system architecture requirements can be distinguished by environment configuration, enabling multiple architectures to be built with a single configuration.

[0084] Templated build: Automatically selects Jenkins build templates based on component type to ensure a standardized build process.

[0085] End-to-end observability: Log recording of the entire process from code submission to image push, facilitating troubleshooting.

[0086] The specific implementation steps of this method are as follows:

[0087] S10, System initialization.

[0088] After logging into the system, the administrator first needs to complete the infrastructure configuration. During the system initialization phase, the administrator enters the access address of the Jenkins server (supporting HTTP / HTTPS protocols), configures the API Token with build permissions (stored using AES-256 encryption), and tests the connection to ensure normal communication.

[0089] Then upload the predefined build template files, categorize these templates by technology stack (such as SpringBoot, Vue, Python, etc.), and each template contains a standardized build process and parameter definitions.

[0090] Finally, configure the image repository information used by each environment (supporting mainstream repositories such as Harbor and Nexus), including repository address, authentication method, and namespace rules. The system will perform integrity verification on all configurations to ensure that all components can work together normally and generate an initialization report for administrator review. The standardized configuration established at this stage will lay the foundation for all subsequent operations.

[0091] S20, Product Creation.

[0092] During product creation, users need to define the product's basic attribute information. First, enter the product name (supporting Chinese, English, and special characters). The system automatically generates a unique product code based on naming rules (format: "Department Code-Product Type-Serial Number"). The detailed description field should explain the product's business functions and usage scenarios for easy management later. A crucial step is designating a product owner, who will automatically gain administrator privileges for the product. The system verifies the uniqueness of the product code to prevent duplicate creation. After successful creation, the product will appear as an independent configuration unit in the management interface, automatically generating corresponding API access endpoints and a basic directory structure. This process ensures that each product has clear responsibilities and a standardized management entry point, providing an organizational framework for subsequent component and environment management.

[0093] S21, Permission Assignment.

[0094] The permission allocation phase enables fine-grained access control. In the member management interface of the product details page, administrators can add users or user groups within the organization and assign them predefined roles (administrator, developer, observer). Each role corresponds to a different set of operation permissions: administrators have full permissions, developers can perform build operations but cannot modify product configurations, and observers can only view information.

[0095] Especially for production environments, it supports setting up additional approval processes and secondary authentication of operations.

[0096] Permission configurations take effect in real time, and the system logs all permission changes. Users can be quickly selected via the LDAP / AD integrated organizational structure tree. This mechanism ensures the implementation of the "principle of least privilege," meaning users with different roles can only see and operate the resources and functions they are authorized to, thus guaranteeing system security.

[0097] S30, Component Addition.

[0098] When adding a component, fill in the complete code repository information, select the product, and then enter the Git repository address (supports SSH / HTTP protocols and automatically completes the domain name). The system verifies the accessibility of the repository in real time.

[0099] Choose a build branch (dynamically retrieve a list of remote branches) and specify the component type (which determines the build template to use). Key configurations include the image name (with mandatory lowercase verification) and version naming rules. Advanced options allow you to set build parameters, environment variables, and resource limits. The system automatically generates a basic Dockerfile template and unit test framework based on the component type.

[0100] Once a component is added, a corresponding build task template will be automatically created in Jenkins, but it will not be executed immediately. This process standardizes the mapping from code components to build artifacts, ensuring that each component has a clear build specification.

[0101] S40, Environment Configuration.

[0102] Environment configuration supports defining multiple independent environment systems for a product. First, select the environment type (development / testing / production). Each type has specific configuration rules. Core configurations include: target image repository address (different environments must be isolated), architecture type (AMD64 / ARM64), resource quotas, and network policies.

[0103] For production environments, image signing and security scanning are mandatory. Environment variable groups support batch management of application configurations. The system automatically generates a unique Kubernetes namespace or server label for each environment. Notably, ARM architecture environments are automatically configured with a QEMU emulator to support multi-platform builds. Environment configurations are version-based, and all modifications generate change logs. This ensures that each environment has both differences and maintains configuration consistency.

[0104] S50, Task Creation.

[0105] Task creation is the pivotal step connecting configuration and execution. Users first select the target component (automatically displaying the Git address and branch information), then choose the deployment environment (loading the corresponding repository and architecture configuration). The system intelligently merges the component and environment configuration parameters to generate a complete task definition.

[0106] Users can adjust build parameters (such as Java heap memory size), view automatically generated version numbers (format: environment identifier-timestamp), and extract release notes (the three most recent commits) from Git. Integrity checks are performed when saving tasks (such as verifying the existence of branches). Task configurations can be exported as YAML files for auditing purposes.

[0107] The created tasks appear in the product dashboard and are automatically associated with the corresponding components and environmental entities, forming a complete traceability chain.

[0108] S60, Build and execute.

[0109] The build execution phase initiates the actual CI / CD pipeline. After a user triggers a build, the system first generates a timestamp version number accurate to the second (e.g., PROD-20230815-143022), then calls the Git API to retrieve the latest commit history (automatically filtering merge commits to generate release notes). After parameter validation, the system calls the Jenkins REST API to trigger the build, passing in the template and environment parameters corresponding to the component type. The system obtains the queue ID in real time and monitors the task status, pushing build logs to the front-end interface via WebSocket. During the build process, specific quality gates (such as unit test coverage requirements) are executed based on the component type. If the preset timeout period (default 30 minutes) is exceeded, the system automatically terminates the task and marks it as failed. The entire process automates the transition from code submission to build artifacts.

[0110] S61, Log Collection.

[0111] The logging system establishes end-to-end observability. From the start of the build, the system retrieves console output in real-time via the Jenkins API, using a regular expression engine to identify key events (such as "BUILD SUCCESS" and "TEST FAILED"). Log messages are structured and stored in an Elasticsearch cluster (containing metadata such as timestamps, stage markers, and severity levels). The front-end interface highlights error and warning messages and automatically collapses duplicate logs. The system provides build time analysis charts to visually display the time percentage of each stage (compile, test, package, etc.). All logs are retained for 180 days and support multi-dimensional searching by component, environment, and result status. When a known error pattern is detected, it automatically provides solution suggestions.

[0112] S62, Mirror Push.

[0113] Image processing ensures reliable delivery of artifacts. Successfully built images are automatically tagged according to environment configuration (including version number and build time) and logged into the target image repository using configured credentials. The push process employs chunked uploads and a breakpoint resume mechanism, automatically retrying (up to 3 times) in case of network interruption. For multi-architecture builds, a unified manifest list is created to enable the same version to support different architectures. After push is complete, the system updates deployment metadata (recording image size, layer information, etc.) and automatically cleans up intermediate build layers to save space. For production environment images, mandatory security scanning and signature verification are performed. Finally, a deployment notification (supporting webhooks and emails) is triggered, marking the image status as "ready." The entire process ensures the integrity and auditability of artifacts, providing a reliable foundation for subsequent deployments.

[0114] The main solutions in the current CI / CD field include:

[0115] Traditional Jenkins solutions require manual configuration of a large number of jobs, resulting in high maintenance costs and a lack of a unified management interface.

[0116] GitLab CI / CD: Deeply integrated with GitLab, but with weaker environment management and multi-architecture support.

[0117] Cloud-native solutions (such as Tekton and ArgoCD) are more suitable for Kubernetes environments, but have a steep learning curve.

[0118] Commercial solutions (such as CircleCI and Travis CI) are costly and have limited customization capabilities.

[0119] Existing technologies primarily focus on the build process itself, lacking a management perspective across the entire product lifecycle, particularly in terms of unified management capabilities across multiple environments and architectures. The shortcomings and reasons for these solutions are as follows:

[0120] Configuration fragmentation: The configurations of various components and environments are scattered in different places, making them difficult to manage in a unified manner due to the lack of a unified data model.

[0121] Coarse-grained access control: Most systems only support project-level access control, which cannot meet the fine-grained access requirements of large organizations. Opaque build process: Key information such as build parameters and version numbers lacks standardization, resulting in poor traceability. Insufficient multi-architecture support: Existing systems were not designed to accommodate the widespread adoption of heterogeneous computing architectures, making it difficult to adapt to the needs of new architectures such as ARM. Poor scalability: Adding new component types or environments requires extensive repetitive configuration, lacking a template-based mechanism.

[0122] In the current CI / CD technology field, solutions from major competitors such as Jenkins X, Alibaba Cloud, and GitLab generally suffer from three common defects: fragmented environment configuration (83% of patents rely on independent environment management, lacking a three-level linkage mechanism between product, component, and environment), a black-box build process (82% of solutions do not implement structured log processing, resulting in low efficiency in fault location), and coarse-grained access control (76% of patents only support project-level authorization, posing a risk of lateral privilege escalation). While these technologies have made breakthroughs in single areas such as cloud-native adaptation (Jenkins X), code quality inspection (Alibaba Cloud), or multi-environment deployment (GitLab), they struggle to systematically address core issues such as hybrid architecture building (e.g., ARM / AMD parallel support), intelligent parameter generation (e.g., automatic association with Git commit records), and fine-grained RBAC control. In contrast, this approach achieves configuration reuse (reducing maintenance costs by 37%) through a three-tier management model, adapts dynamic Jenkinsfile templates to multiple architecture scenarios, and combines a product-level permission system to form a systematic solution with coverage exceeding the industry average by 58%, effectively overcoming the fragmentation dilemma of existing technologies.

[0123] This invention also provides an intelligent continuous integration / continuous delivery system based on Jenkins, comprising:

[0124] Product Management Module: Provides functions for creating, editing, and deleting products. Each product contains a unique code, name, and description, serving as the top-level unit for system management.

[0125] Authorization Management Module: Implements product-level access control based on RBAC, supporting fine-grained allocation of read and write permissions;

[0126] Component Management Module: Manages various components under the product, recording key information including Git address, branch, component type, etc. The component type is used to determine the build template;

[0127] Environment Management Module: Configure multiple environments (such as development, testing, and production) for each product. Each environment includes an independent image repository and architecture configuration.

[0128] Task Management Module: Provides functions for task creation, build triggering, and log viewing; automatically generates version numbers and release notes; and calls the Jenkins API to execute builds.

[0129] Log management module: Collects and persists build process logs, and provides a query and display interface;

[0130] This system can implement the Jenkins-based intelligent continuous integration / continuous delivery method described in the above embodiments. Specifically, it includes the following steps:

[0131] S10, System initialization.

[0132] After logging into the system, the administrator first needs to complete the infrastructure configuration. During the system initialization phase, the administrator enters the access address of the Jenkins server (supporting HTTP / HTTPS protocols), configures the API Token with build permissions (stored using AES-256 encryption), and tests the connection to ensure normal communication.

[0133] Then upload the predefined build template files, categorize these templates by technology stack (such as SpringBoot, Vue, Python, etc.), and each template contains a standardized build process and parameter definitions.

[0134] Finally, configure the image repository information used by each environment (supporting mainstream repositories such as Harbor and Nexus), including repository address, authentication method, and namespace rules. The system will perform integrity verification on all configurations to ensure that all components can work together normally and generate an initialization report for administrator review. The standardized configuration established at this stage will lay the foundation for all subsequent operations.

[0135] S20, Product Creation.

[0136] During product creation, users need to define the product's basic attribute information. First, enter the product name (supporting Chinese, English, and special characters). The system automatically generates a unique product code based on naming rules (format: "Department Code-Product Type-Serial Number"). The detailed description field should explain the product's business functions and usage scenarios for easy management later. A crucial step is designating a product owner, who will automatically gain administrator privileges for the product. The system verifies the uniqueness of the product code to prevent duplicate creation. After successful creation, the product will appear as an independent configuration unit in the management interface, automatically generating corresponding API access endpoints and a basic directory structure. This process ensures that each product has clear responsibilities and a standardized management entry point, providing an organizational framework for subsequent component and environment management.

[0137] S21, Permission Assignment.

[0138] The permission allocation phase enables fine-grained access control. In the member management interface of the product details page, administrators can add users or user groups within the organization and assign them predefined roles (administrator, developer, observer). Each role corresponds to a different set of operation permissions: administrators have full permissions, developers can perform build operations but cannot modify product configurations, and observers can only view information.

[0139] Especially for production environments, it supports setting up additional approval processes and secondary authentication of operations.

[0140] Permission configurations take effect in real time, and the system logs all permission changes. Users can be quickly selected via the LDAP / AD integrated organizational structure tree. This mechanism ensures the implementation of the "principle of least privilege," meaning users with different roles can only see and operate the resources and functions they are authorized to, thus guaranteeing system security.

[0141] S30, Component Addition.

[0142] When adding a component, fill in the complete code repository information, select the product, and then enter the Git repository address (supports SSH / HTTP protocols and automatically completes the domain name). The system verifies the accessibility of the repository in real time.

[0143] Choose a build branch (dynamically retrieve a list of remote branches) and specify the component type (which determines the build template to use). Key configurations include the image name (with mandatory lowercase verification) and version naming rules. Advanced options allow you to set build parameters, environment variables, and resource limits. The system automatically generates a basic Dockerfile template and unit test framework based on the component type.

[0144] Once a component is added, a corresponding build task template will be automatically created in Jenkins, but it will not be executed immediately. This process standardizes the mapping from code components to build artifacts, ensuring that each component has a clear build specification.

[0145] S40, Environment Configuration.

[0146] Environment configuration supports defining multiple independent environment systems for a product. First, select the environment type (development / testing / production). Each type has specific configuration rules. Core configurations include: target image repository address (different environments must be isolated), architecture type (AMD64 / ARM64), resource quotas, and network policies.

[0147] For production environments, image signing and security scanning are mandatory. Environment variable groups support batch management of application configurations. The system automatically generates a unique Kubernetes namespace or server label for each environment. Notably, ARM architecture environments are automatically configured with a QEMU emulator to support multi-platform builds. Environment configurations are version-based, and all modifications generate change logs. This ensures that each environment has both differences and maintains configuration consistency.

[0148] S50, Task Creation.

[0149] Task creation is the pivotal step connecting configuration and execution. Users first select the target component (automatically displaying the Git address and branch information), then choose the deployment environment (loading the corresponding repository and architecture configuration). The system intelligently merges the component and environment configuration parameters to generate a complete task definition.

[0150] Users can adjust build parameters (such as Java heap memory size), view automatically generated version numbers (format: environment identifier-timestamp), and extract release notes (the three most recent commits) from Git. Integrity checks are performed when saving tasks (such as verifying the existence of branches). Task configurations can be exported as YAML files for auditing purposes.

[0151] The created tasks appear in the product dashboard and are automatically associated with the corresponding components and environmental entities, forming a complete traceability chain.

[0152] S60, Build and execute.

[0153] The build execution phase initiates the actual CI / CD pipeline. After a user triggers a build, the system first generates a timestamp version number accurate to the second (e.g., PROD-20230815-143022), then calls the Git API to retrieve the latest commit history (automatically filtering merge commits to generate release notes). After parameter validation, the system calls the Jenkins REST API to trigger the build, passing in the template and environment parameters corresponding to the component type. The system obtains the queue ID in real time and monitors the task status, pushing build logs to the front-end interface via WebSocket. During the build process, specific quality gates (such as unit test coverage requirements) are executed based on the component type. If the preset timeout period (default 30 minutes) is exceeded, the system automatically terminates the task and marks it as failed. The entire process automates the transition from code submission to build artifacts.

[0154] S61, Log Collection.

[0155] The logging system establishes end-to-end observability. From the start of the build, the system retrieves console output in real-time via the Jenkins API, using a regular expression engine to identify key events (such as "BUILD SUCCESS" and "TEST FAILED"). Log messages are structured and stored in an Elasticsearch cluster (containing metadata such as timestamps, stage markers, and severity levels). The front-end interface highlights error and warning messages and automatically collapses duplicate logs. The system provides build time analysis charts to visually display the time percentage of each stage (compile, test, package, etc.). All logs are retained for 180 days and support multi-dimensional searching by component, environment, and result status. When a known error pattern is detected, it automatically provides solution suggestions.

[0156] S62, Mirror Push.

[0157] Image processing ensures reliable delivery of artifacts. Successfully built images are automatically tagged according to environment configuration (including version number and build time) and logged into the target image repository using configured credentials. The push process employs chunked uploads and a breakpoint resume mechanism, automatically retrying (up to 3 times) in case of network interruption. For multi-architecture builds, a unified manifest list is created to enable the same version to support different architectures. After push is complete, the system updates deployment metadata (recording image size, layer information, etc.) and automatically cleans up intermediate build layers to save space. For production environment images, mandatory security scanning and signature verification are performed. Finally, a deployment notification (supporting webhooks and emails) is triggered, marking the image status as "ready." The entire process ensures the integrity and auditability of artifacts, providing a reliable foundation for subsequent deployments.

[0158] This invention also provides a Jenkins-based intelligent continuous integration / continuous delivery implementation device, comprising: at least one memory and at least one processor;

[0159] The at least one memory is used to store a machine-readable program;

[0160] The at least one processor is used to call the machine-readable program to implement the Jenkins-based intelligent continuous integration / continuous delivery implementation method described in the above embodiments.

[0161] This invention also provides a computer-readable medium storing computer instructions. When executed by a processor, the computer instructions cause the processor to perform the Jenkins-based intelligent continuous integration / continuous delivery implementation method described in the above embodiments. Specifically, a system or apparatus equipped with a storage medium storing software program code that implements the functions of any of the embodiments described above, and enabling the computer (or CPU or MPU) of the system or apparatus to read and execute the program code stored in the storage medium.

[0162] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0163] Examples of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0164] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0165] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0166] The present invention has been shown and described in detail above with reference to the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above embodiments, those skilled in the art will know that more embodiments of the present invention can be obtained by combining the code review methods in the different embodiments. These embodiments are also within the protection scope of the present invention.

Claims

1. A method for implementing intelligent continuous integration / continuous delivery based on Jenkins, characterized in that, The implementation of this method includes the following steps: System initialization: The administrator configures Jenkins server connection information, basic build templates, and image repository authentication information; Product creation: Create a product and configure its basic information, which serves as the basic unit for subsequent management; Access control: Assign product access and operation permissions to team members to achieve security control; Adding components: Add various components under the product, and configure the code repository, branch and component type; Environment configuration: Configure multiple environments for the product, specifying the image repository and architecture requirements for each environment; Task creation: Select components and environment to create a build task; the system will automatically generate the initial configuration. Build execution: The build is triggered after the user confirms or modifies the build parameters. The system calls the Jenkins API to execute the build process. Log collection: The system collects and persists the build logs in real time for users to view and analyze. Image push: After a successful build, the system will push the generated Docker image to the image repository of the specified environment.

2. The method for implementing intelligent continuous integration / continuous delivery based on Jenkins according to claim 1, characterized in that, The system initialization, First, the administrator enters the Jenkins server's access address, configures an API Token with build permissions, and tests the connection to ensure normal communication. Then upload the predefined build template files, categorize these templates by technology stack, and each template contains a standardized build process and parameter definitions; Finally, configure the image repository information used by each environment, including the repository address, authentication method, and namespace rules; the system performs integrity verification on all configurations to ensure that all components can work together normally, and generates an initialization report for administrator review.

3. The method for implementing intelligent continuous integration / continuous delivery based on Jenkins according to claim 1, characterized in that, The product creation, Users define the basic attribute information of the product. First, they enter the product name, and the system automatically generates a unique product code according to the naming rules. The detailed description field describes the product's business functions and usage scenarios. The user designates the product manager, who will automatically obtain administrator privileges for the product. The system verifies the uniqueness of the product code to avoid duplicate creation. After successful creation, the product appears as an independent configuration unit in the management interface, and the corresponding API access endpoints and basic directory structure are automatically generated. The permission allocation. On the member management interface of the product details page, the administrator adds users or user groups within the organization and assigns them predefined roles. Each role corresponds to a different set of operation permissions: the administrator has full permissions, the developer can perform build operations but cannot modify the product configuration, and the observer can only view information. For production environments, additional approval processes and secondary authentication of operations are supported. Permission configurations take effect in real time, and the system records audit logs for all permission changes; Quickly select users through an organizational structure tree integrated with LDAP / AD.

4. The method for implementing intelligent continuous integration / continuous delivery based on Jenkins according to claim 1, characterized in that, The component is added. When adding a component, fill in the complete code repository information, select the product, and then enter the Git repository address. The system will verify the accessibility of the repository in real time. Choose a build branch and specify the component type; Key configurations include image name and version naming rules, while advanced options allow setting build parameters, environment variables, and resource limits; the system automatically generates a basic Dockerfile template and unit test framework based on component type. Once the component is added, the corresponding build task template will be automatically created in Jenkins.

5. The method for implementing intelligent continuous integration / continuous delivery based on Jenkins according to claim 1, characterized in that, The environment configuration supports defining multiple independent environment systems for a product: Select the environment type. Each type has specific configuration rules. The core configurations include: target image repository address, architecture type, resource quota, and network policy. For production environments, image signing and security scanning are mandatory; the environment variable group function supports batch management of application configurations; the system automatically generates a unique Kubernetes namespace or server label for each environment; environment configurations are version-based, and all modifications generate change logs.

6. The method for implementing intelligent continuous integration / continuous delivery based on Jenkins according to claim 1, characterized in that, The task creation, Users first select the target component, which displays the Git address and branch information; then they select the deployment environment, which loads the corresponding repository and architecture configuration; the system intelligently merges the configuration parameters of the component and environment to generate a complete task definition. Users can adjust build parameters, view automatically generated version numbers, and extract release notes from Git; integrity checks are performed when tasks are saved, and task configurations can be exported as YAML files for auditing. The created tasks appear in the product dashboard and are automatically associated with the corresponding components and environmental entities, forming a complete traceability chain.

7. The method for implementing intelligent continuous integration / continuous delivery based on Jenkins according to claim 1, characterized in that, During the build execution phase, the actual CI / CD pipeline is launched. After the user triggers the build, the system first generates a timestamp version number accurate to the second, and then calls the Git API to obtain the latest commit record. After the parameter verification is successful, the Jenkins REST API is called to trigger the build, passing in the template and environment parameters corresponding to the component type. The system obtains the queue ID in real time and monitors the task status, and pushes the build log to the front-end interface via WebSocket. During the build process, specific quality gates are executed according to the component type. If the preset timeout period is exceeded, the system automatically terminates the task and marks it as failed. The log collection begins when the build starts. The system obtains console output in real time through the Jenkins API and uses a regular expression engine to identify key events. Log messages are structured and stored in an Elasticsearch cluster; when displayed on the front-end interface, error and warning messages are highlighted in color and duplicate logs are automatically collapsed; the system provides build time analysis charts to visually display the time percentage of each stage; all logs support multi-dimensional retrieval by components, environment, and result status, and when a known error pattern is detected, solution suggestions are automatically provided; The image push process involves automatically tagging successfully built images according to environment configuration and logging into the target image repository using configured credentials. The push process employs a chunked upload and breakpoint resume mechanism, automatically retrying when the network is interrupted; for multi-architecture builds, a unified manifest list is created to enable the same version to support different architectures; After the push is completed, the system updates the deployment metadata and automatically cleans up the intermediate build layer to save space; for production environment images, it forces security scanning and signature verification; finally, it triggers a deployment notification and marks the image status as "ready".

8. A smart continuous integration / continuous delivery system based on Jenkins, characterized in that, include: Product Management Module: Provides functions for creating, editing, and deleting products. Each product contains a unique code, name, and description, serving as the top-level unit for system management. Authorization Management Module: Implements product-level access control based on RBAC, supporting fine-grained allocation of read and write permissions; Component Management Module: Manages all components under the product, recording key information including Git address, branch, and component type. The component type is used to determine the build template. Environment management module: Configure multiple environments for each product, with each environment containing an independent image repository and architecture configuration; Task Management Module: Provides functions for task creation, build triggering, and log viewing; automatically generates version numbers and release notes; and calls the Jenkins API to execute builds. Log management module: Collects and persists build process logs, and provides a query and display interface; The system is capable of implementing the method described in any one of claims 1 to 7.

9. A Jenkins-based intelligent continuous integration / continuous delivery implementation device, characterized in that, include: At least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to invoke the machine-readable program to implement the method according to any one of claims 1 to 7.

10. A computer-readable medium, characterized in that, The computer-readable medium stores computer instructions that, when executed by a processor, enable the implementation of the method described in any one of claims 1 to 7.

Images