Design and Implementation of a Plugin‑Based CI/CD Platform for Mobile App Development

The project background explains that the "ZhiJia" app uses a highly modular, plugin‑based architecture (over 40 iOS core modules, 30 plugins, dozens of Android modules, and many RN components) across multiple business lines, making full‑package local builds difficult for developers and cumbersome for testers, UI designers, and product owners.

Key requirements include enabling developers to focus on their own modules while providing a cooperative build mechanism, allowing testers and other roles to easily obtain testable app packages, supporting automated testing integration, and giving product, UI, and operations teams direct access to downloadable builds for acceptance. Management needs visibility into release progress and the ability to control which modules and plugins are included in each release, as well as seamless integration with external systems such as performance testing and crash‑analysis platforms.

The architecture is divided into three main areas:

Compilation : Jenkins serves as the open‑source CI/CD foundation. A second‑level API layer abstracts various task templates (integration packages, plugin packages, platform layers, RN modules) and provides a unified compilation scheme that can generate complete integration builds on demand.

Process Control : Process templates define the overall integration workflow, business‑line sub‑processes, and auxiliary flows such as hot‑fixes. Teams follow their own sub‑processes, which converge into the main integration flow, reducing inter‑team coupling and improving efficiency.

External System Integration : Hooks expose pipeline status and artifacts to platforms like performance‑automation testing, plugin management, and iOS crash‑analysis services.

Technical implementation details:

1. Jenkins second‑level development – The Java client API ( JenkinsServer jenkins = new JenkinsServer(new URI("http://localhost:8080/jenkins"), "admin", "password"); ) is used to create, update, trigger, and monitor jobs, enabling the abstraction of compilation templates.

2. Process engine – JBPM is chosen for its suitability to the workflow requirements and the team’s familiarity. Each workflow node is encapsulated as a role, allowing dynamic reassignment of responsible personnel and online updates of the process diagram.

Usage statistics show integration of nearly 100 iOS modules, 50 Android modules, and over 75 RN modules, covering dozens of business lines. The platform provides notifications, on‑demand compilation of the latest integration package, and access to operation logs and automated test reports.

Several problems and their solutions are discussed:

Compilation speed – IO bottlenecks were mitigated by mapping the compilation workspace to memory‑mapped storage, allowing unrestricted parallel builds.

Code download – Parallel shallow clones (using --depth=1 ) across multiple repositories dramatically reduced checkout time.

Task‑record mapping – Platform IDs are passed to Jenkins jobs and callbacks are used to reliably associate build records with platform tasks, preventing ID mismatches in parallel builds.

Long API parameters – The original POST implementation that concatenated parameters into the URL was replaced with a proper POST body to avoid build failures.

References include the Jenkins java‑client‑api repository.