ICBC, Zhuhai · DevOps consulting

01 / Consulting scope

Starting with the problems the bank needed to solve.

As a Thoughtworks consultant on an ICBC engagement in Zhuhai, I analysed pain points raised by the bank and provided technical advice and solution options. The work covered deployment standardisation, delivery measurement, test-environment database changes and traffic switching.

I worked through the existing processes and constraints before proposing changes. This meant connecting technical choices with release schedules, audit requirements, team handoffs and the effort needed to adopt a different way of working.

02 / Delivery & measurement

Connecting automation measures to delivery problems.

The bank was improving application deployment and wanted to understand its progress. Existing workflows combined automated pipelines, manual steps and handoffs between development, integration and operations teams. A pipeline could be in use while substantial work still happened outside it.

My analysis followed the release path from build and artifact handoff through deployment and verification. This helped identify where manual work remained and what a measure would need to capture. I recommended a small, obtainable set of measures that fitted the bank’s existing reporting and addressed those specific gaps.

Standardisation also needed clear boundaries: common deployment steps and configuration rules had to leave room for application-specific release needs, including canary strategies. The advice balanced consistency with that flexibility.

Coverage: Identify which applications and release steps use the standard workflow, and where manual intervention remains.
Effort & time: Examine deployment duration, manual work and handoff delays alongside pipeline usage. Agree what each measurement includes.
Quality: Consider successful deployment and recovery measures together with delivery speed, so the assessment reflects how well the process works.

Agree on the measure before building its collection.

The consulting work separated metric definition from collection implementation. First establish the question, calculation and available data; then decide how to collect it. This kept the proposed measures useful and practical to obtain.

03 / Database changes

Keeping database changes consistent across parallel releases.

Test environments were created by cloning VMs while development continued on monthly branches. Database structure changes and data changes were managed in different places. This made it difficult to know the starting state of a new environment and which changes it still needed.

Test database updates also relied on a production pre-release verification workflow, bringing release-related requirements into routine development. I proposed separating the test-environment deployment path and making database versions, baselines and application changes easier to track together.

Recommended checks for test-environment changes

Establish the baselineIdentify the state inherited from the clone and the changes already applied.
Resolve change orderCoordinate overlapping schema and data changes across branches.
Verify compatibilityCheck the resulting schema, data and application behaviour together.

A shared migration history helps track change; coordination and testing establish whether the combined result is correct.

a. Integrate changes earlier

Shorter branches, earlier conflict detection.

Where release constraints allowed, I recommended trunk-based development or shorter-lived feature branches. Frequent integration would expose conflicting schema changes sooner. Adopting it would also require changes to team practices.

b. Retain monthly branches

Make ordering and reconciliation explicit.

If the monthly model remained, late changes to an earlier release needed careful handling in later environments. Replaying migrations or allowing out-of-order changes brought different costs and risks of overwriting or masking conflicts.

The options included Flyway and Liquibase for managing migration histories. Tooling needed to be paired with coordination over shared fields, compatibility tests and care around destructive changes. The existing audit purpose of separate DDL and DML management also had to be considered before recommending consolidation.

Where should a database migration task run?

A related design question arose when considering a move from VM-hosted databases to a container platform: the old assumption of a deployment agent installed on the same VM no longer held. The options included dynamic agents and separate migration jobs, with execution location, network access and resource lifecycle considered together.

04 / Traffic switching

Choosing the right place to control traffic.

I also worked on traffic-switching and canary-release advice. The discussion compared DNS-level routing, API-gateway controls and service-mesh approaches, considering where routing decisions belonged and how much change each option introduced.

Routing scope: Separate directing users to an endpoint from routing requests between application versions and managing service-to-service traffic.
Controlled rollout: Use staged traffic movement, health checks and monitoring to judge whether a new version should receive more traffic or have traffic withdrawn.
Platform fit: Compare gateway and mesh options against the required controls and the complexity the team would need to operate.

Across these topics, my contribution was to turn broad improvement requests into concrete technical decisions: clarify the problem, compare workable options and explain the consequences of each choice.