Knowledgebase

How to integrate Azure DevOps/Pipelines with Load Impact/k6


Purpose

The intent of this guide is to walk you through the steps of triggering tests as part of your Azure Pipelines within Azure DevOps. Before you get started go to https://dev.azure.com/ and click Start Free or login with your existing Microsoft account.

After a successful login, follow the instructions below.

Run k6 using Azure Pipelines from your GitHub project

Create a new project (or use an existing one)

Click on New Pipeline button.

For this example, we will use GitHub as the repository for our code. If your code is elsewhere, the next few steps will vary for you.

You will need to have a project on GitHub for this exercise. Either create a new one or choose one of your existing ones. Click the Authorize button to connect your repo to Azure Pipelines.

If you are a member of multiple organizations select the organization that contains your project.

Choose to install Azure Pipelines into all repositories or just into a single repository

Once you finish giving Azure Pipelines access to your project, you can begin configuring your your integration.

Azure Pipelines config

Create a new file in the root of your repo named azure-pipelines.yml.

Azure provides us with ready-made pools to run our pipeline agents in. Having a choice between a Windows, MacOS and Ubuntu agent I’ve selected Ubuntu 16.04. That gives us the easiest way to install k6 tool through shell commands.

We can start our example by defining the base image for our agent:

azure-pipelines.yml

1
2
pool:
  vmImage: 'Ubuntu 16.04'

Commit this new file and push the code to remote. On each push, a build is automatically triggered.

Installing k6

For now, our build does nothing useful. Let’s change that. We are going to create our first script task within our pipeline step. On it’s GitHub page, k6 provides us with clear instructions how to install k6 on a Debian based system so we can copy that verbatim as a multiline script with a descriptive displayName attribute.

To make sure that k6 is installed properly we can add a new script task that just outputs version of our k6 install. This task is optional and can be removed in real-life scenarios.

For this example, we are using a single-job build so the jobs section is omitted.

At this point, we have the following:

azure-pipelines.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
pool:
  vmImage: 'Ubuntu 16.04'

steps:
- script: |
    sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 379CE192D401AB61
    echo "deb https://dl.bintray.com/loadimpact/deb stable main" | sudo tee -a /etc/apt/sources.list
    sudo apt-get update
    sudo apt-get install k6
  displayName: Install k6 tool

  - script: |
    k6 version
  displayName: Check if k6 is installed

Commit and push the code. Go to Pipeline’s web UI and check the output for the steps. You should see something similar to the following:

k6 run

We have k6 installed in our agent so it’s time to run a proper load test. k6 uses JavaScript as it’s scripting language making it very flexible to write any kind of load testing scenario.

In this example, we will be testing a single webpage. We are ramping up for 10s from 1 to 15 virtual users, stay at that number of virtual users for 20 seconds, and then ramp the test down to 0 virtual users. The duration of your test and number of virtual users used will depend on your needs.

We have named this test local.js since it is being run locally straight from Azure Pipelines agent. Local execution is helpful for script validation or even testing behind the firewall. Note: Locally executed tests can stream results into Load Impact’s cloud service for analysis. You are able to do this by setting the flag -o cloud

Since we are planning to have multiple test scenarios, create a separate directory loadtest in the root of the repo and place local.js file within it.

loadtests/local.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
import { check, group, sleep } from "k6";
import http from "k6/http";

export let options = {
    stages: [
        { duration: "10s", target: 15 },
        { duration: "20s", target: 15 },
        { duration: "10s", target: 0 }
    ],
    thresholds: {
        "http_req_duration": ["p(95)<250"]
    },
    ext: {
        loadimpact: {
            name: "test.loadimpact.com"
        }
    }
};

export default function() {
    group("Front page", function() {
        let res = http.get("http://test.loadimpact.com/");
        check(res, {
            "is status 200": (r) => r.status === 200
        });
        sleep(5);
    });
}

In azure-pipelines.yml config file we add a new script task to run k6 load test directly from Azure Pipelines agent:

1
2
3
4
5
steps:
# ...
- script: |
    k6 run loadtests/local.js
  displayName: Run k6 load test within Azure Pipelines

Once again: commit and push.

If you see the above screen, congrats! You now know how to set up a GitHub project CI build to run on Azure Pipelines and use Load Impact for load testing!

k6 cloud run

k6 can also be used to execute tests directly on the Load Impact’s cloud service. This enables you to geographically distribute the origin of your load and not worry about maintaining any load generators.

Our test script is nearly identical to the one presented above, with a small change to our options section. We have now defined to run our load test from two datacenters (Ashburn and Dublin). For a list of all available Load Zones from which a load test can be run refer to this article.

Let’s create a new file in our loadtests dir named cloud.js.

loadtests/cloud.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import { check, group, sleep } from "k6";
import http from "k6/http";

export let options = {
    stages: [
        { duration: "10s", target: 15 },
        { duration: "20s", target: 15 },
        { duration: "10s", target: 0 }
    ],
    thresholds: {
        "http_req_duration": ["p(95)<250"]
    },
    ext: {
        loadimpact: {
            name: "test.loadimpact.com",
            distribution: {
                loadZoneLabel1: { loadZone: "amazon:us:ashburn", percent: 60 },
                loadZoneLabel2: { loadZone: "amazon:ie:dublin", percent: 40 }
              }
        }
    }
};

export default function() {
    group("Front page", function() {
        let res = http.get("http://test.loadimpact.com/");
        check(res, {
            "is status 200": (r) => r.status === 200
        });
        sleep(5);
    });
}

In azure-pipelines.yml config file add an additional step or modify your existing step that was running k6 locally.

1
2
3
4
5
6
steps:
# ...
- script: |
    k6 login cloud --token $(k6cloud.token)
    k6 cloud --quiet loadtests/cloud.js
  displayName: Run k6 cloud load test within Azure Pipelines

Important Note: Notice the usage of token provided from Load Impact. You will need to get this before you commit your code. First, we need to get the Load Impact token and set Azure Pipelines secret variable.

You can obtain your token from your account at loadimpact.com. Go over to Integrations section of the page and click Use your token link. Copy the provided token.

Now we need to add an Azure Pipelines variable that will be available within the build.

Go to Azure Pipelines web UI and from the left side menu select Pipelines and then click the Edit button next to the name of your project.

Once you enter the options for your project switch to Variables tab within the web UI and enter a new secret variable that will be used during k6 cloud execution.

Click Add to add a new variable. Under name enter k6cloud.token and for its value paste Load Impact’s token. Don’t forget to set the variable as secret so that it’s not visible as plain text in your pipelines output.

After entering the values click Save & queue button above and into field Save comment enter adding k6cloud.token env var.

Now, you can push your new loadtests/cloud.js script alongside new Pipelines script task to trigger a new build. You can see some basic output from k6 in Azure Pipelines web UI, but for a more in-depth view and analysis of your test go to Load Impact’s web UI.

See also/Reference