How do my company implement integration tests efficiently?

"I have to use the test environment for a interation test project at 2-3 pm, please don't publish during that time!" I was in a panic after I saw this message. Since the company uses microservice architecture and deploys it on the Kubernetes cluster, the service that the team is responsible for is part of the entire microservice architecture. The operation of the entire system depends on the upstream and downstream services in the microservice system. Every time when a new versions is released, everyone starts to occupy the test environment and test the functions developed by themselves, which leads to the situation of queuing to use the test environment.

Today is the release date of my product's new version. I also have to publish my projects to the test environment to verify its functions. Queuing to use the test environment will affect my release efficiency. I was overwhelmed with dysphoria.

My test arranged at 3-4 PM, another engineer sent. The available time of the test environment is constantly being squeezed. I was anxious and hurriedly shouted in the group chat "I expect to merge the PR code at 5 o’clock, so I will test it at 4-5 o’clock. Everyone will be notified when it is finished."

While waiting for the test, I complained to my engineer friend Henry about this problem. He told me that there are actually some tool chains that can solve this time-consuming queuing problem, such as TeamCode's new product KubeOrbit: an integration testing tool for microservices. It can help the team deploy multiple test environments efficiently in the Kubernetes cluster for testing.

I opened the product documentation he sent 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

Then I can create different test environments 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

Update the code and deploy to the target test environment
kubectl apply -f /path/to/your/serviceroute.yaml

Summary from my usage experience
KubeOrbit tools have the following three main functions: create a test channel in the microservice test environment, so that you can get a separate and stable integrated test environment; add the microservices that need to be tested to the test channel, and isolate them from other different versions of Microservices; when a microservice request is initiated and a test channel is specified, KubeOrbit will forward it to the specified test channel. These features just solved the time-consuming queuing issues for my team satisfy our needs below:

1. The needs of parallel development and Interation Test within the team, we don't have to compete for the use of the test environment
2. The need to deliver the project on time, avoiding project delays due to insufficient testing environment

The team does not need to adjust the existing technology stack and architecture, KubeOrbit will adapt your microservices and can also isolate the communication between different test channels. But during the product, I found that many manual operations are required. And I just got the notification from its official facebook page that the product is open source on GitHub (https://github.com/teamcode-inc/kubeorbit). I will follow up this product and if these manual operation processes can be automated, the user experience will be greatly improved.

Comments

[anandsunderraman]

This is an interesting article.
I closely worked to build the integration tests in my team.
For the integration tests we were lucky to be able to spin up a temporary as part of the pipeline, run our tests and then bring it down.

[TrystanCocolatte]

Thank you! Maybe you can have a try on KubeOrbit, see if it works for your team;)