"I have to use the test environment for an integration 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 a new version 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 their functions. Queuing to use the test environment will affect my release efficiency. I was overwhelmed with dysphoria. My test was arranged for 3-4 PM. 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 talked 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 integration tests 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. I will follow up on this product and if these manual operation processes can be automated, the user experience will be greatly improved.

My Experience with Integration Testing

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Application Scenarios of Pylon CLI — A Client Tool that Controls the Dev Environment Locally

10 Strategic Technology Trends Businesses Should Plan for in 2021

The Noonification: Craig Wright is Satoshi Nakamoto (12/17/2023)

300 Scholarships Up For Grabs at The School of Cloud Computing Courtesy Udacity and SUSE

4 Best Cloud Deployment models

Application Scenarios of Pylon CLI — A Client Tool that Controls the Dev Environment Locally

10 Strategic Technology Trends Businesses Should Plan for in 2021

The Noonification: Craig Wright is Satoshi Nakamoto (12/17/2023)

300 Scholarships Up For Grabs at The School of Cloud Computing Courtesy Udacity and SUSE

4 Best Cloud Deployment models

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps