Cloud Native 10 min read

How Agricultural Bank Built a Scalable Microservice Platform with DevOps

This article describes Agricultural Bank's "1+1" development model that combines a comprehensive microservice development platform with an end‑to‑end DevOps workflow, enabling rapid, automated delivery of cloud‑native financial applications and achieving industry‑leading continuous delivery maturity.

Efficient Ops
Efficient Ops
Efficient Ops
How Agricultural Bank Built a Scalable Microservice Platform with DevOps

Background

In recent years, buzzwords such as microservices and cloud computing have reshaped the industry. The Financial Accounting platform responded by vertically splitting business, decoupling the monolithic application, and building a platform‑level microservice system. Leveraging this, multiple microservice products were launched to the cloud, supporting business growth and digital transformation.

Why DevOps?

Microservice architecture raises higher demands on product delivery. Continuously improving delivery quality, efficiency, and automation is a key challenge, and DevOps is the digital‑transformation solution.

"1+1" Development Model

The Agricultural Bank "Value‑Added Tax Input Tax Management" project team created a "1+1" development model: one development architecture and one development process.

1 Development Architecture

During the microservice practice, the team built a "Financial Accounting Microservice Application Development Platform" that provides more than 150 components and framework‑level capabilities, including Redis cache, Swagger integration, a generic double‑review framework, idempotency support, XA distributed transactions, RPC circuit breaker, parameterized unit‑test code generator, ATP log generation, global exception handling, transaction code management, CORS support, Ribbon‑based client load balancing, code generators, integration with the bank’s monitoring platform, messaging service, file storage, logging platform, API governance platform, and many others.

These capabilities are abstracted in the development platform; new projects can use the scaffolding and code generators to build a new microservice application in minutes, allowing developers to focus on business logic.

Integrating with existing microservice infrastructure such as Nginx front‑end, Eureka service registry, and Zuul gateway creates a Lego‑style rapid product deployment model.

During DevOps practice, many project‑level functions rely on the platform, such as exposing Swagger specifications to test teams and the ATP platform, automatic unit‑test code generation, and ATP log output for baseline test cases.

1 Development Process

The DevOps practice unifies tools like ITA, TFS, ATP, Jenkins, ACMS, and Xingyun, and incorporates quality checks (JUnit, ESLint, JTest, Checkmarx) into pipelines to raise automation and product quality.

The team defined an end‑to‑end workflow: requirement analysis (front‑end and back‑end Wiki templates) → detailed design (front‑end and back‑end Wiki templates) → work‑item breakdown based on detailed design → task‑code linking (TFS work items and Git feature branches) → branch development (stand‑up meetings) → remote commit (Git pipeline ensures code quality) → branch merge (long‑branch pipeline protects main branch) → development environment build and deployment (image build and pipeline) → test environment deployment (pipeline) → gray deployment (ACMS integrated) → production deployment (ACMS integrated).

Requirement analysis and detailed design use a self‑built Wiki with front‑end and back‑end templates, ensuring design documents serve as pseudo‑code for developers and test case guides.

Work‑item splitting and the Git feature‑branch model guarantee traceability and version consistency; board meetings monitor progress.

Code quality gates (static analysis, security scan, unit tests, manual review) protect the main branch.

Four CI/CD pipelines (development, test, gray, production) automatically build images, verify across environments, and deploy with zero manual steps, greatly improving delivery efficiency and reducing operational risk.

The "1+1" model forms a repeatable microservice development pattern that can be replicated across projects, representing years of microservice and DevOps practice. Ongoing enhancements will continue to empower development.

Achievements

In June 2020, the bank’s projects passed the third‑level assessment of the DevOps Standard Continuous Delivery model, a domestic leading level. The five projects that achieved this are:

Credit Middle‑Office Project

Personal Online Banking Project

Distributed Application Interconnection Platform (AIR) Project

Value‑Added Tax Input Tax Management Project

Financial Mini‑Store Project

Achieving level‑3 continuous delivery indicates that the bank’s projects have reached a leading domestic capability in DevOps.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Software ArchitectureMicroservicesDevOpsContinuous Delivery
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.