Applying Jenkins for Build Scheduling in ZheZhe's Continuous Integration System

Author: Chen Qiu

ZheZhe's continuous integration system, Beetle, uses Jenkins as the underlying compilation scheduler; this article shares the team's experience with Jenkins.

Why Jenkins? It is open‑source, has abundant plugins and documentation, and meets current and future performance requirements while reducing development and maintenance costs.

Goals

1. Act as a scheduler for compilation and Sonar analysis, fully controlled by the Beetle platform. 2. Remain a pure scheduler without coupling to business logic.

To achieve these goals, the system must:

1. Categorize project types and unify compilation scripts. 2. Centralize control of compilation scripts and updates. 3. Manage Jenkins config.xml files per project type.

Projects are classified into six types: rpc, web, fe, php, android, and ios. Each type has its own unified build script and a corresponding config.xml stored in Apollo, which can be updated dynamically.

Architecture Overview

(Diagram omitted – shows the overall Jenkins‑based scheduling architecture.)

Specific Process

Job Management

1. Creation: For each GitLab branch, Beetle creates a Jenkins job named after the branch based on the project‑type config.xml . 2. Build: Beetle triggers the appropriate job via Jenkins API. 3. Result: Beetle monitors job execution and displays results on the platform. 4. Deletion: After a branch is released, only the latest five branches are retained; older jobs are removed.

build.sh Content

1. Script Update: Each build machine runs a scheduled task to pull the latest build scripts from GitLab, ensuring all machines use the newest version. 2. Pre‑build Checks: Unified scripts allow consistent pre‑ and post‑build checks, e.g., enforcing FastJSON version constraints for Java projects. 3. Unified Build Process and Artifact Upload.

Key Points

1. Decouple build artifact version from Jenkins build number to allow easy job deletion. 2. Use shallow clone depth = 1 to speed up source checkout. 3. Configure retention policies to discard old builds as needed.

Currently, ZheZhe operates six Linux and two macOS build machines, handling roughly 1,600 builds per day on a single‑master setup. Future plans include adopting new open‑source solutions or Docker‑based multi‑master architectures, which will be straightforward thanks to the decoupled design.

For further reading, see the linked past articles covering related topics such as continuous delivery, UI automation, iOS testing on non‑Mac environments, and performance testing.