Zelfstudie: Prestatie regressies identificeren met GitHub Actions en Azure Load Testing Preview

In deze zelfstudie leert u hoe u het testen van prestatie-regressie kunt automatiseren met Azure Load Testing Preview en GitHub Actions. U configureert een GitHub ACTIONS CI/CD-werkstroom om een belastingstest uit te voeren voor een voorbeeldwebtoepassing en gebruikt vervolgens de resultaten om prestatie-regressies te identificeren.

Zie de bijbehorende zelfstudie over Azure Pipelines als u Azure Pipelines gebruikt voor uw CI/CD-werkstromen.

U leert het volgende:

Vereisten

• Een Azure-account met een actief abonnement. Als u nog geen abonnement op Azure hebt, maak dan een gratis account aan voordat u begint.
• Een GitHub account waar u een opslagplaats kunt maken. Als u nog geen account hebt, kunt u gratis een account maken.
• Een bestaande Azure Load Testing-resource. Zie Een belastingstest maken en uitvoeren om een resource voor het testen van belasting te maken.

Uw opslagplaats instellen

Om aan de slag te gaan, hebt u eerst een GitHub met de voorbeeldwebtoepassing nodig. Vervolgens gebruikt u deze opslagplaats om een werkstroom voor GitHub te configureren om de belastingstest uit te voeren.

1. Open een browser en navigeer naar de bronopslagplaats van GitHub voorbeeldtoepassing:https://github.com/Azure-Samples/nodejs-appsvc-cosmosdb-bottleneck.git

   De voorbeeldtoepassing is een Node.js app die bestaat uit Azure App Service webonderdeel en een Cosmos DB database.

2. Selecteer Fork om de opslagplaats van de voorbeeldtoepassing te vervorken naar uw GitHub account.

   

Het Apache JMeter-script configureren

De bron-repo van de voorbeeldtoepassing bevat een Apache JMeter-script met de naam SampleApp.jmx. Met dit script worden drie API-aanroepen uitgevoerd voor elke test iteratie:

• add - Voert een bewerking voor het invoegen van gegevens Cosmos DB voor het aantal bezoekers op de web-app.
• get - Voert een GET-bewerking uit vanaf Cosmos DB om het aantal op te halen.
• lasttimestamp - Werkt de tijdstempel bij sinds de laatste gebruiker naar de website is gegaan.

In deze sectie gaat u het Apache JMeter-script bijwerken met de URL van uw voorbeeld-web-app.

1. Open sampleApp.jmx in de opslagplaats van uw voorbeeldtoepassing om het te bewerken.

   

2. Zoek naar <stringProp name="HTTPSampler.domain">.

   U ziet drie exemplaren van <stringProp name="HTTPSampler.domain"> in het bestand.

3. Vervang de waarde in alle drie de exemplaren door de URL van App Service voorbeeldtoepassing.

   <stringProp name="HTTPSampler.domain">{your-app-name}.azurewebsites.net</stringProp>
   

   U implementeert de voorbeeldtoepassing in een Azure App Service web-app met behulp van de werkstroom GitHub acties in de volgende stappen. Vervang op dit moment de tijdelijke tekst in het vorige XML-fragment door een unieke naam die u wilt verstrekken {your-app-name} aan App Service web-app. Vervolgens gebruikt u dezelfde naam om de web-app te maken.

   Belangrijk

   Neem of niet op in de URL van https http de voorbeeldtoepassing.

4. Commit your changes to the main branch.

Toegangsmachtigingen GitHub Azure instellen

In deze sectie configureert u uw opslagplaats GitHub machtigingen voor toegang tot de Azure Load Testing-resource.

Voor toegang tot Azure-resources maakt u een Azure Active Directory service-principal en gebruikt u op rollen gebaseerd toegangsbeheer om de benodigde machtigingen toe te wijzen.

1. Voer de volgende Azure CLI-opdracht uit om een service-principal te maken:

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

   Vervang in de vorige opdracht de tekst van de tijdelijke aanduiding <subscription-id> door uw Azure-abonnements-id van uw Azure Load Testing-resource.

   Het resultaat van de Azure CLI-opdracht is een JSON-tekenreeks die u in een latere stap aan uw GitHub toevoegt.

   {
     "clientId": "<my-client-id>",
     "clientSecret": "<my-client-secret>",
     "subscriptionId": "<my-subscription-id>",
     "tenantId": "<my-tenant-id>",
     (...)
   }
   

