Übung: Erstellen kurzlebiger Umgebungen für Pull Requests

Abgeschlossen

Einige Teammitglieder haben Ihnen mitgeteilt, dass sie das automatische Bicep-Linter-Feedback zu ihren Codeänderungen zu schätzen wissen, bevor sie diese an andere Teammitglieder zur Überprüfung weiterleiten. Jetzt haben Sie beschlossen, Ihren Mitwirkenden und Prüfern die Möglichkeit zu geben, ihren Code in einer kurzlebigen Umgebung bereitzustellen und zu prüfen.

In dieser Übung werden Sie Ihren Pull Request-Workflow aktualisieren, um eine kurzlebige Umgebung bereitzustellen, sobald ein Pull Request geöffnet wird, und sie erneut bereitzustellen, wenn Code in den Pull Request-Branch gepusht wird. Sie erstellen auch einen weiteren Workflow zum automatischen Löschen der Umgebung, wenn der Pull Request geschlossen wird. Sie testen Ihre Änderungen, indem Sie einen Pull Request für Ihre Website erstellen, um ein Docker-Containerimage zu verwenden.

In dem Prozess gehen Sie wie folgt vor:

  • Aktualisieren Sie den Pull Request-Workflow, um eine kurzlebige Umgebung bereitzustellen.
  • Erstellen Sie einen Workflow zum Löschen von Pull Requests, um die kurzlebige Umgebung zu löschen.
  • Erstellen Sie einen Pull Request und beobachten Sie, wie die kurzlebige Umgebung erstellt wird.
  • Genehmigen Sie den Pull Request, und beobachten Sie, wie die kurzlebige Umgebung gelöscht wird.

Aktualisieren des Pull Request-Workflows zum Bereitstellen einer kurzlebigen Umgebung

Zunächst müssen Sie Ihren pr-validation-Workflow aktualisieren, um eine kurzlebige Umgebung zu erstellen.

  1. Schauen Sie sich im Visual Studio Code-Terminal den Mainbranch des Repositorys an.

    git checkout main
    
  2. Pullen Sie die neueste Version des Codes von GitHub, die die Änderungen enthält, die Sie in einer vorherigen Übung gemergt haben.

    git pull
    
  3. Öffnen Sie die Datei .github/workflows/pr-validation.yml in Visual Studio Code.

  4. Fügen Sie am oberen Rand der Datei unter der Einstellung name eine concurrency-Einstellung hinzu:

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

    Diese Einstellung verhindert, dass mehrere Workflows für denselben Pull Request gleichzeitig ausgeführt werden, was zu unvorhersehbaren Ergebnissen bei der Bereitstellung von Ressourcen in Azure führen kann.

  5. Definieren Sie am oberen Rand der Datei unter dem Abschnitt on, in dem der Trigger definiert wird, den Abschnitt permissions:

    name: pr-validation
    concurrency: ${{ github.event.number }}
    
    on: pull_request
    
    permissions:
      id-token: write
      contents: read
    
  6. Fügen Sie unterhalb des Abschnitts permissions zwei neue Umgebungsvariablen hinzu:

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

    Die Umgebungsvariable resourceGroupName gibt den Namen der Ressourcengruppe an, die für jede kurzlebige Umgebung verwendet werden soll. Jede Ressourcengruppe erhält den Namen pr_123, wobei 123 die eindeutige Nummer des Pull Requests ist.

    Die Umgebungsvariable resourceGroupLocation gibt an, dass Ihre kurzlebigen Umgebungen alle in der Azure-Region „USA, Westen 3“ bereitgestellt werden sollen.

  7. Definieren Sie einen neuen Auftrag mit dem Namen deploy, unterhalb des Auftrags lint:

    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 }}
    

    Der Auftrag checkt zunächst den gesamten Code auf den GitHub-Runner aus und meldet sich dann bei Ihrer Azure-Umgebung an.

    Tipp

    YAML-Dateien berücksichtigen Einzüge. Unabhängig davon, ob Sie diesen Code eingeben oder einfügen, stellen Sie sicher, dass der Einzug korrekt ist. Später in dieser Übung sehen Sie die vollständige YAML-Workflowdefinition, sodass Sie überprüfen können, ob Ihre Datei übereinstimmt.

  8. Fügen Sie einen Schritt hinzu, um die Ressourcengruppe mit dem in der Umgebungsvariablen definierten Namen zu erstellen:

    - uses: Azure/cli@v1
      name: Create resource group
      with:
        inlineScript: |
          az group create \
            --name ${{ env.resourceGroupName }} \
            --location ${{ env.resourceGroupLocation }}
    
  9. Fügen Sie nach dem Schritt zur Erstellung der Ressourcengruppe einen Schritt zur Bereitstellung der Bicep-Datei für die Ressourcengruppe hinzu:

    - 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. Fügen Sie nach dem Schritt der Bereitstellung einen Schritt hinzu, um die Adresse der Website der kurzlebigen Umgebung im Workflowprotokoll anzuzeigen:

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

  12. Überprüfen Sie, ob die Datei pr-validation.yml wie folgt aussieht:

    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 }}"
    

    Falls nicht, aktualisieren Sie sie entsprechend diesem Beispiel und speichern sie.

  13. Committen Sie Ihre Änderungen im Visual Studio Code-Terminal. Sie werden sie noch nicht in das Remoterepository pushen.

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

