Manually configure your CI/CD workflow for running load tests
Άρθρο
You can automate a load test in Azure Load Testing by creating a CI/CD pipeline. In this article, you learn how to manually configure GitHub Actions, Azure Pipelines, or other CI tools to invoke an existing test in Azure Load Testing. Automate a load test to continuously validate your application performance and stability under load.
To add an existing load test to a CI/CD pipeline:
Configure service authentication to allow the CI tool to connect to your Azure load testing resource.
Add load test input files to your repository, such as the test script and the load test YAML configuration.
Update the CI/CD pipeline definition to invoke Azure Load Testing.
An Azure DevOps organization and project. If you don't have an Azure DevOps organization, you can create one for free. If you need help with getting started with Azure Pipelines, see Create your first pipeline.
A GitHub account. If you don't have a GitHub account, you can create one for free.
A GitHub repository to store the load test input files and create a GitHub Actions workflow. To create one, see Creating a new repository.
Permission to create or modify a CI pipeline.
A source code repository to store the load test input files.
Configure service authentication
To run a load test in your CI/CD workflow, you need to grant permission to the CI/CD workflow to access your load testing resource. Create a service principal for the CI/CD workflow and assign the Load Test Contributor Azure RBAC role.
In Azure Pipelines, you create a service connection in your Azure DevOps project to access resources in your Azure subscription. When you create the service connection, Azure DevOps creates a Microsoft Entra service principal object.
Sign in to your Azure DevOps organization (https://dev.azure.com/<your-organization>), and select your project.
Replace the <your-organization> text placeholder with your project identifier.
Select Project settings > Service connections > + New service connection.
In the New service connection pane, select the Azure Resource Manager, and then select Next.
Select the Service Principal (automatic) authentication method, and then select Next.
Enter the service connection details, and then select Save to create the service connection.
Field
Value
Scope level
Subscription.
Subscription
Select the Azure subscription that hosts your load testing resource.
Resource group
Select the resource group that contains your load testing resource.
Service connection name
Enter a unique name for the service connection.
Grant access permission to all pipelines
Checked.
From the list of service connections, select the one you created earlier, and then select Manage Service Principal.
The Azure portal opens in a separate browser tab and shows the service principal details.
In the Azure portal, copy the Display name value.
You use this value in the next step to grant permissions for running load tests to the service principal.
Grant access to Azure Load Testing
Azure Load Testing uses Azure RBAC to grant permissions for performing specific activities on your load testing resource. To run a load test from your CI/CD pipeline, you grant the Load Test Contributor role to the service principal.
In the Azure portal, go to your Azure Load Testing resource.
Select Access control (IAM) > Add > Add role assignment.
In the Role tab, select Load Test Contributor in the list of job function roles.
In the Members tab, select Select members, and then use the display name you copied previously to search the service principal.
Select the service principal, and then select Select.
In the Review + assign tab, select Review + assign to add the role assignment.
You can now use the service connection in your Azure Pipelines workflow definition to access your Azure load testing resource.
To access your Azure Load Testing resource from the GitHub Actions workflow, you first create a Microsoft Entra service principal. This service principal represents your GitHub Actions workflow in Microsoft Entra ID.
Next, you grant permissions to the service principal to create and run a load test with your Azure Load Testing resource.
Create a service principal
Create a service principal in the Azure subscription and assign the Load Test Contributor role so that your GitHub Actions workflow has access to your Azure load testing resource to run load tests.
Create a service principal and assign the Load Test Contributor role:
Azure CLI
# Get the resource ID for the load testing resource - replace the text place holders.loadtest=$(az resource show -g<resource-group-name>-n<load-testing-resource-name>--resource-type"Microsoft.LoadTestService/loadtests"--query"id"-o tsv)
echo $loadtest# Create a service principal and assign the Load Test Contributor role - the scope is limited to the load testing resource.az ad sp create-for-rbac --name"my-load-test-cicd"--role"Load Test Contributor" \
--scopes$loadtest \
--json-auth
The output is a JSON object that represents the service principal. You use this information to authenticate with Azure in the GitHub Actions workflow.
Έξοδος
Creating 'Load Test Contributor' role assignment under scope
{
"clientId": "00000000-0000-0000-0000-000000000000",
"clientSecret": "00000000-0000-0000-0000-000000000000",
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"tenantId": "00000000-0000-0000-0000-000000000000",
"activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
"resourceManagerEndpointUrl": "https://management.azure.com/",
"activeDirectoryGraphResourceId": "https://graph.windows.net/",
"sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
"galleryEndpointUrl": "https://gallery.azure.com/",
"managementEndpointUrl": "https://management.core.windows.net/"
}
Σημείωση
You might get a --sdk-auth deprecation warning when you run this command. Alternatively, you can use OpenID Connect (OIDC) based authentication for authenticating GitHub with Azure. Learn how to use the Azure login action with OpenID Connect.
Copy the output JSON object to the clipboard.
In the next step, you store the service principal information as a GitHub Actions secret.
Store Azure credentials in GitHub Actions secret
Create a GitHub Actions secret to securely store the service principal information. You use this secret in your workflow definition to connect to authenticate with Azure and access your Azure load testing resource.
Σημείωση
If you're using OpenID Connect to authenticate with Azure, you don't have to pass the service principal object in the Azure login action. Learn how to use the Azure login action with OpenID Connect.
Select New repository secret, enter the secret information, and then select Add secret to create a new secret.
Field
Value
Name
AZURE_CREDENTIALS
Secret
Paste the JSON output from the service principal creation command you copied earlier.
You can now access your Azure subscription and load testing resource from your GitHub Actions workflow by using the stored credentials.
If you're using another CI/CD tool, you use the Azure CLI to interact with your Azure resources. Perform the following steps to authorize the CI tool access to your load testing resource:
Create a Microsoft Entra service principal to connect to your Azure subscription and access your Azure load testing resource.
Grant the service principal permissions to create and run a load test by assigning the Load Test Contributor role.
Store the Azure credentials securely in the CI tool.
Perform the following steps to configure the service authorization for your CI tool:
Create a service principal and assign the Load Test Contributor role:
Replace the <resource-group-name> and <load-testing-resource-name> text placeholders.
Azure CLI
# Get the resource ID for the load testing resource - replace the text place holders.loadtest=$(az resource show -g<resource-group-name>-n<load-testing-resource-name>--resource-type"Microsoft.LoadTestService/loadtests"--query"id"-o tsv)
echo $loadtest# Create a service principal and assign the Load Test Contributor role - the scope is limited to the load testing resource.az ad sp create-for-rbac --name"my-load-test-cicd"--role"Load Test Contributor" \
--scopes$loadtest \
--json-auth
The output is a JSON object that represents the service principal.
Έξοδος
Creating 'Load Test Contributor' role assignment under scope
{
"clientId": "00000000-0000-0000-0000-000000000000",
"clientSecret": "00000000-0000-0000-0000-000000000000",
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"tenantId": "00000000-0000-0000-0000-000000000000",
"activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
"resourceManagerEndpointUrl": "https://management.azure.com/",
"activeDirectoryGraphResourceId": "https://graph.windows.net/",
"sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
"galleryEndpointUrl": "https://gallery.azure.com/",
"managementEndpointUrl": "https://management.core.windows.net/"
}
Copy the clientId, clientSecret, and tenantId values and securely store them as secrets in your CI tool.
You use these values to sign into your Azure subscription with the Azure CLI az login command.
Add load test files in your repository
To run a load test with Azure Load Testing in a CI/CD workflow, you need to add all load test input files in your source control repository.
If you don't have an existing load test, add the following files to your source code repository:
Test plan file. For JMeter-based tests, add a JMeter test script (JMX file). For Locust-based tests, add a Locust test script (.py file). For URL-based tests, add a requests JSON file.
Any input data files that your test plan uses. For example, CSV data files.
If you have an existing load test, you can download the configuration settings and all input files directly from the Azure portal. Perform the following steps to download the input files for an existing load testing in the Azure portal:
In the Azure portal, go to your Azure Load Testing resource.
On the left pane, select Tests to view the list of load tests, and then select your test.
Selecting the ellipsis (...) next to the test run you're working with, and then select Download input file.
The browser downloads a zipped folder that contains the load test input files.
Use any zip tool to extract the input files.
The folder contains the following files:
config.yaml: the load test YAML configuration file. You reference this file in the CI/CD workflow definition.
.jmx or .py: The JMeter or Locust test script
Any additional input files, such as CSV files or user properties files that are needed to run the load test.
Commit all extracted input files to your source control repository.
Use the source code repository in which you configure the CI/CD pipeline.
Update the CI/CD workflow definition
Azure Load Testing supports both GitHub Actions and Azure Pipelines for running load tests.
Select your Azure DevOps organization, and then select Install to install the extension.
If you don't have administrator privileges for the selected Azure DevOps organization, select Request to request an administrator to install the extension.
Update the Azure Pipelines workflow
Update your Azure Pipelines workflow to run a load test for your Azure load testing resource.
Sign in to your Azure DevOps organization (https://dev.azure.com/<your-organization>), and select your project.
Select Pipelines in the left navigation, select your pipeline, and then select Edit to edit your workflow definition.
Alternately, select Create Pipeline to create a new pipeline in Azure Pipelines.
Use the AzureLoadTest task to run the load test.
Specify the load test configuration file you exported earlier in the loadTestConfigFile property.
Replace the <load-testing-resource> and <load-testing-resource-group> text placeholders with the name of your Azure load testing resource and the resource group.
Use the azure/load-testing action to run the load test.
Specify the load test configuration file you exported earlier in the loadTestConfigFile property.
Replace the <load-testing-resource> and <load-testing-resource-group> text placeholders with the name of your Azure load testing resource and the resource group.
Update your CI workflow to run a load test for your Azure load testing resource by using the Azure CLI. Use the specifics of your CI tool to add the following commands to your CI workflow:
Sign into the Azure subscription by using the service principal.
Use the clientId, clientSecret, and tenantId values you stored previously.
Azure CLI
az login --service-principal-u$AZURE_CLIENT_ID-p$AZURE_CLIENT_SECRET-t$AZURE_TENANT_IDaz account set -s$AZURE_SUBSCRIPTION_ID
Create a load test by using the load test configuration YAML file.
Replace the <load-testing-resource>, <load-testing-resource-group>, and <load-test-config-yaml> text placeholders with the name of the load testing resource, the resource group name, and the file name of the load test configuration YAML file you added to the repository previously.
Azure CLI
az load test create --load-test-resource<load-testing-resource>--resource-group<load-testing-resource-group>--test-id sample-test-id--load-test-config-file<load-test-config-yaml>
Run the load test.
Azure CLI
testRunId="run_"`date +"%Y%m%d%_H%M%S"`
displayName="Run"`date +"%Y/%m/%d_%H:%M:%S"`
az load test-run create --load-test-resource<load-testing-resource>--test-id sample-test-id--test-run-id$testRunId--display-name$displayName--description"Test run from CLI"
Retrieve and display the client-side metrics for the load test run.
Azure CLI
az load test-run metrics list --load-test-resource<load-testing-resource>--test-run-id$testRunId--metric-namespace LoadTestRunMetrics
View load test results
When you run a load test from your CI/CD pipeline, you can view the summary results directly in the CI/CD output log. If you published the test results as a pipeline artifact, you can also download a CSV file for further reporting.
Clean up resources
If you don't plan to use any of the resources that you created, delete them so you don't incur any further charges.
Learn how to optimize application performance by simulating real-world loads with Azure Load Testing service. Learn how to automate load testing with GitHub Actions to ensure consistent application performance and scalability.