How We Built a Fast, Reliable Mobile CI/CD Pipeline with GitLab and Jenkins

Background

With Youzan Retail’s rapid business growth, the team switched to a weekly release cycle for the mobile client in 2019, demanding a robust CI/CD system that could keep up with frequent changes while maintaining quality.

Problems and Challenges

Developers had to manually submit merge requests, trigger builds, and monitor packaging status, which fragmented their focus and reduced productivity. As the codebase and team expanded, manual coordination became unsustainable, making automated end‑to‑end delivery essential.

Automated Process System

3.1 Process and Architecture

The solution leverages GitLab CI as the core platform, supplemented by Jenkins for auxiliary tasks. The workflow is divided into five parts:

CI (Continuous Integration): GitLab, Jenkins

CD (Continuous Delivery): MBD, APUB, Mobile Assistant App

Checks: compile check, local check, static check

Code Review: Git Hooks, GitLab CI

Messaging & Closure: Enterprise WeChat notifications, group bots, email, report generation, JIRA integration

3.1.1 Process

Developers create a feature branch from dev, commit locally with pre‑commit checks, build a test package, submit it for QA, and after approval merge back into dev. The dev branch undergoes static analysis and regression testing before final acceptance.

3.1.2 Architecture

The architecture consists of GitLab CI pipelines, Jenkins jobs, and integration with the Mobile Build (MBD) platform.

3.2 Packaging and Distribution

3.2.1 Packaging

The mobile build platform MBD supports iOS, Android, and Weex, allowing builds from any branch or version via a remote API. Teams without a custom platform can use Jenkins to automate iOS/Android builds at lower cost.

3.2.2 Distribution

The APUB (App Publish) platform, tightly integrated with MBD, automates the flow from build to release, hot‑fix, and delivery, exposing the Mobile Assistant App for easy download of test and production packages.

Download official and test builds

Switch between internal gateway and development environments

View package metadata (builder, version, size, branch)

3.3 Check System

3.3.1 Compile Check

Compile checks act as a gatekeeper; failing them blocks the build. To avoid pipeline bottlenecks, compile checks run only on trusted branches (e.g., dev, release) via GitLab Runner pipelines, allowing merges only after successful checks.

3.3.2 Local Check

Local checks run as Git hooks before commit, enforcing style, preventing accidental changes to critical config files, and limiting cross‑module modifications. The team uses commit-msg, prepare-commit-msg, and pre-commit hooks.

#!/bin/bash -l
current_dir=$(cd $(dirname $0) && pwd)
scripts_dir=$(dirname $current_dir)
project_dir=$(dirname $scripts_dir)
git_dir="$project_dir/.git"
git_hooks_dir="$git_dir/hooks"

commit_msg="$git_hooks_dir/commit-msg"
analyzer="$current_dir/commit_msg_analyzer.sh"

if [ ! -d $git_dir ]; then
    echo ".git not exist"
    exit 1
fi

if [ -f $commit_msg ]; then
    echo "commit-msg already exist"
    exit 1
else
    if [ -f $analyzer ]; then
        chmod +x $analyzer
        ln -sf $analyzer $commit_msg
        echo "deploy success"
    else
        echo "commit_msg_analyzer.sh not exist"
        exit 1
    fi
fi

The analyzer script ( commit_msg_analyzer.sh) validates commit messages, code style, critical config changes, and cross‑module edits.

#!/bin/bash -l
# Validate commit message format
# Check code style
# Detect critical config modifications
# Detect cross‑module changes
# ...

3.3.3 Static Check

Static analysis catches coding standard violations, defects, and performance issues early. The team uses:

iOS: scan‑build + Infer

Android: Android Lint + FindBugs

Static checks run nightly on reliable branches and can be triggered manually. Results are sent via Enterprise WeChat, and failing issues automatically create JIRA tickets for the responsible module owners.

3.4 Code Review

Code Review is enforced through GitLab Merge Requests. MRs require successful pipelines and approvals from designated reviewers before merging. Reviewers can comment on whole files or individual lines, and the system tracks unresolved comments.

Line‑by‑line commenting with automatic "to‑be‑resolved" status

Configurable approvers and minimum reviewer count

Merge button enabled only after pipeline passes and all comments are resolved

Large changesets can be split into smaller MRs to reduce review overhead, and the team experiments with pre‑splitting MR flow using GitLab Flow.

3.5 Messaging and Closure

Automated notifications reduce manual coordination. The system uses Enterprise WeChat messages, group bots, and email to inform stakeholders of pipeline status and errors.

Enterprise WeChat notifications

Group robot alerts

Enterprise email

To compare two test builds, the team either extracts MR change logs (mandatory "Change Content" field) or uses standardized Git commit messages (e.g., via Commitizen) to generate diff reports, which are then posted to the group bot.

Thoughts and Outlook

The current system is a pragmatic solution; there is no universal best practice. Future work will focus on stricter code‑gate controls and expanding automated testing to reduce manual QA effort, while keeping the workflow lightweight for developers.