Hinzufügen eines Workflows zum Löschen von Pull Requests

Sie haben einen Workflow erstellt, der die Änderungen in jedem Pull Request automatisch in einer kurzlebigen Ressourcengruppe bereitstellt. Jetzt konfigurieren Sie einen zweiten Workflow, um die kurzlebigen Umgebungen zu löschen, wenn sie nicht mehr benötigt werden.

  1. Erstellen Sie eine neue Datei namens pr-closed.yml im Ordner .github/workflows.

    Screenshot von Visual Studio Code: Datei „pr-closed.yml“ im Ordner „Workflows“

  2. Benennen Sie den Workflow am Anfang der Datei, konfigurieren Sie denselben Parallelitätsschlüssel, den Sie im Workflow zur Überprüfung von Pull Requests verwendet haben, konfigurieren Sie den Workflow so, dass er ausgeführt wird, sobald ein Pull Request geschlossen wird, und gestatten Sie dem Workflow das Abrufen eines Zugriffstokens:

    name: pr-closed
    concurrency: ${{ github.event.number }}
    
    on:
      pull_request:
        types: [closed]
    
    permissions:
      id-token: write
      contents: read
    
  3. Definieren Sie unterhalb des Codes, den Sie gerade eingegeben haben, eine Umgebungsvariable für den Namen der Ressourcengruppe, die der kurzlebigen Umgebung des Pull Requests zugeordnet ist:

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

    Der Name der Ressourcengruppe ist derselbe wie der, den Sie für den Workflow zur Überprüfung des Pull Requests verwendet haben.

  4. Definieren Sie unterhalb des hinzugefügten Codes einen neuen Auftrag mit dem Namen remove, und konfigurieren Sie ihn für die Anmeldung bei 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. Definieren Sie innerhalb des Auftrags remove einen Schritt zum Löschen der Ressourcengruppe mithilfe der Azure CLI, und bestätigen Sie die Löschung mithilfe des Arguments --yes:

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

  7. Überprüfen Sie, ob die Datei pr-closed.yml wie folgt aussieht:

    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
    

    Falls nicht, aktualisieren Sie sie entsprechend diesem Beispiel und speichern sie.

  8. Committen Sie Ihre Änderungen im Visual Studio Code-Terminal, und pushen Sie sie in das Remoterepository:

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

Update der Bicep-Datei

Aktualisieren Sie nun Ihre Bicep-Datei, um ein Docker-Containerimage für die Anwendung Ihrer Website zu verwenden.

  1. Führen Sie im Visual Studio Code-Terminal den folgenden Befehl aus, um einen neuen Branch für Ihre Änderungen zu erstellen:

    git checkout -b feature/container-app
    
  2. Öffnen Sie die Datei main.bicep im Ordner deploy.

  3. Aktualisieren Sie den Wert der Variablen appServiceAppLinuxFrameworkVersion:

    var appServiceAppLinuxFrameworkVersion = 'DOCKER|dockersamples/static-site:latest'
    
  4. Speichern Sie die Änderungen.

  5. Committen und pushen Sie Ihre Änderungen in Ihr Git-Repository, indem Sie die folgenden Befehle im Visual Studio Code-Terminal ausführen:

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

Erstellen eines Pull Request

Sie haben Workflows definiert, um kurzlebige Umgebungen in Pull Requests automatisch zu erstellen und zu verwalten. Nun erstellen Sie einen weiteren Pull Request für Ihre Bicep-Änderungen.

  1. Wählen Sie in Ihrem Browser Code aus, und wählen Sie dann 3 Branches aus.

    Screenshot von GitHub: Branchliste des Repositorys

  2. Wählen Sie unter Ihre Branches neben feature/container-app die Option Neuer Pull Request aus.

    Screenshot von GitHub: Link zum Erstellen eines Pull Requests für den Feature-/Container-App-Branch

  3. Klicken Sie auf Pull Request erstellen.

