R&D Management 15 min read

Why Change Requests Outperform Pull/Merge Requests in Modern DevOps

This article compares Alibaba’s change request workflow with traditional Pull/Merge Request models, outlining their similarities, key differences, benefits such as flexibility and faster releases, as well as associated risks, and explains how the method is implemented and supported by tools like Cloud Eff.

Programmer DD
Programmer DD
Programmer DD
Why Change Requests Outperform Pull/Merge Requests in Modern DevOps

Typical Software Integration Release Model

In most modern software projects, feature branches are managed through Pull Requests (GitHub) or Merge Requests (GitLab). After code review approves a branch, it is merged into an integration branch and then passes through a continuous delivery pipeline until production.

Alibaba’s Change Request Workflow

Within Alibaba, developers often use a “Change Request” (full name Change Request) object to manage feature branches instead of the standard PR/MR flow. A change request represents a feature branch and is tracked until release.

Similarities

A change request, like a Pull/Merge Request, corresponds to a feature branch.

Code changes in a change request can be reviewed just as in a PR/MR.

Continuous‑integration builds and checks are triggered automatically and can be displayed in the change request.

Test environments can be provisioned for the latest code of a change request, similar to PR/MR.

Approval rules (e.g., minimum reviewers, passing CI) can be configured for change requests just as for PR/MR.

Differences and Main Value

The key difference lies in how a feature branch is integrated and delivered together with other branches. With PR/MR, once a branch is merged into the integration branch, it loses its individual granularity and proceeds through the release stages as part of a larger batch. Change requests retain a degree of independence even after integration, allowing them to be withdrawn or modified mid‑process.

Examples

Example 1: Five changes (A‑E) pass daily integration testing. During pre‑release testing, change C reveals a defect. Because C is independent, it is removed from the pre‑release batch, allowing the remaining four changes to continue to production without re‑running daily integration tests.

Example 2: After daily integration, the five changes reach pre‑release. Market feedback requires a minor wording tweak in change C. The tweak is made directly on C’s feature branch, the updated change is retested with the other four changes, and all are released together.

Additional Benefits

Change management provides clear traceability: each change can be linked to requirements, tasks, or defects, making it easy to see what features are included in a test or release. Because all modifications for a change stay within its branch, developers can view and operate on them as a unit, and the change’s status (development, testing, released) is automatically trackable, enabling real‑time board updates.

Risks and Weaknesses

The flexibility introduced by change requests breaks the traditional “single integrated version moves sequentially through stages” model, increasing risk of misuse. Teams must assess inter‑change dependencies, code size, architectural quality, and urgency to decide when it is safe to withdraw or modify a change mid‑pipeline.

Smaller code changes reduce withdrawal risk.

Fewer modifications to a change lower risk.

Better architecture mitigates risk of mid‑process changes.

Low coupling between changes reduces risk.

Higher urgency may justify flexible handling.

High quality‑requirement contexts should avoid excessive flexibility.

Implementation and Tool Support

Alibaba’s implementation relies on a branch strategy where master always points to the latest released version. Feature branches are created from master, and short‑lived integration branches are automatically generated for each release stage, merging the relevant feature branches. If a feature needs further work, it is updated on its branch and merged again.

master represents the latest released version.

All code changes happen on feature branches derived from master.

No long‑living integration branch; each release stage has a temporary integration branch.

Developers are responsible for tracking and advancing their own changes through the stages.

This approach demands sophisticated tooling to manage branch creation, merging, and conflict resolution, which Alibaba provides through its internal platform Aone and the public cloud service Cloud Eff.

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.

DevOpschange managementcontinuous integrationrelease process
Programmer DD
Written by

Programmer DD

A tinkering programmer and author of "Spring Cloud Microservices in Action"

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.