Full-Link Multi-Version Deployment in Testing Environments: Architecture and Practices

This article introduces a full‑link multi‑version deployment solution for testing environments, aiming to solve resource contention and inefficiencies in traditional test setups.

Background : In microservice architectures, a business system consists of many independently deployed services, leading to complex deployment and testing processes. Traditional test environments require full deployment of all services for each version, consuming significant hardware resources and causing delays when urgent hot‑fixes need to be tested.

Full‑Link Deployment refers to deploying all services of the system in a single environment at once, simplifying release workflows and ensuring service coordination.

Multi‑Version Deployment builds on the concept of gray‑release, allowing different versions of services to run concurrently in the same environment, enabling parallel testing of feature branches and hot‑fixes.

The solution evolves Vivo’s CI/CD platform to support container‑based pipelines, middleware integration, and call‑chain tracing, providing a flexible multi‑service orchestration capability.

Technical Architecture : The architecture distinguishes a baseline environment (full service deployment) from feature environments (only required services are started). Requests carry a custom header tc_fd indicating the target environment; routing rules in HTTP gateways, Dubbo, and MQ forward traffic accordingly.

Traffic Coloring methods include:

Client‑side HTTP: use proxy tools (e.g., Charles, ModHeader) to inject tc_fd header.

Server‑side HTTP: gateway rewrites request headers.

Dubbo: set tag via RpcContext.getContext().setAttachment("Dubbo.tag","流量标识") or JVM argument -Dvivotag=流量标识 .

Distributed tasks: schedule tasks with environment tags.

Traffic Isolation is achieved through:

HTTP isolation using VUA (vivo unity access) gateway with traffic‑split plugin.

Dubbo isolation via dynamic tag‑based routing rules.

MQ isolation by attaching environment tags to message properties and using proxy components to filter messages.

Tag Propagation ensures that once a request is colored, the environment tag is passed along the call chain (HTTP headers, Dubbo attachments, MQ message properties) using a distributed tracing system that injects and extracts the tag without modifying business code.

Environment Management covers baseline and feature environments. Baseline environments are shared and must remain stable; feature environments are created on‑demand with unique tags, support rapid provisioning, automated routing configuration, and timed destruction to avoid resource waste.

Link Monitoring integrates a distributed tracing system to visualize service interactions, locate issues via trace IDs, and display environment tags on topology graphs.

Future Outlook includes extending support to more middleware and programming languages, implementing data‑level isolation (e.g., separate MySQL/Redis instances), and applying the multi‑version pipeline to production scenarios such as A/B testing.