How Bank of China Standardized DevOps with a Seven‑Step Quality‑Built Pipeline

Standardized Branch Management

The Bank of China IT division adopted a feature‑branch, trunk‑release strategy with five explicit branch types:

Master – production releases; protected, changes only via merge request.

Release – versioned feature releases; protected, merge‑request only.

Develop – integration branch for ongoing development; protected, merge‑request only.

Feature – short‑lived branches for individual user stories; developers may push directly.

Fix – branches for bug‑fixes; direct push allowed.

Protected branches enforce code‑review and CI checks, while Feature/Fix branches give developers flexibility for rapid iteration.

Quality‑Built Seven‑Step Development Process

The workflow splits a feature implementation into seven gated steps, each enforced by automated or manual quality checks.

Feature‑branch creation – Developers create a new branch per agile story (e.g., feat/checkout/zhang/20240401) with a target size of 2–3 days. The branch is rebased daily against Develop to keep it up‑to‑date and avoid long‑lived merge conflicts.

Local code checks – Upon git commit, a pre‑commit hook validates the commit message format and runs language‑specific static analysis (e.g., SonarQube, ESLint, Checkstyle). The hook aborts the commit if syntax errors, rule violations, or prohibited patterns are detected.

CI integration pipeline – Pushing to a Feature branch triggers a CI job that runs:

SonarQube scan with a “zero‑bug, zero‑vulnerability, zero‑code‑smell” quality gate.

Unit‑test execution with a minimum branch coverage threshold (e.g., 80%).

Security scanning (e.g., OWASP Dependency‑Check).

Any failure blocks further progression.

Pre‑compile pipeline (pre‑merge) – When a merge request to Develop is opened, GitLab/GitHub automatically creates a pre‑compile job that compiles the merged code, runs integration tests, and produces a build artifact. The pipeline result must be attached to the merge‑request for reviewer visibility.

Code review – Reviewers examine the attached pipeline results and the code itself against a checklist that includes business‑logic correctness, unit‑test adequacy, and adherence to coding standards. Approval is required before the merge can proceed.

CD pipeline – After approval, the merge request is rebased and merged. This automatically triggers a continuous‑delivery pipeline that deploys the changes to a staging environment, runs smoke tests, and notifies the testing team.

Iterative testing – The successful deployment launches an Automated Test Platform (ATP) suite that executes functional, regression, and performance tests. Test results are fed back to developers for rapid defect resolution.

Toolchain Enhancements

Each product line extends the core DevOps pipeline with domain‑specific scripts, such as:

SQL migration validators that check syntax and idempotency before deployment.

Custom test‑automation wrappers that integrate legacy test frameworks into the CI/CD flow.

Automated code‑generation tools that enforce consistent API contracts.

These extensions reduce manual effort and further lower the risk of human error.

Measured Outcomes

Defect shift – 76.5 % of defects are intercepted during development (local checks, pre‑compile, review) versus only 18.1 % during testing.

Pipeline success rate – After introducing the pre‑compile stage and strict quality gates, successful pipeline executions rose from 65.7 % to 99.3 %.

Feedback acceleration – Replacing a single serial pipeline (~16 min per run) with staged, parallel pipelines reduced total execution time and provided earlier defect feedback.

Future Directions

The organization plans to:

Introduce end‑to‑end automated testing (e.g., contract testing, performance testing) within the CD pipeline.

Deepen cloud‑native integrations such as Kubernetes‑based deployments and serverless functions.

Continuously refine each pipeline stage based on metric‑driven retrospectives to sustain high‑quality, rapid delivery.