Oefening: tijdelijke omgevingen maken voor pull-aanvragen

Voltooid

Sommige teamleden hebben u verteld dat ze de geautomatiseerde Bicep linter-feedback krijgen over hun codewijzigingen voordat ze ze naar andere teamleden sturen om ze te beoordelen. Nu hebt u besloten om uw inzenders en revisoren de mogelijkheid te geven om hun code in een kortstondige omgeving te implementeren en te controleren.

In deze oefening werkt u uw werkstroom voor pull-aanvragen bij om een tijdelijke omgeving te implementeren wanneer een pull-aanvraag wordt geopend en implementeert u deze opnieuw wanneer code naar de pull-aanvraagbranch wordt gepusht. U maakt ook een andere werkstroom om de omgeving automatisch te verwijderen wanneer de pull-aanvraag wordt gesloten. U gaat uw wijzigingen testen door een pull-aanvraag voor uw website te maken om een Docker-containerinstallatiekopie te gebruiken.

Tijdens het proces gaat u het volgende doen:

• Werk de werkstroom voor pull-aanvragen bij om een tijdelijke omgeving te implementeren.
• Maak een werkstroom voor het verwijderen van pull-aanvragen om de tijdelijke omgeving te verwijderen.
• Maak een pull-aanvraag en bekijk hoe de tijdelijke omgeving wordt gemaakt.
• Keur de pull-aanvraag goed en bekijk hoe de tijdelijke omgeving wordt verwijderd.

Werk de werkstroom voor pull-aanvragen bij om een tijdelijke omgeving te implementeren

Om te beginnen moet u uw pr-validatiewerkstroom bijwerken om een tijdelijke omgeving te maken.

1. Bekijk in de Visual Studio Code-terminal de hoofdbranch van de opslagplaats.

   git checkout main
   

2. Haal de nieuwste versie van de code op uit GitHub, inclusief de wijzigingen die u in een eerdere oefening hebt samengevoegd.

   git pull
   

3. Open het bestand .github/workflows/pr-validation.yml in Visual Studio Code.

4. Voeg boven aan het bestand, onder de name instelling, een concurrency instelling toe:

   name: pr-validation
   concurrency: ${{ github.event.number }}
   

   Met deze instelling voorkomt u dat meerdere werkstromen voor dezelfde pull-aanvraag tegelijkertijd worden uitgevoerd, wat onvoorspelbare resultaten kan veroorzaken wanneer u resources implementeert in Azure.

5. Definieer bovenaan het bestand, onder de on sectie waarin de trigger wordt gedefinieerd, de permissions sectie:

   name: pr-validation
   concurrency: ${{ github.event.number }}
   
   on: pull_request
   
   permissions:
     id-token: write
     contents: read
   

6. Voeg onder de permissions sectie twee nieuwe omgevingsvariabelen toe:

   name: pr-validation
   concurrency: ${{ github.event.number }}
   
   on: pull_request
   
   permissions:
     id-token: write
     contents: read
   
   env:
     resourceGroupName: pr_${{ github.event.number }}
     resourceGroupLocation: westus3
   

   De resourceGroupName omgevingsvariabele geeft de naam op van de resourcegroep die moet worden gebruikt voor elke tijdelijke omgeving. Elke resourcegroep krijgt de naam pr_123, waarbij 123 het unieke pull-aanvraagnummer is.

   De resourceGroupLocation omgevingsvariabele geeft aan dat uw tijdelijke omgevingen allemaal moeten worden geïmplementeerd in de Azure-regio VS - west 3.

7. Definieer een nieuwe taak met de naam deploy, onder de lint taak:

   jobs:
     lint:
       uses: ./.github/workflows/lint.yml
   
     deploy:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v3
         - uses: azure/login@v1
           name: Sign in to Azure
           with:
             client-id: ${{ secrets.AZURE_CLIENT_ID }}
             tenant-id: ${{ secrets.AZURE_TENANT_ID }}
             subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
   

   De taak controleert eerst alle code op de GitHub-runner en meldt zich vervolgens aan bij uw Azure-omgeving.

   Tip

   YAML-bestanden zijn gevoelig voor inspringing. Controleer of de inspringing juist is, ongeacht of u deze code typt of plakt. Verderop in deze oefening ziet u de volledige YAML-werkstroomdefinitie, zodat u kunt controleren of het bestand overeenkomt.

8. Voeg een stap toe om de resourcegroep te maken met de naam die is gedefinieerd in de omgevingsvariabele:

   - uses: Azure/cli@v1
     name: Create resource group
     with:
       inlineScript: |
         az group create \
           --name ${{ env.resourceGroupName }} \
           --location ${{ env.resourceGroupLocation }}
   

9. Voeg na de stap voor het maken van de resourcegroep een stap toe om het Bicep-bestand te implementeren in de resourcegroep:

   - uses: azure/arm-deploy@v1
     id: deploy
     name: Deploy Bicep file
     with:
       failOnStdErr: false
       deploymentName: ${{ github.run_number }}
       resourceGroupName: ${{ env.resourceGroupName }}
       template: ./deploy/main.bicep
       parameters: >
         environmentType=Test
   