Beobachten Sie, wie die kurzlebige Umgebung erstellt wird.

  1. Warten Sie auf der Detailseite des Pull Requests, bis die Statusünerprüfungselemente angezeigt werden.

  2. Wählen Sie in der Liste neben dem Bereitstellungsauftrag die Option Details aus.

    Screenshot: GitHub-Pull Request mit Elementen der Statusüberprüfung. Der Link „Details“ für den Auftrag „Bereitstellen“ ist hervorgehoben.

    Warten Sie, bis die Bereitstellung abgeschlossen ist.

  3. Wählen Sie Websitehostnamen anzeigen aus.

  4. Wählen Sie die URL im Protokoll aus.

    Screenshot des GitHub Actions-Bereitstellungsprotokolls. Die Website-URL im Schritt „Websitehostnamen anzeigen“ ist hervorgehoben.

    Die Website wird geladen und die Meldung Hello Docker! angezeigt, die besagt, dass die Website im in der Pull Request-Änderung angegebenen Containerimage ausgeführt wird.

    Screenshot: Websitehomepage nach Abschluss der Bereitstellung

  5. Öffnen Sie optional das Azure-Portal, und navigieren Sie zur Ressourcengruppe der kurzlebigen Umgebung.

    Überprüfen Sie die bereitgestellten Ressourcen: Speicherkonto, App Service-Instanz und App Service-Plan.

Zusammenführen des Pull Requests

Nachdem Sie den Pull Request getestet haben, können Sie ihn mit dem Branch Main zusammenführen.

  1. Wählen Sie Pull Requests und dann den Pull Request Containerimage für Website verwenden aus.

    Screenshot von GitHub: Liste offener Pull Requests im Repository

    Die Statusprüfungen wurden bestanden.

    Screenshot: GitHub-Pull Request mit zwei erfolgreich durchgeführten Statusüberprüfungen

  2. Wählen Sie Pull Request zusammenführen aus.

  3. Wählen Sie Merge bestätigen aus.

Überprüfen des Löschens der Ressourcengruppe

  1. Wählen Sie im Browser Aktionen aus, und wählen Sie dann im linken Bereich den pr-closed-Workflow aus.

    Sie können erkennen, dass der Workflow automatisch aufgerufen wurde, da ein Pull Request geschlossen wurde.

    Screenshot: GitHub Actions-Bereich mit Anzeige der Ausführung des pr-closed-Workflows

  2. Wählen Sie den Workflow zur Überprüfung des Protokolls aus.

    Es kann ein paar Minuten dauern, bis der Workflow das Löschen der Ressourcengruppe in Azure beendet hat.

    Wichtig

    Sie müssen nicht warten, bis die Workflowausführung abgeschlossen ist. Denken Sie jedoch daran, später das Azure-Portal zu öffnen, um zu überprüfen, ob die Ressourcengruppe der kurzlebigen Umgebung erfolgreich gelöscht wurde und um zu vermeiden, dass Ihnen Kosten für die Azure-Ressourcen entstehen.

Bereinigen von Ressourcen

Sobald Sie mit dem Modul fertig sind, können Sie die von Ihnen erstellten Ressourcen löschen:

  • GitHub-Geheimnisse

    1. Wechseln Sie im GitHub-Repository zu Einstellungen>Geheimnisse und Variablen>Aktionen.
    2. Wählen Sie die Schaltfläche "Löschen " für jeden geheimen Repositoryschlüssel aus, und folgen Sie den Eingabeaufforderungen.
  • GitHub-Repository

    1. Wechseln Sie zu Einstellungen>Allgemein.
    2. Scrollen Sie zum unteren Rand des Bildschirms, wählen Sie "Dieses Repositorylöschen" aus, und folgen Sie den Anweisungen.
  • Verbundanmeldeinformationen und Dienstprinzipal der Azure-App-Registrierung.

    1. Suchen Sie auf der Startseite des Portals nach Microsoft Entra-ID, und wählen Sie sie aus der Liste der Dienste aus.
    2. Wechseln Sie zu Verwalten>App-Registrierungen.
    3. Wählen Sie unter Anwendungen mit Besitzerdie Option toy-website-auto-review aus.
    4. Wählen Sie Löschen aus, und befolgen Sie die Anweisungen.
    5. Wählen Sie Gelöschte Anwendungen aus, um die App-Registrierung endgültig zu löschen.

    Wichtig

    Doppelte App-Registrierungen und Dienstprinzipalnamen sind möglich. Es wird empfohlen, die ID der Anwendung zu überprüfen, um sicherzustellen, dass Sie die richtige Ressource löschen.