How Continuous Delivery Transforms DevOps: Real Cases from Baidu and Tencent

My Journey with "Continuous Delivery"

In 2011 I translated the book Continuous Delivery and have since guided multiple teams at Baidu, Tencent, and other companies to adopt its practices, reflecting on more than a decade of agile and DevOps experience.

What Is Continuous Delivery?

Continuous Delivery is a capability that enables teams to safely and rapidly push any change—features, configuration, or user experience—to production. It aims to break down the walls between development, testing, operations, and business, delivering end‑to‑end value.

Key Concepts

Continuous Integration : Connects development and testing, reducing the development‑testing wall.

Agile Development : Brings product owners into the loop, shrinking the business‑development gap.

DevOps : Targets the operations‑development divide.

Continuous Delivery : Seeks to eliminate all isolation walls across the software lifecycle.

Case Study 1: Baidu

In 2010‑2011 I helped a large search‑service team improve six dimensions: continuous integration, environment deployment, configuration management, data management, test management, and release management.

The team adopted a maturity model from the book, introduced a visual kanban board, and followed a six‑step CI workflow.

Testing was organized into a pyramid: automated subsystem and module tests, with selective system testing and minimal unit testing at the start.

After optimizing compilation with distributed builds and caching, the release cadence shifted from one version every three months to one every two weeks, while automation reduced operational workload and improved quality.

Case Study 2: Tencent

In 2013 I consulted a 400‑person product team that aimed for bi‑weekly beta releases and monthly stable releases. The reality was far slower due to complex processes and inter‑team dependencies.

We applied four steps:

Organizational decoupling – forming small, cross‑functional squads.

Software architecture decoupling – breaking monolithic codebases into modular services.

Configuration management and one‑click deployment – enabling teams to release independently without affecting users.

Automation – reducing the final testing window from two weeks to two hours, with instant rollback on failure.

These changes yielded two daily beta builds, weekly candidate releases, and a monthly stable release, cutting crash rates by 90% and moving the product into the top tier of Tencent’s internal catalog.

Reflections and the "Seven‑Piece" Model

Both cases share a common three‑step approach I call the "Continuous Delivery" three‑step method:

Define the Goal – set clear, business‑driven objectives (e.g., reduce release cycle from two months to one month).

Design Mechanisms and Methods – decide team structures, collaboration practices, and architectural patterns.

Implement Supporting Infrastructure – provide automation, configuration tools, and continuous improvement loops.

Beyond the technical layer, I added two extra dimensions—team collaboration mechanisms and system‑architecture adaptability—forming a "seven‑piece" framework that can be assembled differently depending on product type, team size, and organizational context.

Conclusion

Continuous Delivery is not a one‑size‑fits‑all solution; it requires aligning business goals, team structures, architecture, and automation. When these elements are harmonized, teams can release faster, maintain higher quality, and respond more effectively to market demands.