2. Navigeer naar uw gevorkte voorbeeldtoepassing GitHub opslagplaats.

3. Voeg een nieuw geheim toe aan GitHub opslagplaats door Instellingen > Geheimen > Geheim nieuwe opslagplaats te selecteren.

   

4. Voer AZURE_CREDENTIALS naam in, plak het JSON-antwoord van de Azure CLI voor de waarde en selecteer geheim toevoegen.

   

5. Als u de service-principal toegang wilt verlenen tot de Azure Load Testing-service, wijst u de rol Load Test Contributor toe aan de service-principal.

   Haal eerst de object-id van de service-principal op door deze Azure CLI-opdracht uit te voeren:

   az ad sp list --filter "displayname eq 'my-load-test-cicd'" -o table
   

   Wijs vervolgens de rol Load Test Contributor toe aan de service-principal. Vervang de tekst van de tijdelijke aanduiding <sp-object-id> door de ObjectId-waarde uit de vorige Azure CLI-opdracht. Vervang ook de door <subscription-name-or-id> uw Azure-abonnements-id.

   az role assignment create --assignee "<sp-object-id>" \
       --role "Load Test Contributor" \
       --subscription "<subscription-name-or-id>"
   

De werkstroom GitHub acties configureren om een belastingstest uit te voeren

In deze sectie stelt u een werkstroom voor GitHub acties in die de belastingstest activeert.

Als u een test wilt uitvoeren met Azure Load Testing vanuit een CI/CD-werkstroom, hebt u een YAML-configuratiebestand voor belastingstests nodig. De opslagplaats van de voorbeeldtoepassing bevat het bestand SampleApp.yaml dat de parameters bevat voor het uitvoeren van de test.

1. Open het werkstroombestand .github/workflows/workflow.yml GitHub Actions in de opslagplaats van uw voorbeeldtoepassing.

2. Bewerk het bestand en vervang de volgende tijdelijke aanduidingen.

   Tijdelijke aanduiding	Waarde
   <your-azure-web-app>	De Azure App Service web-app. Deze naam moet overeenkomen met de naam die wordt gebruikt voor de eindpunt-URL in het sampleApp.jmx-testscript.
   <your-azure-load-testing-resource-name>	De naam van uw Azure Load Testing-resource.
   <your-azure-load-testing-resource-group-name>	De naam van de resourcegroep die de Azure Load Testing-resource bevat.

   Belangrijk

   De naam van de Azure-web-app moet overeenkomen met de naam die u hebt gebruikt voor de eindpunt-URL in het sampleApp.jmx-testscript.

   env:
     AZURE_WEBAPP_NAME: "<your-azure-web-app>"
     LOAD_TEST_RESOURCE: "<your-azure-load-testing-resource-name>"
     LOAD_TEST_RESOURCE_GROUP: "<your-azure-load-testing-resource-group-name>"
   

3. Commit your changes directly to the main branch.

   

   De door commit activeert de werkstroom GitHub Acties in uw opslagplaats. U kunt controleren of de werkstroom wordt uitgevoerd door naar het tabblad Acties te gaan.

Resultaten van belastingstests weergeven

De werkstroom GitHub acties voert de volgende stappen uit voor elke update van de main branch:

• Implementeer de voorbeeld-Node.js toepassing in een Azure-app Services-web-app. De naam van de web-app is geconfigureerd in het werkstroombestand.
• Activeer Azure Load Testing om de belastingstest te maken en uit te voeren op basis van het Apache JMeter-script en het YAML-bestand voor testconfiguratie in de opslagplaats.

In deze sectie bekijkt u de resultaten van de belastingtest in het werkstroomlogboek GitHub acties.

1. Selecteer het tabblad Acties in uw GitHub opslagplaats om de lijst met werkstromen die worden uitgevoerd te bekijken.

   

2. Selecteer de werkstroom die wordt uitgevoerd in de lijst om naar de details van de run en logboekregistratie te navigeren.

   

   Zodra de belastingstest is uitgevoerd, kunt u de samenvattingsgegevens van de test en de metrische gegevens aan de clientzijde bekijken in de werkstroomlogboeken. Het logboek bevat ook de stappen voor het navigeren naar het Azure Load Testing-dashboard voor deze belastingstest.

