How does our company achieve efficient parallel testing?

"I need to occupy the test environment joint debugging project at 2-3 pm, please don't publish it!"
When I saw the news in the group, I was distressed for a while. Since the company uses the microservice architecture and deploys it on the Kubernetes cluster, the services developed by the team are part of the entire microservice architecture, and the entire system operates normally. It is necessary to rely on the upstream and downstream services in the microservice system, which leads to the fact that every time the window period for a new version is reached, everyone begins to occupy the test environment to jointly debug and test the functions developed by themselves, resulting in the situation of queuing up to use the test environment.
Today is the release day. I also need to publish my functions to the test environment to verify whether the functions are correct. If someone occupies the test environment, I will not be able to test and repair functions at will. Queuing to use the test environment will affect my release efficiency. I'm going to be complained by the product manager for being slow to go online again :(
"Then I'll schedule it at 3-4 o'clock," another engineer on the team said in the group.
Seeing that the use time of the test environment is constantly being squeezed, I don't care if it really takes an hour, so I quickly shouted in the group "I expect to open the PR merge code at 5 o'clock, so I have to test it at 4-5 o'clock, I'll let you know when it's ready."

Presumably everyone who uses the microservice architecture has the same trouble as me, that is, "integration test joint debugging is really annoying!", especially when the new version is released, the test environment is like an Internet celebrity restaurant. There is a long queue, and every function has to be tested, so you can only wait obediently. Like my company, many companies only have one set of test environments, and each project has a tight schedule before the release, so they are all crowded together. Especially now that the iteration cycle of agile development is getting shorter and shorter, and testing is becoming more and more frequent, the testing environment is really not enough.

So I went looking for a solution to this problem, and found that there are some toolchains that can solve this time-consuming queueing problem, such as TeamCode new microservice integration test tool KubeOrbit , which helps teams efficiently test microservices. Serve.

I opened the product documentation he sent me and found that this tool allows me to define a benchmark environment in the Kubernetes cluster of the company's test environment:

$ kubectl label deployment your-deployment version=base

I can also create different test channels based on the benchmark environment, such as test environment 1 and test environment 2:

# Create a test env with name v1
$ kubectl label deployment your-deployment-v1 version=v1
# Create a test env with name v2
$ kubectl label deployment your-deployment-v1 version=v2

Add your own services to the target test environment

apiVersion: network.kubeorbit.io/v1alpha1
kind: ServiceRoute
metadata:
  name: serviceroute-sample
  namespace: sample-namespace
spec:
  name: pod-svc
  # Add your service to the test env named with v1 by defining trafficRoutes
  trafficRoutes:
    routes:
      - name: v1
        labels:
          version: v1
        headers:
          version:
            exact: v1
    default:
      version: base

Deploy to the target test environment

kubectl apply -f /path/to/your/serviceroute.yaml

Summary of use experience

The KubeOrbit tool mainly has the following three functions: create a test channel in the microservice test environment, so that a separate and stable integration test environment can be obtained; add the microservices that need to be tested to the test channel, and compare them with other versions of Microservices are isolated; specify a test channel when initiating a microservice request, and KubeOrbit will forward it to the test channel you specify. These functions just solve the dilemma of me and the team's time-consuming queuing test, and meet the needs of team testing:

1. For the needs of parallel development and joint debugging and testing within the team, everyone no longer needs to compete for the use of the test environment
2. The need to deliver the project on time avoids project delays due to insufficient test environments

We do not need to adjust the existing technology stack and architecture, KubeOrbit will adapt to the existing microservices, and can also isolate the communication between different test channels. However, in the process of using the product, I found that more manual operations are required, which increases the threshold for using this tool. If these processes can be automated, the user experience will be greatly improved. I just learned from the that the products are all open source on 161ee86bfbd566 GitHub . I also plan to study it carefully, continue to pay attention to this project and platform, and hope to have a better experience in the future.