Hands-on demo – Identify performance regressions with Azure Load Testing and GitHub Actions

Hands-on demo – Identify performance regressions with Azure Load Testing and GitHub Actions

To identify performance regressions with Azure Load Testing and GitHub Actions, you can integrate load testing into your CI/CD pipeline. This ensures performance metrics are evaluated with every change in code, helping catch regressions early.

Here goes a step-by-step guide to setup the performance regression testing in Azure Load Testing and GitHub Actions.

1. Prerequisites

1. Azure Load Testing resource in your Azure subscription.

2. JMeter script (.jmx) for your load test.

3. GitHub repository integrated with your application.

4. Azure service principal with required permissions to interact with the Azure Load Testing resource.

2. Create an Azure Load Testing Resource

1. In the Azure Portal, navigate to Create a Resource > Load Testing.

2. Configure the resource and note the resource's details:

   • Resource Name

   • Resource Group

   • Region

3. Prepare Your JMeter Script

1. The script should define the test scenarios, such as endpoint requests, user load, and response time thresholds.

2. Example of a simple JMeter test plan:

xxxxxxxxxx
10
1
<ThreadGroup>
2
    <num_threads>10</num_threads>
3
    <ramp_time>30</ramp_time>
4
    <loop_count>1</loop_count>
5
    <HTTPSamplerProxy>
6
        <HTTPSamplerDomain>example.com</HTTPSamplerDomain>
7
        <HTTPSamplerPath>/api/endpoint</HTTPSamplerPath>
8
        <HTTPSamplerMethod>GET</HTTPSamplerMethod>
9
    </HTTPSamplerProxy>
10
</ThreadGroup>

Save this as load-test.jmx.

4. Set Up GitHub Actions for Azure Load Testing

4.1 Add Azure Service Principal Credentials

1. In your GitHub repository, go to Settings > Secrets and Variables > Actions.

2. Add the following secrets:

   • AZURE_CLIENT_ID (Service principal’s app ID)

   • AZURE_TENANT_ID (Azure AD tenant ID)

   • AZURE_CLIENT_SECRET (Service principal password)

   • AZURE_SUBSCRIPTION_ID (Subscription ID)

   • LOAD_TEST_RESOURCE (Name of your Azure Load Testing resource)

   • LOAD_TEST_RESOURCE_GROUP (Resource group name)

4.2 Create a GitHub Actions Workflow

Add a .github/workflows/load-testing.yml file in your repository.

xxxxxxxxxx
39
1
name: Azure Load Testing
2
on:
3
  push:
4
    branches:
5
      - main
6
  pull_request:
7
jobs:
8
  load-test:
9
    runs-on: ubuntu-latest
10
    steps:
11
   - name: Checkout Code
12
      uses: actions/checkout@v3
13
   - name: Login to Azure
14
      uses: azure/login@v1
15
      with:
16
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
17
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
18
        client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
19
   - name: Upload JMeter Script to Azure Load Testing
20
      run: |
21
        az load test upload-file \
22
          --resource-group ${{ secrets.LOAD_TEST_RESOURCE_GROUP }} \
23
          --resource-name ${{ secrets.LOAD_TEST_RESOURCE }} \
24
          --file-path ./load-test.jmx \
25
          --file-name load-test.jmx
26
   - name: Run Load Test
27
      run: |
28
        az load test run \
29
          --resource-group ${{ secrets.LOAD_TEST_RESOURCE_GROUP }} \
30
          --resource-name ${{ secrets.LOAD_TEST_RESOURCE }} \
31
          --test-id my-test \
32
          --test-name "GitHub Actions Load Test"
33
   - name: Check Test Results
34
      run: |
35
        results=$(az load test-run show \
36
          --resource-group ${{ secrets.LOAD_TEST_RESOURCE_GROUP }} \
37
          --resource-name ${{ secrets.LOAD_TEST_RESOURCE }} \
38
          --test-run-id my-test)
39
        echo $results

5. Workflow Details

1. Login to Azure: Authenticates using the service principal.

2. Upload JMeter Script: Uploads the load test definition (.jmx) to Azure Load Testing.

3. Run the Test: Executes the test using the az load test run command.

4. Check Results: Retrieves and prints the results of the load test.

6. Analyze Results for Performance Regressions

1. Use the Azure CLI or Azure Portal to view the results:

   • Response Time: Ensure response times meet your thresholds.

   • Error Rates: Check for increases in HTTP errors.

   • Throughput: Validate sustained request processing rates.

2. Set performance thresholds in your pipeline: Example: Fail the pipeline if the average response time exceeds 500ms or if the error rate is above 1%.

7. Example: Conditional Pass/Fail Based on Results

Add a step to analyze results and fail the workflow if thresholds are breached.

xxxxxxxxxx
11
1
- name: Validate Test Results
2
   run: |
3
      results=$(az load test-run show \
4
         --resource-group ${{ secrets.LOAD_TEST_RESOURCE_GROUP }} \
5
         --resource-name ${{ secrets.LOAD_TEST_RESOURCE }} \
6
         --test-run-id my-test)
7
      avgResponseTime=$(echo $results | jq '.metrics.avgResponseTime')
8
      if [ "$avgResponseTime" -gt 500 ]; then
9
         echo "Average response time exceeded threshold. Failing workflow."
10
         exit 1
11
      fi

8. Monitor and Improve

1. Use Azure Monitor Logs and Application Insights for detailed telemetry.

2. Set up alerts for SLA breaches.

3. Continuously improve your application based on findings.

Summary

This integration ensures that performance regressions are detected automatically, helping maintain application quality and reliability. Feel free to write in comments and let me know if you need further help with specific steps.