3. Selecteer in het scherm details van de werkstroomrun het artefact loadTestResults om de resultatenbestanden van de belastingtest te downloaden.

   

Criteria voor testpass/fail definiëren

In deze sectie voegt u foutcriteria toe om het resultaat van uw belastingstest te bepalen. Als ten minste één van de foutcriteria waar is, mislukt de belastingstest.

U kunt deze criteria opgeven in het YAML-bestand voor testconfiguratie.

1. Bewerk het bestand SampleApp.yml in uw GitHub opslagplaats.

2. Voeg het volgende codefragment toe aan het einde van het bestand.

   failureCriteria: 
   - avg(response_time_ms) > 100
   - percentage(error) > 20
   

   U hebt nu foutcriteria opgegeven voor uw belastingstest. De test mislukt als aan ten minste één van deze voorwaarden wordt voldaan:

   • De totale gemiddelde reactietijd is groter dan 100 ms.
   • Het cumulatief percentage fouten is groter dan 20%.

3. De wijzigingen door te voeren en naar de main branch van de opslagplaats te pushen.

   De wijzigingen activeren de CI/CD GitHub werkstroom acties.

4. Selecteer het tabblad Acties en selecteer vervolgens de meest recente werkstroomrun om de werkstroomlogboeken te bekijken.

   

   Nadat de belastingstest is uitgevoerd, ziet u dat de werkstroom is mislukt omdat de gemiddelde reactietijd hoger was dan u hebt opgegeven in de foutcriteria.

   De Azure Load Testing-service evalueert de criteria tijdens de testuitvoering. Als een van deze voorwaarden mislukt, retourneert de Azure Load Testing-service een afsluitende code die niet nul is. Deze code informeert de CI/CD-werkstroom dat de test is mislukt.

5. Bewerk het bestand SampleApp.yml en wijzig de criteria voor testfout.

   failureCriteria: 
   - avg(response_time_ms) > 5000
   - percentage(error) > 20
   

6. De wijzigingen door te voeren om de werkstroom GitHub acties te activeren.

   

   De belastingstest slaagt nu en de werkstroom is voltooid.

Parameters doorgeven aan uw belastingstests vanuit de werkstroom

Vervolgens gaat u de belastingstest parameteriseren met behulp van werkstroomvariabelen. Deze parameters kunnen geheimen zijn, zoals wachtwoorden of niet-geheimen.

In deze zelfstudie configureren we de voorbeeldtoepassing opnieuw om alleen beveiligde aanvragen te accepteren. Als u een beveiligde aanvraag wilt verzenden, moet u een geheime waarde doorgeven in de HTTP-aanvraag.

1. Bewerk het bestand SampleApp.yaml in uw GitHub opslagplaats.

   Werk de configuratie-instelling testPlan bij om het bestand SampleApp_Secrets.jmx te gebruiken.

   version: v0.1
   testName: SampleApp
   testPlan: SampleApp_Secrets.jmx
   description: 'SampleApp Test with secrets'
   engineInstances: 1
   

   Het apache JMeter-script SampleApp_Secrets.jmx maakt gebruik van een door de gebruiker gedefinieerde variabele die de geheime waarde op haalt met de aangepaste functie ${__GetSecret(secretName)} . Apache JMeter geeft deze geheime waarde vervolgens door aan het eindpunt van de voorbeeldtoepassing.

2. De wijzigingen in het YAML-bestand door te voeren.

3. Bewerk het bestand config.json in uw GitHub opslagplaats.

   Werk de enableSecretsFeature instelling bij naar true om de voorbeeldtoepassing opnieuw te configureren om alleen beveiligde aanvragen te accepteren.

   {
       "enableSecretsFeature": true
   }
   

4. De wijzigingen door te voeren in het bestand config.json.

5. Bewerk het SampleApp_Secrets.jmx-bestand.

6. Zoek naar <stringProp name="HTTPSampler.domain">.

   U ziet drie exemplaren van <stringProp name="HTTPSampler.domain"> in het bestand.

