Self-Test Joint Debugging Environment

# Introduction

The self-test mode is a developer-oriented feature module introduced by Zadig to reduce environment management complexity and deployment costs. When the self-test mode is enabled for an environment, it becomes the baseline environment. Developers can quickly replicate their own self-test environment (i.e., sub-environment) based on the baseline environment, focusing only on services related to their daily changes. They do not need to worry about upstream and downstream services, as the baseline environment will provide the necessary capabilities, enabling quick self-testing and joint debugging.

# Application Scenarios

Zadig's self-test mode supports the rapid creation of sub-environments that include only some services at a lower cost. Developers can develop and change target services in the sub-environment and interact with the baseline environment, which includes all services, to achieve self-testing and joint debugging. The issues that enterprises can address using the self-test mode include but are not limited to:

1. Frequent Development: Strong demand for business verification, necessitating rapid iteration of business processes, but lacking the necessary engineering infrastructure
2. Large Number of Microservices: High business complexity, leading to high costs and significant effort in building a complete environment
3. Technical Architecture Limitations: Some microservices, due to basic technical architecture or other reasons, cannot be fully replicated into multiple complete environments, resulting in multiple teams being bound to a single environment, making it difficult to ensure environmental stability

# How to Use

The following example uses simple-service(opens new window) to illustrate how to use the self-test mode of the environment to achieve daily joint debugging.

# Project Background

• The project includes three microservices: a, b, and c, with the service call chain: a → b → c
• The dev environment is a complete and stable daily test environment, including all microservices: a, b, and c
• Service A will undergo frequent changes on a daily basis. We aim to conduct thorough self-testing on service A to ensure that its changes can be delivered

# Administrator: Enable Self-Test Mode

In the dev environment, enable the self-test mode. After enabling, the dev environment becomes the baseline environment.

If the sub-environment includes ingress services, you need to configure the Istio gateway for the baseline environment's ingress service. The configured access address should be resolved to the external network access address of the cluster's istio-ingressgateway service, as shown in the figure below.

# Engineer: Daily Self-Test Joint Debugging

# Create a Sub-Environment

In the dev baseline environment, click Create Sub-Environment and select service A to create a sub-environment containing service A, named dev-test-env1:

# Self-Test and Joint Debugging

The following operations need to be performed in a service that is in the same Service Mesh as a/b/c and is injected with istio-proxy. In this example, the shortcut operation for deploying the service is as follows:

# Execute the following command to inject istio label into the default namespace
kubectl label ns default istio-injection=enabled

# Deploy the nginx service in the default namespace
kubectl -n default apply -f nginx.yaml # nginx.yaml can be obtained from the project source code

When requesting service A, add x-env:dev-test-env1 to the request Header to forward the request traffic to the sub-environment dev-test-env1, enabling self-testing and joint debugging between the sub-environment and the dev environment. Log in to the nginx Pod, and the test results are as follows:

1. Without x-env request header: Directly request service A, services a/b/c in the dev environment will process the request, and there is no requested traffic input in the sub-environment.

2. With x-env: dev-test-env1 request header: Access service A, service A in the sub-environment will receive the request and give a response. For the b/c service on the request link, the service in the dev environment will give a normal response.

# Additional Resources

• Based on Ingress Controller Access Zadig self-test environment outside the cluster (best practice)(opens new window)
• Istio + SkyWalking + Spring Boot Practical combat -Zadig self-test mode solves the developer sub-environment(opens new window)