10. Voeg na de implementatiestap een stap toe om het tijdelijke websiteadres van de omgeving weer te geven in het werkstroomlogboek:

    - name: Show website hostname
      run: |
        echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"
    

11. Sla uw wijzigingen op.

12. Controleer of uw pr-validation.yml-bestand er als volgt uitziet:

    name: pr-validation
    concurrency: ${{ github.event.number }}
    
    on: pull_request
    
    permissions:
      id-token: write
      contents: read
    
    env:
      resourceGroupName: pr_${{ github.event.number }}
      resourceGroupLocation: westus3
    
    jobs:
      lint:
        uses: ./.github/workflows/lint.yml
    
      deploy:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
          - uses: azure/login@v1
            name: Sign in to Azure
            with:
              client-id: ${{ secrets.AZURE_CLIENT_ID }}
              tenant-id: ${{ secrets.AZURE_TENANT_ID }}
              subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          - uses: Azure/cli@v1
            name: Create resource group
            with:
              inlineScript: |
                az group create \
                  --name ${{ env.resourceGroupName }} \
                  --location ${{ env.resourceGroupLocation }}
          - uses: azure/arm-deploy@v1
            id: deploy
            name: Deploy Bicep file
            with:
              failOnStdErr: false
              deploymentName: ${{ github.run_number }}
              resourceGroupName: ${{ env.resourceGroupName }}
              template: ./deploy/main.bicep
              parameters: >
                environmentType=Test
          - name: Show website hostname
            run: |
              echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"
    

    Als dit niet het probleem is, werkt u deze bij zodat deze overeenkomt met dit voorbeeld en slaat u het op.

13. Voer uw wijzigingen door in de Visual Studio Code-terminal. U pusht ze nog niet naar de externe opslagplaats.

    git add .
    git commit -m "Update pull request validation workflow to deploy an ephemeral environment"
    

Een werkstroom voor het verwijderen van pull-aanvragen toevoegen

U hebt een werkstroom gemaakt waarmee de wijzigingen in elke pull-aanvraag automatisch worden geïmplementeerd in een tijdelijke resourcegroep. Nu configureert u een tweede werkstroom om de tijdelijke omgevingen te verwijderen wanneer ze niet meer nodig zijn.

1. Maak een nieuw bestand met de naam pr-closed.yml in de map .github/workflows.

   

2. Geef bovenaan het bestand de naam van de werkstroom, configureer dezelfde gelijktijdigheidssleutel die u hebt gebruikt in de validatiewerkstroom voor pull-aanvragen, configureer de werkstroom die moet worden uitgevoerd wanneer een pull-aanvraag wordt gesloten en laat de werkstroom een toegangstoken ophalen:

   name: pr-closed
   concurrency: ${{ github.event.number }}
   
   on:
     pull_request:
       types: [closed]
   
   permissions:
     id-token: write
     contents: read
   

3. Definieer onder de code die u zojuist hebt ingevoerd een omgevingsvariabele voor de naam van de resourcegroep die is gekoppeld aan de tijdelijke omgeving van de pull-aanvraag:

   env:
     resourceGroupName: pr_${{ github.event.number }}
   

   De naam van de resourcegroep is hetzelfde als de naam die u hebt gebruikt voor de validatiewerkstroom voor pull-aanvragen.

4. Definieer onder de code die u hebt toegevoegd een nieuwe taak met de naam removeen configureer deze om u aan te melden bij Azure:

   jobs:
     remove:
       runs-on: ubuntu-latest
       steps:
         - uses: azure/login@v1
           name: Sign in to Azure
           with:
             client-id: ${{ secrets.AZURE_CLIENT_ID }}
             tenant-id: ${{ secrets.AZURE_TENANT_ID }}
             subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
   

5. Definieer in de remove taak een stap voor het verwijderen van de resourcegroep met behulp van de Azure CLI en bevestig de verwijdering met behulp van het --yes argument:

   - uses: Azure/cli@v1
     name: Delete resource group
     with:
       inlineScript: |
         az group delete \
           --name ${{ env.resourceGroupName }} \
           --yes
   

6. Sla uw wijzigingen op.

7. Controleer of uw pr-closed.yml-bestand er als volgt uitziet:

   name: pr-closed
   concurrency: ${{ github.event.number }}
   
   on:
     pull_request:
       types: [closed]
   
   permissions:
     id-token: write
     contents: read
   
   env:
     resourceGroupName: pr_${{ github.event.number }}
   
   jobs:
     remove:
       runs-on: ubuntu-latest
       steps:
         - uses: azure/login@v1
           name: Sign in to Azure
           with:
             client-id: ${{ secrets.AZURE_CLIENT_ID }}
             tenant-id: ${{ secrets.AZURE_TENANT_ID }}
             subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
         - uses: Azure/cli@v1
           name: Delete resource group
           with:
             inlineScript: |
               az group delete \
                 --name ${{ env.resourceGroupName }} \
                 --yes
   

   Als dit niet het probleem is, werkt u deze bij zodat deze overeenkomt met dit voorbeeld en slaat u het op.

