Baidu's Traditional Application Operations and Branch Management Process

Continuing from the previous discussion on developers over‑estimating their abilities, this article outlines Baidu's traditional application operations and branch management practices.

1. Baidu Project Branch Management Method

In 2012 Baidu primarily used a branch development, mainline release configuration management model. The mainline contains released code, while ongoing development resides in project branches. After a project is created in iCafe and receives a three‑digit version number, a branch is cut from the latest mainline for development. If a project has multiple modules, each module gets its own branch. After development, the code enters an integration testing phase managed by developers, with testers only defining requirements and cases. Once integration testing is complete, a four‑digit version is generated and submitted for testing via iCafe. Testers then verify the build; any defects trigger a new four‑digit version and retesting. This cycle repeats until no issues remain, after which the code is queued for merging into the mainline, merged when the queue is clear, and finally deployed with documentation handed over to operations.

2. Why Is There a Mainline Queue?

Baibu's release policy permits deployments only twice a week (Tuesday and Thursday), and only one fully tested project can be merged per release unless projects are completely unrelated. Because multiple projects often finish simultaneously, a queue forms. Projects may need to sync the latest mainline code before their own release, and dependencies or architectural changes can enforce a strict order, further contributing to the queue.

At the time of writing, 14 projects were waiting for release, which, assuming no new projects and flawless deployments, would take seven weeks to clear.

3. Phase Summary

The team’s improvements include:

Clear business objectives for each project.

Clear improvement goals.

Transparent development plans.

A self‑defined, self‑adhered process ensuring high‑quality delivery.

Periodic proactive retrospectives rather than event‑driven reviews.

Story‑driven development instead of task‑oriented assignments.

A six‑step continuous integration submission method.

Appropriate use of automated testing to boost efficiency.

Stay tuned for the next stage summary of the "Continuous Delivery Summer Journey."