Continuous Delivery Practices and Automation at Meituan Waimai

Meituan Waimai has grown rapidly since its launch in 2013, handling over 30 million daily orders and expanding from a single food delivery service to a platform that includes flash sales, errands, payments, marketing, and advertising. All business teams share a common demand: how to get features released quickly.

0. Introduction

The article reviews the evolution of Meituan Waimai’s delivery models—from early monthly releases, to bi‑weekly releases, and finally a hybrid bi‑weekly plus weekly model—highlighting the key factors that enable effective continuous delivery.

1. Delivery Model

Software delivery involves many stages (requirement analysis, design, coding, testing, deployment). Traditional models (waterfall, iterative, spiral, agile) have been explored, but the focus here is on practical, business‑driven delivery.

2. What is Continuous Delivery?

Continuous Delivery is defined as a product‑value development framework that includes principles and practices to accelerate internal operations and delivery efficiency. It differs from Continuous Integration (code‑to‑build) and Continuous Deployment (code‑to‑users). In Meituan Waimai, it represents a tight feedback loop between users and the delivery team (PM, UI/UX, RD, QA).

3. Evolution of Waimai’s Delivery Model

3.1 Early Serial Delivery

The early model followed a linear “serial” flow with eight steps: requirement review, development, multiple test rounds, gray release, and full release. A version cycle lasted about 6.5 weeks, yielding 11‑12 releases per year.

3.2 Bi‑weekly Iteration

To meet growing business demands, a bi‑weekly release cadence was introduced, parallelizing review, development, and testing. The cycle was reduced to ~5.5 weeks, increasing releases to 22‑24 per year. Key weekly activities (W1‑W7) were defined, and a grouping strategy (AB groups) was applied to balance workload and reduce context switching.

3.3 Bi‑weekly + Weekly Iteration

Further refinement added a weekly dynamic release window for fast‑track features, especially those built with the Mach dynamic framework or React Native (MRN). Pure dynamic requests can be shipped within a week, while combined dynamic‑native features follow the bi‑weekly cadence.

3.4 Automated Version Management

Automation was introduced to handle the increasing complexity of version events (over 40 manual steps per release). A combination of internal tools (Gulf, QA‑Assistant, Tide) schedules and triggers events such as branch creation, CI jobs, packaging, and notifications, reducing manual effort and errors.

3.5 CI Construction

CI pipelines cover five stages: preparation, PR check, development, test submission, and release. Specific checks include independent compilation configuration, PR merge verification, and automatic packaging of shell projects.

3.6 Deployment and Release

Deployment moves a tested build to a test environment; release moves a stable build to production. The process defines clear responsibilities (RD for deployment, QA for approval) and automates gray‑release and full‑release steps, including unattended gray‑release monitoring.

4. Summary of Continuous Delivery at Waimai

Key principles: continuous automation, early problem solving, versioning of code/data/config, rapid feedback, and ongoing incremental improvement. The article outlines concrete steps for requirement intake, code submission, test deployment, and online monitoring.

5. Outlook

Future work focuses on fine‑grained CI rules and automated testing to reduce manual QA effort while maintaining high release quality.

6. References

Understanding CI, CD, and CD

Differences among CI, CD, and CD

Continuous Delivery 2.0: DevOps Essentials