Tutoriel : Identifier les régressions des performances en automatisant les tests de charge avec CI/CD

Article
06/01/2023

Ce tutoriel explique comment identifier rapidement les régressions de performances à l’aide d’outils Test de charge Azure et CI/CD. Identifiez rapidement quand votre application rencontre des performances dégradées sous charge en exécutant des tests de charge dans Azure Pipelines ou GitHub Actions.

Dans ce tutoriel, vous allez configurer un pipeline CI/CD qui exécute un test de charge pour un exemple d’application sur Azure. Vous allez vérifier le comportement de l’application sous charge directement à partir du tableau de bord CI/CD. Vous allez ensuite utiliser les critères d’échec du test de charge pour recevoir une alerte lorsque l’application ne répond pas à vos exigences de qualité.

Dans ce tutoriel, vous allez utiliser un exemple d’application Node.js et de script JMeter. Le tutoriel ne nécessite pas de compétences de codage ou Apache JMeter.

Vous découvrirez comment effectuer les actions suivantes :

Configurez le dépôt GitHub d’exemple d’application.
Configurez l’authentification du service pour votre workflow CI/CD.
Configurez le workflow CI/CD pour exécuter un test de charge.
Affichez les résultats des tests de charge dans le tableau de bord CI/CD.
Définissez les critères d’échec du test de charge pour identifier les régressions des performances.

Notes

Azure Pipelines applique un délai d’expiration de 60 minutes aux travaux exécutés sur des agents hébergés par Microsoft pour des projets privés. Si le délai d’exécution de votre test de charge dépasse 60 minutes, vous devrez payer pour l’utilisation d’une capacité supplémentaire, à défaut de quoi, le pipeline expirera sans attendre les résultats du test. Vous pouvez afficher l’état du test de charge dans le Portail Azure.

Prérequis

Compte Azure avec un abonnement actif. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Si vous utilisez Azure Pipelines, une organisation et un projet Azure DevOps. Si vous ne possédez pas d’organisation Azure DevOps, vous pouvez en créer une gratuitement. Si vous avez besoin d’aide pour prendre en main Azure Pipelines, consultez Créer votre premier pipeline.
Un compte GitHub, dans lequel vous pouvez créer un dépôt. Si vous n’en avez pas, vous pouvez en créer un gratuitement.

Configurer le dépôt d’exemple d’application

Pour vous familiariser avec ce tutoriel, vous devez d’abord configurer un exemple d’application web Node.js. L’exemple d’application contient une définition Azure Pipelines pour déployer l’application sur Azure et déclencher un test de charge.

Ouvrez un navigateur et accédez au référentiel GitHub source de l’exemple d’application.

L’exemple d’application est une application Node.js qui se compose d’un composant web Azure App Service et d’une base de données Azure Cosmos DB.
Sélectionnez Dupliquer (fork) pour dupliquer le référentiel de l’exemple d’application dans votre compte GitHub.

Le référentiel de l’exemple d’application contient un script Apache JMeter nommé SampleApp.jmx. Le script teste les trois API dans l’exemple d’application :

add : effectue une insertion sur Azure Cosmos DB pour stocker le nombre de visiteurs de l’application web.
get : effectue une opération de lecture sur Azure Cosmos DB pour récupérer le nombre de visiteurs.
lasttimestamp : met à jour la date et heure en mémoire de la dernière visite de l’utilisateur.

Configurer l’authentification au service

Avant de configurer le pipeline CI/CD pour exécuter un test de charge, vous accorderez au workflow CI/CD les autorisations nécessaires pour accéder à votre ressource de test de charge Azure.

Azure Pipelines
Actions GitHub

Pour accéder à votre ressource Test de charge Azure à partir du workflow Azure Pipelines, vous créez d’abord une connexion de service dans votre projet Azure DevOps. La connexion de service crée un principal de service Azure Active Directory. Ce principal de service représente votre workflow Azure Pipelines dans Azure Active Directory.

Ensuite, vous accordez des autorisations à ce principal de service pour créer et exécuter un test de charge avec votre ressource Test de charge Azure.

Créer une connexion de service dans Azure Pipelines

Créez une connexion de service dans Azure Pipelines afin que votre workflow CI/CD ait accès à votre abonnement Azure. Dans une prochaine étape, vous accorderez des autorisations pour créer et exécuter des tests de charge.