8. Voer in de Visual Studio Code-terminal uw wijzigingen door en push ze naar de externe opslagplaats:

   git add .
   git commit -m 'Add pull request closed workflow'
   git push
   

Het Bicep-bestand bijwerken

Werk vervolgens uw Bicep-bestand bij om een Docker-containerinstallatiekopieën te gebruiken voor de toepassing van uw website.

1. Maak in de Visual Studio Code-terminal een nieuwe vertakking voor uw wijzigingen door de volgende opdracht uit te voeren:

   git checkout -b feature/container-app
   

2. Open het bestand main.bicep in de implementatiemap .

3. Werk de waarde van de appServiceAppLinuxFrameworkVersion variabele bij:

   var appServiceAppLinuxFrameworkVersion = 'DOCKER|dockersamples/static-site:latest'
   

4. Sla uw wijzigingen op.

5. Voer uw wijzigingen door en push deze naar uw Git-opslagplaats door de volgende opdrachten uit te voeren in de Visual Studio Code-terminal:

   git add .
   git commit -m "Use container image for website"
   git push origin feature/container-app
   

Een pull-aanvraag maken

U hebt werkstromen gedefinieerd voor het automatisch maken en beheren van tijdelijke omgevingen in pull-aanvragen. Nu maakt u nog een pull-aanvraag voor uw Bicep-wijzigingen.

1. Selecteer Code in uw browser en selecteer vervolgens 3 vertakkingen.

   

2. Selecteer onder Uw vertakkingen, naast functie/container-app, nieuwe pull-aanvraag.

   

3. Selecteer Pull-aanvraag maken.

Bekijk hoe de tijdelijke omgeving wordt gemaakt

1. Wacht op de pagina met details van de pull-aanvraag totdat de statuscontrole-items worden weergegeven.

2. Selecteer Details in de lijst naast de implementatietaak.

   

   Wacht tot de implementatie is voltooid.

3. Selecteer Hostnaam website weergeven.

4. Selecteer de URL in het logboek.

   

   De website wordt geladen en geeft een Hello Docker! -bericht weer dat aangeeft dat de website wordt uitgevoerd vanuit de containerinstallatiekopie die is gedefinieerd in de wijziging van de pull-aanvraag.

   

5. Open eventueel Azure Portal en ga naar de resourcegroep van de tijdelijke omgeving.

   Controleer de resources die zijn geïmplementeerd: opslagaccount, App Service en App Service-plan.

De pull-aanvraag samenvoegen

Nu u de pull-aanvraag hebt getest, kunt u deze samenvoegen in de hoofdbranch .

1. Selecteer Pull-aanvragen en selecteer de containerinstallatiekopie gebruiken voor de pull-aanvraag van de website .

   

   De statuscontroles zijn geslaagd.

   

2. Selecteer Pull-aanvraag samenvoegen.

3. Selecteer Samenvoegen bevestigen.

Het verwijderen van de resourcegroep controleren

1. Selecteer acties in de browser en selecteer vervolgens in het linkerdeelvenster de gesloten werkstroom.

   U kunt zien dat de werkstroom automatisch is aangeroepen omdat een pull-aanvraag is gesloten.

   

2. Selecteer de werkstroom om het logboek te controleren.

   Het kan enkele minuten duren voordat de werkstroom de resourcegroep in Azure heeft verwijderd.

   Belangrijk

   U hoeft niet te wachten totdat de werkstroom is voltooid. Maar zorg ervoor dat u de Azure-portal later opent, om te controleren of de resourcegroep van de tijdelijke omgeving is verwijderd en om kosten voor de Azure-resources te voorkomen.

Resources opschonen

Nadat u klaar bent met de module, kunt u de resources verwijderen die u hebt gemaakt:

• GitHub-geheimen

  1. Ga vanuit de GitHub-opslagplaats naar Instellingengeheimen>>en variabelenacties.
  2. Selecteer de knop Verwijderen voor elk opslagplaatsgeheim en volg de aanwijzingen.

• GitHub-opslagplaats

  1. Ga naar Instellingen>algemeen
  2. Schuif naar de onderkant van het scherm, selecteer Deze opslagplaats verwijderen en volg de aanwijzingen.

• Azure-app de federatieve referenties en service-principal van de registratie.

  1. Zoek op de startpagina van de portal naar Microsoft Entra-id en selecteer deze in de lijst met services.
  2. Ga naar Beheren> App-registraties.
  3. In eigendomstoepassingen selecteert u speelgoedwebsite-automatisch controleren.
  4. Selecteer Verwijderen en volg de aanwijzingen.
  5. Selecteer Verwijderde toepassingen om de app-registratie definitief te verwijderen.

  Belangrijk

  Het is mogelijk om dubbele app-registratie- en service-principalnamen te hebben. Het is raadzaam om de toepassings-id te controleren om ervoor te zorgen dat u de juiste resource verwijdert.