7. Vervang de waarde in alle drie de exemplaren door de URL van App Service voorbeeldtoepassing.

   <stringProp name="HTTPSampler.domain">{your-app-name}.azurewebsites.net</stringProp>
   

   In de volgende stappen implementeert u de beveiligde voorbeeldtoepassing in Azure App Service web-app met behulp van de werkstroom GitHub acties. Vervang in het vorige XML-fragment de tekst van de tijdelijke aanduiding door de unieke naam van de {your-app-name} App Service web-app. Vervolgens gebruikt u dezelfde naam om de web-app te maken.

   Belangrijk

   Neem of niet op in de URL van https http de voorbeeldtoepassing.

8. Sla het Apache JMeter-script op en door.

9. Voeg een nieuw geheim toe aan GitHub opslagplaats door Instellingen > Geheimen > Geheim nieuwe opslagplaats te selecteren.

10. Voer MY_SECRET naam in voor de naam en 1797669089 voor de waarde en selecteer vervolgens Geheim toevoegen.

    

11. Bewerk het bestand .github/workflows/workflow.yml om het geheim door te geven aan de belastingstest.

    Bewerk de azure Load Testing-actie door het volgende YAML-fragment toe te voegen.

    secrets: |
      [
          {
          "name": "appToken",
          "value": "${{ secrets.MY_SECRET }}"
          }
      ]
    

12. De wijzigingen door te voeren, waardoor de werkstroom GitHub acties wordt triggeren.

    De taak Belasting testen van Azure geeft het geheim van de opslagplaats veilig door aan de test-engine. De geheime parameter wordt alleen gebruikt tijdens het uitvoeren van de belastingstest en vervolgens wordt de waarde ervan uit het geheugen verwijderd.

Azure Load Testing-actie

In deze sectie wordt de Azure Load Testing-GitHub beschreven. U kunt deze actie gebruiken door te verwijzen naar azure/load-testing@v1 de actie in uw werkstroom. De actie wordt uitgevoerd op Windows, Linux en Mac-hardlopers.

U kunt de volgende parameters gebruiken om de GitHub configureren.

In het volgende YAML-codefragment wordt beschreven hoe u de actie gebruikt in een GitHub Actions-werkstroom.

- name: 'Azure Load Testing'
  uses: azure/load-testing@v1
  with:
    loadTestConfigFile: '< YAML File path>'
    loadTestResource: '<name of the load test resource>'
    resourceGroup: '<name of the resource group of your load test resource>' 
    secrets: |
      [
          {
          "name": "<Name of the secret>",
          "value": "${{ secrets.MY_SECRET1 }}",
          },
          {
          "name": "<Name of the secret>",
          "value": "${{ secrets.MY_SECRET2 }}",
          }
      ]
    env: |
      [
          {
          "name": "<Name of the variable>",
          "value": "<Value of the variable>",
          },
          {
          "name": "<Name of the variable>",
          "value": "<Value of the variable>",
          }
      ]

Resources opschonen

Als u niet van plan bent om een van de resources te gebruiken die u hebt gemaakt, verwijdert u deze zodat er geen verdere kosten in rekening worden gebracht.

• In Azure Portal:

  1. Selecteer de menuknop in de linkerbovenhoek en selecteer vervolgens Resourcegroepen.

  2. Selecteer de resourcegroep die u hebt gemaakt uit de lijst.

  3. Selecteer Resourcegroep verwijderen.

     

  4. Voer de naam van de resourcegroup in. Selecteer vervolgens Verwijderen.

• U kunt ook de Azure CLI gebruiken.

  az group delete --name <yourresourcegroup>
  

  Als u de resourcegroep verwijdert, worden alle resources in de resourcegroep verwijderd.

Volgende stappen

U hebt nu een werkstroom voor GitHub acties gemaakt die gebruikmaakt van Azure Load Testing voor het automatisch uitvoeren van belastingstests. Met behulp van criteria voor doorgeven/mislukken kunt u de status van de CI/CD-werkstroom instellen. Met parameters kunt u de uitvoering van de belastingstest configureerbaar maken.

• Zie Parameterize a load test (Een belastingstest parameteriseren) voor meer informatie over het parameteriseren van belastingstests.
• Zie Testcriteria definiëren voor meer informatie over het definiëren van testcriteria voor het slagen/mislukken van tests.