Connectez-vous à votre organisation Azure DevOps (https://dev.azure.com/<your-organization>) et sélectionnez votre projet.
Sélectionnez Paramètres du projet>Connexions de service.
Sélectionnez + Nouvelle connexion de service, la connexion de service Azure Resource Manager, puis Suivant.
Sélectionnez la méthode d’authentification Principal de service (automatique), puis Suivant.

Entrez les informations de connexion de service, puis sélectionnez Enregistrer pour créer la connexion de service.

Champ	Valeur
Niveau de portée	Abonnement.
Abonnement	Sélectionnez l’abonnement Azure qui hébergera votre ressource de test de charge.
Groupe de ressources	Laissez ce champ vide. Le pipeline crée un groupe de ressources pour la ressource Test de charge Azure.
Nom de la connexion de service	Saisissez un nom unique pour la connexion de service. Vous utiliserez ce nom plus tard pour configurer la définition du pipeline.
Accorder une autorisation d’accès à tous les pipelines	Coché.

Sélectionnez la connexion de service que vous avez créée dans la liste, puis sélectionnez Gérer le principal du service.
Dans le portail Azure, copiez la valeur ID (client) d’application.

Lancement d’Azure Cloud Shell

Azure Cloud Shell est un interpréteur de commandes interactif et gratuit que vous pouvez utiliser pour exécuter les étapes de cet article. Il contient des outils Azure courants préinstallés et configurés pour être utilisés avec votre compte.

Pour ouvrir Cloud Shell, sélectionnez simplement Essayer en haut à droite d’un bloc de code. Vous pouvez aussi lancer Cloud Shell dans un onglet distinct du navigateur en accédant à https://shell.azure.com.

Quand Cloud Shell s’ouvre, vérifiez que Bash est sélectionné pour votre environnement. Les sessions ultérieures utiliseront Azure CLI dans un environnement Bash. Sélectionnez Copier pour copier les blocs de code, collez-les dans Cloud Shell, puis appuyez sur Entrée pour les exécuter.

Cloud Shell est automatiquement authentifié sous le compte initial utilisé pour la connexion. Utilisez le script suivant pour vous connecter avec un autre abonnement, en remplaçant <Subscription ID> par votre ID d’abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit Azure avant de commencer.

subscription="<subscriptionId>" # add subscription here

az account set -s $subscription # ...or use 'az login'

Pour plus d’informations, consultez Définir l’abonnement actif ou Se connecter de manière interactive

Accorder l'accès au service Test de charge Azure

Affectez le rôle Contributeur du test de charge au principal de service pour l’autoriser à accéder au service Test de charge Azure. Ce rôle accorde l’accès au principal de service pour créer et exécuter des tests de charge avec votre service Test de charge Azure. En savoir plus sur la gestion des utilisateurs et des rôles dans le service Test de charge Azure.

Récupérez l’ID de l’objet principal de service à l’aide d’Azure CLI. Remplacez la valeur de l’espace réservé <application-client-id> par la valeur copiée.
```
object_id=$(az ad sp show --id "<application-client-id>" --query "id" -o tsv)
echo $object_id
```

Affectez le rôle Load Test Contributor au principal du service :

subscription=$(az account show --query "id" -o tsv)
echo $subscription

az role assignment create --assignee $object_id \
    --role "Load Test Contributor" \
    --scope /subscriptions/$subscription \
    --subscription $subscription

Pour accéder à votre ressource Test de charge Azure à partir du workflow GitHub Actions, vous créez d’abord un principal de service Azure Active Directory. Ce principal de service représente votre workflow GitHub Actions dans Azure Active Directory.

Ensuite, vous accordez des autorisations au principal de service pour créer et exécuter un test de charge avec votre ressource Test de charge Azure.

Lancement d’Azure Cloud Shell

subscription="<subscriptionId>" # add subscription here

az account set -s $subscription # ...or use 'az login'

Pour plus d’informations, consultez Définir l’abonnement actif ou Se connecter de manière interactive

Créer un principal du service

Créez un principal de service dans l’abonnement Azure et attribuez le rôle Contributeur afin que votre workflow GitHub Actions ait accès à votre abonnement Azure. Dans une prochaine étape, vous accorderez des autorisations pour créer et exécuter des tests de charge.

Créez un principal de service et attribuez le rôle Contributor :

subscription=$(az account show --query "id" -o tsv)
echo $subscription

az ad sp create-for-rbac --name "my-load-test-cicd" --role contributor \
                         --scopes /subscriptions/$subscription \
                         --sdk-auth

La sortie est un objet JSON qui représente le principal de service. Vous allez utiliser ces informations pour vous authentifier auprès d’Azure dans le workflow GitHub Actions.

Creating 'contributor' role assignment under scope '/subscriptions/123abc45-6789-0abc-def1-234567890abc'
{
  "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/"    
}

Notes

Il est possible que vous ayez un avertissement de dépréciation --sdk-auth lorsque vous exécutez cette commande. Vous pouvez également utiliser l’authentification basée sur OpenID Connect (OIDC) pour authentifier GitHub avec Azure. Apprenez comment utiliser l’action Azure login avec OpenID Connect.

Copiez l’objet JSON de sortie.
Ajoutez un secret GitHub AZURE_CREDENTIALS à votre dépôt pour stocker le principal de service que vous avez créé. L’action azure/login dans le workflow GitHub Actions utilise ce secret pour s’authentifier auprès d’Azure.

Notes

Si vous utilisez OpenID Connect pour vous authentifier auprès d’Azure, vous n’avez pas besoin de transmettre l’objet principal de service dans l’action de connexion Azure. Apprenez comment utiliser l’action Azure login avec OpenID Connect.
1. Dans GitHub, accédez à votre référentiel dupliqué, sélectionnez Paramètres >Secrets>Actions>Nouveau secret de référentiel.
2. Entrez les informations du nouveau secret, puis sélectionnez Ajouter un secret pour créer un secret.
  
  Champ Valeur
  
  Nom AZURE_CREDENTIALS
  
  Secret Collez les informations d’identification d’attribution de rôle JSON copiées précédemment.

Champ	Valeur
Nom	AZURE_CREDENTIALS
Secret	Collez les informations d’identification d’attribution de rôle JSON copiées précédemment.

Accorder l'accès au service Test de charge Azure

Récupérez l’ID de l’objet principal de service :

object_id=$(az ad sp list --filter "displayname eq 'my-load-test-cicd'" --query "[0].id" -o tsv)
echo $object_id

Affectez le rôle Load Test Contributor au principal du service :

az role assignment create --assignee $object_id \
    --role "Load Test Contributor" \
    --scope /subscriptions/$subscription \
    --subscription $subscription

Configurer le workflow CI/CD pour exécuter un test de charge

Vous allez maintenant créer un workflow CI/CD pour créer et exécuter un test de charge pour l’exemple d’application. Le référentiel d’exemple d’application contient déjà une définition de workflow CI/CD qui déploie d’abord l’application sur Azure, puis crée un test de charge basé sur le script de test JMeter (SampleApp.jmx). Vous allez mettre à jour l’exemple de fichier de définition du workflow pour spécifier les détails de l’abonnement et de l’application Azure.

Lors de la première exécution du workflow CI/CD, cela crée une ressource Test de charge Azure dans votre abonnement Azure à l’aide du modèle Azure Resource Manager (ARM) ARMTemplate/template.json. En savoir plus sur les modèles ARM.

Azure Pipelines
Actions GitHub

Vous allez créer un pipeline Azure lié à votre duplication du référentiel d’exemple d'application. Ce dépôt contient les éléments suivants :

Le code source de l'exemple d'application.
Le fichier de définition de pipeline azure-pipelines.yml.
Le script de test JMeter SampleApp.jmx.
Le fichier de configuration Test de charge Azure SampleApp.yaml.

Pour créer et exécuter le test de charge, la définition d’Azure Pipelines utilise l’extension de tâche Test de charge Azure à partir de la place de marché Azure DevOps.

Ouvrez l’extension de tâche Test de charge Azure dans la Place de marché Azure DevOps, puis sélectionnez Obtenir gratuitement.
Sélectionnez votre organisation Azure DevOps, puis sélectionnez Installer pour installer l’extension.

Si vous n’avez pas de privilèges d’administrateur pour l’organisation Azure DevOps sélectionnée, sélectionnez Demander pour demander à un administrateur d’installer l’extension.
Dans votre projet Azure DevOps, sélectionnez Pipelines dans le menu de navigation de gauche, puis sélectionnez Créer un pipeline.
Sous l’onglet Se connecter, sélectionnez GitHub.
Sélectionnez Autoriser Azure Pipelines pour autoriser Azure Pipelines à accéder à votre compte GitHub pour le déclenchement de workflows.
Sous l’onglet Sélectionner, sélectionnez le référentiel dupliqué de l’exemple d’application.

Azure Pipelines détecte automatiquement le fichier de définition du pipeline azure-pipelines.yml.
Notez que la définition du pipeline contient l’étape LoadTest, qui comporte deux tâches.

La tâche AzureResourceManagerTemplateDeployment déploie une nouvelle ressource de test de charge Azure dans votre abonnement Azure.

Ensuite, la AzureLoadTesttâche Test de charge Azure crée et démarre un test de charge. Cette tâche utilise le SampleApp.yamlfichier de configuration de test de charge, qui contient les paramètres de configuration du test de charge, tels que le nombre de moteurs de test parallèles.
```
- task: AzureLoadTest@1
  inputs:
    azureSubscription: $(serviceConnection)
    loadTestConfigFile: 'SampleApp.yaml'
    resourceGroup: $(loadTestResourceGroup)
    loadTestResource: $(loadTestResource)
    env: |
      [
        {
        "name": "webapp",
        "value": "$(webAppName).azurewebsites.net"
        }
      ]
```
Si un test de charge existe déjà, la tâche AzureLoadTest ne crée pas de test de charge, mais ajoute une série de tests à ce test de charge. Pour identifier les régressions au fil du temps, vous pouvez comparer plusieurs séries de tests.

Sous l’onglet Révision, remplacez le texte d’espace réservé suivant au début de la définition du pipeline :

Ces variables sont utilisées pour configurer le déploiement de l’exemple d’application et pour créer le test de charge.

Espace réservé	Valeur
`<Name of your webapp>`	Nom de l’application web Azure App Service.
`<Name of your webARM Service connection>`	Nom de la connexion de service que vous avez créée dans la section précédente.
`<Azure subscriptionId>`	Votre ID d’abonnement Azure.
`<Name of your load test resource>`	Nom de votre ressource Test de charge Azure.
`<Name of your load test resource group>`	Nom du groupe de ressources qui contient la ressource Test de charge Azure.

Capture d’écran montrant l’onglet Révision d’Azure Pipelines lors de la création d’un pipeline.

Sélectionnez Enregistrer et exécuter, entrez le texte du Message de validation, puis sélectionnez Enregistrer et exécuter.

Azure Pipelines exécute désormais le workflow CI/CD, déploie l’exemple d’application et crée le test de charge.
Sélectionnez Pipelines dans le volet de navigation gauche, puis sélectionnez une nouvelle exécution de pipeline dans la liste pour surveiller l’état.

Vous pouvez afficher le journal d’exécution détaillé en sélectionnant le travail de pipeline.

Vous allez créer un workflow GitHub Actions dans votre duplication du référentiel d’exemple d’application. Ce dépôt contient les éléments suivants :

Le code source de l'exemple d'application.
Le workflow GitHub Actions .github/workflows/workflow.yml.
Le script de test JMeter SampleApp.jmx.
Le fichier de configuration Test de charge Azure SampleApp.yaml.

Pour créer et exécuter le test de charge, le workflow GitHub Actions utilise l’action Test de charge Azure à partir de la Place de marché GitHub Actions.

L’exemple de dépôt d’application contient déjà un exemple de fichier de workflow .github/workflows/workflow.yml. Le workflow GitHub Actions exécute les étapes suivantes pour chaque mise à jour de la branche primaire :

Appel du test de charge Azure à l’aide de l’action Test de charge Azure et de l’exemple de script Apache JMeter SampleApp.jmx et du fichier de configuration de test de charge SampleApp.yaml.

Ouvrez le fichier de workflow GitHub Actions .github/workflows/workflow.yml dans le référentiel de votre application d’exemple.

Notez le travail loadTest, qui crée et exécute le test de charge :

L’action azure/login s’authentifie auprès d’Azure en utilisant le secret AZURE_CREDENTIALS pour transmettre les informations d’identification du principal de service.
```
  - name: Login to Azure
    uses: azure/login@v1
    continue-on-error: false
    with:
      creds: ${{ secrets.AZURE_CREDENTIALS }}
```

L’action azure/arm-deploy déploie une nouvelle ressource de test de charge Azure dans votre abonnement Azure.

    - name: Create Azure Load Testing resource
            uses: azure/arm-deploy@v1
            with:
              resourceGroupName: ${{ env.LOAD_TEST_RESOURCE_GROUP }}
              template: ./ARMTemplate/template.json
              parameters: ./ARMTemplate/parameters.json name=${{ env.LOAD_TEST_RESOURCE }} location="${{ env.LOCATION }}"

L’azure/load-testingaction Test de charge Azure crée et démarre un test de charge. Cette action utilise le SampleApp.yamlfichier de configuration de test de charge, qui contient les paramètres de configuration du test de charge, tels que le nombre de moteurs de test parallèles.
```
  - name: 'Azure Load Testing'
    uses: azure/load-testing@v1
    with:
      loadTestConfigFile: 'SampleApp.yaml'
      loadTestResource: ${{ env.LOAD_TEST_RESOURCE }}
      resourceGroup: ${{ env.LOAD_TEST_RESOURCE_GROUP }}
      env: |
        [
          {
          "name": "webapp",
          "value": "${{ env.AZURE_WEBAPP_NAME }}.azurewebsites.net"
          }
        ]          
```
Si un test de charge existe déjà, l’action azure/load-testing ne crée pas de test de charge, mais ajoute une série de tests à ce test de charge. Pour identifier les régressions au fil du temps, vous pouvez comparer plusieurs séries de tests.

Remplacez le texte d’espace réservé suivant au début du fichier de définition du workflow :

Ces variables sont utilisées pour configurer le déploiement de l’exemple d’application et pour créer le test de charge.

Espace réservé	Valeur
`<Name of your webapp>`	Nom de l’application web Azure App Service.
`<Name of your load test resource>`	Nom de votre ressource Test de charge Azure.
`<Name of your load test resource group>`	Nom du groupe de ressources qui contient la ressource Test de charge Azure.

env:
  AZURE_WEBAPP_NAME: "<Name of your webapp>"    # set this to your application's name
  LOAD_TEST_RESOURCE: "<Name of your load test resource>"
  LOAD_TEST_RESOURCE_GROUP: "<Name of your load test resource group>"

Validez vos modifications dans la branche principale.

La validation déclenchera le workflow GitHub Actions dans votre référentiel. Vérifiez que le workflow est en cours d’exécution en accédant à l’onglet Actions.

Voir les résultats des tests de charge

Le service Test de charge Azure vous permet d’afficher les résultats de l’exécution du test de charge directement dans la sortie du workflow CI/CD. Le journal CI/CD contient les métriques côté client suivantes :

Métriques de temps de réponse : moyenne, minimale, médiane, maximale et 90-95-99 centiles.
Nombre de demandes par seconde.
Nombre total de requêtes.
Nombre total d’erreurs.
Taux d’erreur.

De plus, le fichier de résultats de tests de charge est disponible en tant qu’artefact d’exécution de workflow, que vous pouvez télécharger pour obtenir des rapports supplémentaires.

Azure Pipelines
Actions GitHub

Dans votre projet Azure DevOps, sélectionnez Pipelines, puis votre définition de pipeline dans la liste.
Sélectionnez l’exécution du pipeline pour en afficher le résumé.
Sélectionnez Test de charge dans la section Travaux pour afficher le journal de pipeline.

Une fois le test de charge terminé, vous pouvez afficher les informations de résumé du test et les mesures côté client dans le journal de pipeline. Le journal mentionne également l’URL permettant d’accéder au tableau de bord de Test de charge Azure pour ce test de charge.
Dans l’affichage du journal de pipeline, sélectionnez Test de charge, puis 1 artefact produit pour télécharger les fichiers de résultats du test de charge.

Définir les critères de réussite des tests

Le service Test de charge Azure vous permet de définir des critères d’échec du test de charge. Ces critères déterminent quand un test de charge doit réussir ou échouer. Par exemple, votre test de charge doit échouer lorsque le temps de réponse moyen est supérieur à une valeur spécifique ou lorsque trop d’erreurs se produisent.

Lorsque vous exécutez un test de charge dans le cadre d’un pipeline CI/CD, l’état de l’exécution de pipeline reflète l’état du test de charge. Cette approche vous permet d'identifier rapidement les régressions de performance, ou le comportement dégradé de l'application lorsque celle-ci rencontre une charge élevée.

Dans cette section, vous allez configurer des critères d’échec du test en fonction du temps de réponse moyen et du taux d’erreur.

Vous pouvez spécifier des critères d’échec du test de charge pour le Test de charge Azure dans le fichier YAML de configuration de test. En savoir plus sur la configuration des critères d’échec du test de charge.

Modifiez le fichier SampleApp.yml dans votre duplication du dépôt GitHub de l’exemple d’application.
Ajoutez l’extrait de code suivant à la fin du fichier :
```
failureCriteria: 
    - avg(response_time_ms) > 100
    - percentage(error) > 20
```
Vous avez maintenant spécifié des critères d’échec pour votre test de charge en fonction du temps de réponse moyen et du taux d’erreur. Le test échoue si au moins l’une de ces conditions est remplie :
- Le temps de réponse moyen total est supérieur à 100 ms.
- Le pourcentage total d’erreurs est supérieur à 20 %.
Validez et envoyez (push) les modifications à la branche principale du référentiel.

Les modifications déclencheront le workflow CI/CD.
Une fois le test terminé, notez que l’exécution du pipeline CI/CD a échoué.

Dans le journal de sortie CI/CD, vous constatez que le test a échoué car l’un des critères d’échec a été respecté. Le temps de réponse moyen du test de charge était plus élevé que la valeur spécifiée dans les critères d’échec.

Le service Test de charge Azure évalue les critères pendant l’exécution du test. Si l’une de ces conditions échoue, le service Test de charge Azure retourne un code de sortie différent de zéro. Ce code indique au workflow CI/CD que le test a échoué.
Modifiez le fichier SampleApp.yml et changez les critères d’échec du test pour augmenter le critère de temps de réponse moyen :
```
failureCriteria: 
    - avg(response_time_ms) > 5000
    - percentage(error) > 20
```
Validez les modifications pour déclencher de nouveau le workflow CI/CD.

Une fois le test terminé, vous remarquez que le test de charge et le workflow CI/CD s’exécutent correctement.

Nettoyer les ressources

Important

Vous pouvez réutiliser la ressource Test de charge Azure que vous avez créée pour d’autres tutoriels et articles de procédure relatifs à Test de charge Azure.

Si vous n’avez pas l’intention d’utiliser les ressources que vous avez créées, supprimez-les pour éviter la facturation de frais supplémentaires. Si vous avez déployé l’exemple d’application dans un autre groupe de ressources, vous pouvez répéter les étapes suivantes.

Pour supprimer des ressources à l’aide du Portail Azure :

Sélectionnez le bouton du menu en haut à gauche, puis Groupes de ressources.
Dans la liste, sélectionnez le groupe de ressources créé.
Sélectionnez Supprimer le groupe de ressources.
Entrez le nom du groupe de ressources. Puis sélectionnez Supprimer.

Pour supprimer des ressources à l’aide d’Azure CLI, entrez la commande suivante :

az group delete --name <yourresourcegroup>

N’oubliez pas que la suppression du groupe de ressources supprime toutes les ressources qu’il contient.

Étapes suivantes

Vous avez à présent créé un workflow CI/CD qui utilise Test de charge Azure pour exécuter automatiquement des tests de charge. En utilisant des critères d’échec de test de charge, vous pouvez définir l’état du workflow CI/CD et identifier rapidement les dégradations des performances et du comportement de l’application.

Apprenez-en davantage sur la configuration de l’analyse côté serveur.
En savoir plus sur la Comparaison des résultats entre plusieurs séries de tests.
Apprenez-en davantage sur le paramétrage d’un test de charge.
Apprenez-en davantage sur la Définition des critères d’échec de test.

Tutoriel : Identifier les régressions des performances en automatisant les tests de charge avec CI/CD

Prérequis

Configurer le dépôt d’exemple d’application

Configurer l’authentification au service

Créer une connexion de service dans Azure Pipelines

Lancement d’Azure Cloud Shell

Accorder l'accès au service Test de charge Azure

Lancement d’Azure Cloud Shell

Créer un principal du service

Accorder l'accès au service Test de charge Azure

Configurer le workflow CI/CD pour exécuter un test de charge

Voir les résultats des tests de charge

Définir les critères de réussite des tests

Nettoyer les ressources

Étapes suivantes

Ressources supplémentaires

Ressources supplémentaires

Tutoriel : Identifier les régressions des performances en automatisant les tests de charge avec CI/CD

Prérequis

Configurer le dépôt d’exemple d’application

Configurer l’authentification au service

Créer une connexion de service dans Azure Pipelines

Lancement d’Azure Cloud Shell

Connexion à Azure

Accorder l'accès au service Test de charge Azure

Configurer le workflow CI/CD pour exécuter un test de charge

Voir les résultats des tests de charge

Définir les critères de réussite des tests

Nettoyer les ressources

Étapes suivantes

Ressources supplémentaires

Ressources supplémentaires