Building an application is no less than painting a masterpiece. Every line of code is like a stroke that completes the painting. However, building the application without testing is like painting in the dark. Nobody knows the outcome. Using traditional testing tools to find bugs is like using flashlights in the dark. They do the job but are inefficient.

This is where continuous testing comes in and makes testing a part of your DevOps cycle - TestOps, as we call it. In this blog post, we’ll explore how Testkube and GitLab can help implement TestOps, ensuring your code evolves into a masterpiece. 

TestKube and GitLab For TestOps

GitLab is a popular platform that enables end-to-end DevOps lifecycle management. It provides version management capabilities through Git repositories and helps development, operations, and security teams collaborate. Many organizations rely on GitLab to orchestrate their development workflows.

Testkube, on the other hand, is a testing platform designed for Kubernetes that integrates well with all the popular CI/CD tools, including GitHub Actions and Jenkins, to name a few. It also allows you to plug your existing testing tools and make them Kubernetes. 

Testkube and GitLab help you implement TestOps and enable continuous testing as part of your application development lifecycle. Below are some benefits of using Testkube with GitLab:

• Unified Testing Ecosystem: Testkube seamlessly integrates with GitLab, providing a unified testing framework. Automating tests and reducing manual intervention creates a streamlined and efficient TestOps workflow. 

• Continuous Testing: The integration of Testkube with GitLab enables continuous testing throughout your development lifecycle. Every code change triggers test execution, which ensures every change is validated and bugs are identified earlier.

• Test Observability: With Testkube integrated with GitLab, you have improved visibility into your tests. From your tests to application logs, Testkube provides detailed logs and artefacts throughout your testing process, giving you better insights.

Integrating Testkube With GitLab

Integrating Testkube with any CI/CD tool aims to enhance your testing process. In this section, we’ll see how to integrate Testkube with GitLab. Below is a high-level overview of the use case:

• We will create a repository with a sample k6 test to perform a website load test. 
• We’ll also configure a Gitlab CI pipeline job, which will be triggered on every new merge request. 
• The job will create a k6 test on Testkube that is configured on a cluster. 
• Lastly, we’ll configure a branch protection rule that will not allow a change to be merged if the test fails.

With this high-level overview, let’s see how it works.

The code for this integration is available in this repo. The repo contains a directory named k6,  which contains the test. The `.gitlab-ci.yml` file contains the code for the automated job. 

Pre-requisites

• GitLab account & repository with GitLab pipeline configured.
• Kubernetes cluster - we’re using an EKS cluster.
• Testkube Agent configured on the cluster.
• Testkube API token, Org ID, and Environment ID

Once the prerequisites are in place, you should have a target Kubernetes cluster ready with a Testkube agent configured. You should also have a GitLab repository configured with the test files and the GitLab CI pipeline.

Note: Refer to our API Token document to create the API token. To find the Org ID and environment IDs, log in to your Teskube Cloud dashboard, head to any existing tests page, navigate to CI/CD integration, and choose GitLab. Copy the environment and organization IDs from here. 

‍

‍

Pro Tip: You can also use this sample workflow generated by Testkube to create and configure your CI pipeline.

You’ll also need to create variables in GitLab to store these IDs and the token. 

K6 Test

We will create a k6 test that performs a load test on the testkube.io website and checks if the response time is less than 1000 milliseconds. If the response is more than that, the test will fail.

‍

```js

import http from 'k6/http';
import { check, sleep } from 'k6';
‍
export let options = {
  vus: 1, // Virtual Users
  duration: '10s', // Duration of the test
};
‍
export default function () {
  // Send an HTTP GET request to the website
  let response = http.get('https://testkube.io'); // Replace with your URL
‍
  // Check if the response time is less than 1000 milliseconds
 check(response, {
    'Response time is less than 1000 milliseconds': (r) => r.timings.duration < 1000, // Check if response time is less than 1000 milliseconds
  });
‍
  // Add a sleep period (in this case, 1 second) between requests
  sleep(1);
}

``` 

Configuring CI Pipeline Job

We configure the CI pipeline job to execute whenever a new merge request is made. The job uses the Testkube API key, ORG_ID, and ENV_ID which are saved at GitLab variables.

‍

```yaml

stages:
  - setup
‍
setup-testkube:
  stage: setup
  image: 
    name: kubeshop/testkube-cli
    entrypoint: ["/bin/sh", "-c"]
  script:
    - testkube set context --api-key $TESTKUBE_API_KEY --org $TESTKUBE_ORG_ID --env $TESTKUBE_ENV_ID
    - testkube create test --name k6-kubeshop-test --type k6/script --update --test-content-type git-file --git-uri https://gitlab.com/techmaharaj/testkube-GL.git --git-branch main --git-path k6/testkube.js
    - testkube run test k6-kubeshop-test -f

```

The above workflow does the following things:

• Configures the CI job to connect with Testkube cloud using the Testkube token, organization, and environment ID.
• Creates and executes the k6 test using `kubeshop/testkube-cli` on the EKS cluster.
• Based on the result, the status will be updated in the MR. If the test passes, the merge option will be enabled, and anyone can merge it. However, if the test fails, the merge will not be available - we’ll configure an auto-merge protection rule to prevent the PR from being merged if the run fails.

Trigger Testkube Test

To check if everything works correctly, raise a new MR in the repository with some changes. You’ll see that your action is triggered almost immediately.

In the background, our test will run on the target Kubernetes cluster specified. If the test passes, our CI job will update the status in the PR, and a user can merge the PR.

However, if the test fails, the CI job will update the workflow status as failed in the PR. You can see that merging is blocked because of the branch protection rule that we have created, which prevents merging if the test fails.

With this example, we have seen how easy it is to configure Testkube with GitLab. One can perform advanced scenarios by tweaking the workflow and configuring your repositories based on your requirements.

Summary

We looked at the importance of continuous testing and how it enhances our testing. Additionally, we delved into the seamless integration of Testkube with GitLab, a widely used tool for setting up CI/CD workflows. Demonstrating the process, we established a straightforward workflow, successfully incorporating a k6 test using Testkube.

Refer to our documentation for more insights into leveraging Testkube for your CI/CD requirements. Take a proactive step towards implementing TestOps and try Testkube today. Watch this webinar to learn more about how Testkube is suited for TestOps.

Experience the versatility of test types within Testkube, discovering firsthand how its Kubernetes-native capabilities simplify and fortify your testing procedures. For further guidance and assistance, become a part of our Discord community.