Step‑by‑Step Guide to Gray Release with Alibaba Cloud MSE and Cloud‑Native Pipelines

Purpose

During a release, routing a limited, well‑defined slice of traffic to a new version (gray release) enables early verification of functionality while keeping the overall system stable.

Gray Release Strategies

Allocate a small percentage of live traffic directly to the new version.

Select traffic by specific request attributes such as HTTP headers or cookies.

Mark traffic on the client side (e.g., custom header) so that only marked requests are sent to the gray version.

Deploy Application and Create Virtual Lanes

Deploy the alibabacloud‑microservice‑demo to a Kubernetes cluster. After deployment, distinguish between baseline and gray traffic by creating a lane group that contains the entry service and all downstream services. Then create a lane named gray with routing rules that match the chosen traffic slice. Traffic that does not satisfy any rule is automatically routed to the baseline environment (unlabeled pods).

Reference deployment documentation: https://github.com/aliyun/alibabacloud-microservice-demo/blob/master/mse-simple-demo/helm/mse-simple-demo/README.md

Note: Unmatched traffic falls back to the baseline environment.

Configure Cloud‑Effect (DevOps) Pipeline

Pipeline Source

Code repository:

https://gitee.com/mse-group/alibabacloud-microservice-demo.git

(public repository to avoid network latency).

Default branch: master.

Service connection: default settings are sufficient for a public repo.

Build Stage Configuration

Create a task named Image Build to build a Docker image.

Build cluster: select the nearest build cluster (e.g., “Beijing Build Cluster”).

Service connection: add an ACR service connection using RAM authorization.

Target image repository: choose the appropriate ACR repository.

Tag: use the default variable ${DATETIME}.

Dockerfile path: mse-simple-demo/A/Dockerfile.

Gray Deployment Stage

Cluster connection: authorize Cloud‑Effect to modify the ACK workload.

Kubectl version: select a compatible version.

Namespace: choose the namespace used for the demo.

Workload type: Deployment.

Workload name: spring-cloud-a-gray.

Container name: spring-cloud-a-gray.

Image: use the image built in the previous stage (public image address).

Production Deployment Stage

Workload name: spring-cloud-a (baseline environment).

Container name: spring-cloud-a.

Set both the gray and production stages to “manual trigger” to allow verification before full rollout.

Pipeline Execution

Run the Image Build task and confirm successful image creation in the build logs.

Manually trigger the gray deployment; verify in the Kubernetes console that the spring-cloud-a-gray deployment uses the newly built image.

Send a test request that includes the gray‑routing parameter, e.g. GET /?name=xiaoming. The request should be routed to the gray lane.

Confirm that requests without the parameter continue to reach the baseline deployment spring-cloud-a.

After successful verification, manually trigger the production deployment and verify that the new image is running in the baseline workload.

Verification Results

The gray workload receives only traffic that matches the routing rule (e.g., the name=xiaoming query). The new code is active on those pods, while all other traffic remains on the previous version. Once the production stage is triggered, all traffic is switched to the new version.

Conclusion

Using MSE’s full‑link gray release with virtual lanes provides a concrete, low‑risk method for testing new microservice versions. The Cloud‑Effect pipeline automates image building, gray deployment, and final production rollout, enabling rapid verification and reducing the chance of service disruption.