Schnellstart: Erstellen eines GitHub-Workflows zum Veröffentlichen einer App

In diesem Schnellstart erfahren Sie, wie Sie einen GitHub-Workflow erstellen, um Ihre .NET-App aus dem Quellcode zu veröffentlichen. Die automatische Veröffentlichung Ihrer .NET-App von GitHub in einem Ziel wird als Continuous Deployment (CD) bezeichnet. Es gibt viele mögliche Ziele zum Veröffentlichen einer Anwendung. In diesem Schnellstart veröffentlichen Sie in Azure.

Voraussetzungen

Hinzufügen eines Veröffentlichungsprofils

Um die App in Azure zu veröffentlichen, öffnen Sie das Azure-Portal für die App Service-Instanz der Anwendung. Wählen Sie in der Übersicht für die Ressource die Option Veröffentlichungsprofil abrufen aus, und speichern Sie die Datei „*.PublishSetting lokal.

Azure Portal, App Service resource: Get publish profile

Warnung

Das Veröffentlichungsprofil enthält vertrauliche Informationen, z. B. Anmeldeinformationen für den Zugriff auf Ihre Azure App Service-Ressource. Diese Informationen sollten immer sehr sorgfältig behandelt werden.

Navigieren Sie im GitHub-Repository zu Einstellungen, und wählen Sie im linken Navigationsmenü Geheimnisse aus. Wählen Sie Neues Repositorygeheimnis aus, um ein neues Geheimnis hinzuzufügen.

GitHub / Settings / Secret: Add new repository secret

Geben Sie AZURE_PUBLISH_PROFILE als Name ein, und fügen Sie den XML-Inhalt aus dem Veröffentlichungsprofil in den Textbereich Wert ein. Klicken Sie auf Add secret (Geheimnis hinzufügen). Weitere Informationen finden Sie unter Verschlüsselte Geheimnisse.

Erstellen einer Workflowdatei

Fügen Sie im GitHub-Repository dem Verzeichnis .github/workflows eine neue YAML-Datei hinzu. Wählen Sie einen aussagekräftigen Dateinamen aus, der deutlich angibt, welche Aufgabe der Workflow ausführen soll. Weitere Informationen finden Sie unter Workflowdatei.

Wichtig

GitHub erfordert, dass Workflowkompositionsdateien im Verzeichnis .github/workflows platziert werden.

Workflowdateien definieren in der Regel eine Komposition aus einem oder mehreren GitHub Actions-Vorgängen über jobs.<job_id>/steps[*]. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Erstellen Sie eine neue Datei namens publish-app.yml, kopieren Sie die folgenden YML-Inhalte, und fügen Sie sie ein:

name: publish

on:
  push:
    branches: [ production ]

env:
  AZURE_WEBAPP_NAME: DotNetWeb
  AZURE_WEBAPP_PACKAGE_PATH: '.' # Set this to the path to your web app project, defaults to the repository root:
  DOTNET_VERSION: '6.0.401' # The .NET SDK version to use

jobs:
  publish:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_VERSION }}

    - name: Install dependencies
      run: dotnet restore
      
    - name: Build
      run: |
        cd DotNet.WebApp
        dotnet build --configuration Release --no-restore
        dotnet publish -c Release -o ../dotnet-webapp -r linux-x64 --self-contained true /p:UseAppHost=true
    - name: Test
      run: |
        cd DotNet.WebApp.Tests
        dotnet test --no-restore --verbosity normal
      
    - uses: azure/webapps-deploy@v2
      name: Deploy
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
        package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/dotnet-webapp'

Für die vorherige Workflowkomposition gilt:

  • name: publish definiert den Namen. „publish“ wird in Workflowstatusbadges angezeigt.

    name: publish
    
  • Der on-Knoten gibt die Ereignisse an, die den Workflow auslösen:

    on:
      push:
        branches: [ production ]
    
    • Wird ausgelöst, wenn ein push-Ereignis im production-Branch auftritt.
  • Der env-Knoten definiert benannte Umgebungsvariablen (env var).

    env:
      AZURE_WEBAPP_NAME: DotNetWeb
      AZURE_WEBAPP_PACKAGE_PATH: '.' # Set this to the path to your web app project, defaults to the repository root:
      DOTNET_VERSION: '6.0.401' # The .NET SDK version to use
    
    • Der Umgebungsvariablen AZURE_WEBAPP_NAME wird der Wert DotNetWeb zugewiesen.
    • Der Umgebungsvariablen AZURE_WEBAPP_PACKAGE_PATH wird der Wert '.' zugewiesen.
    • Der Umgebungsvariablen DOTNET_VERSION wird der Wert '6.0.401' zugewiesen. Auf die Umgebungsvariable wird später verwiesen, um die dotnet-version der GitHub-Aktion actions/setup-dotnet@v3 anzugeben.
  • Der jobs-Knoten erstellt die Schritte, die für den Workflow ausgeführt werden sollen.

    jobs:
      publish:
    
        runs-on: ubuntu-latest
    
        steps:
        - uses: actions/checkout@v3
        - name: Setup .NET Core
          uses: actions/setup-dotnet@v3
          with:
            dotnet-version: ${{ env.DOTNET_VERSION }}
    
        - name: Install dependencies
          run: dotnet restore
          
        - name: Build
          run: |
            cd DotNet.WebApp
            dotnet build --configuration Release --no-restore
            dotnet publish -c Release -o ../dotnet-webapp -r linux-x64 --self-contained true /p:UseAppHost=true
        - name: Test
          run: |
            cd DotNet.WebApp.Tests
            dotnet test --no-restore --verbosity normal
          
        - uses: azure/webapps-deploy@v2
          name: Deploy
          with:
            app-name: ${{ env.AZURE_WEBAPP_NAME }}
            publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
            package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/dotnet-webapp'
    
    • Es gibt einen einzelnen Auftrag namens publish, der unter der neuesten Version von Ubuntu ausgeführt wird.
    • Die GitHub-Aktion actions/setup-dotnet@v3 wird verwendet, um das .NET SDK mit der angegebenen Version aus der Umgebungsvariablen DOTNET_VERSION einzurichten.
    • Der Befehl dotnet restore wird aufgerufen.
    • Der Befehl dotnet build wird aufgerufen.
    • Der Befehl dotnet publish wird aufgerufen.
    • Der Befehl dotnet test wird aufgerufen.
    • Die GitHub-Aktion azure/webapps-deploy@v2 stellt die App mit dem angegebenen publish-profile und package bereit.
      • publish-profile wird aus dem AZURE_PUBLISH_PROFILE-Repositorygeheimnis zugewiesen.

Erstellen eines Badges für den Workflowstatus

Es ist üblich, dass GitHub-Repositorys im Stammverzeichnis des Repositoryverzeichnisses über eine Datei README.md verfügen. Ebenso ist es sinnvoll, den aktuellen Status für verschiedene Workflows zu melden. Alle Workflows können einen Statusbadge generieren, der innerhalb der Datei README.md visuell ansprechend ist. So fügen Sie den Badge für den Workflowstatus hinzu:

  1. Wählen Sie im GitHub-Repository die Navigationsoption Aktionen aus.

  2. Alle Repositoryworkflows werden auf der linken Seite angezeigt. Wählen Sie den gewünschten Workflow und die Schaltfläche mit den Auslassungspunkten (...) aus.

    • Die Schaltfläche mit den Auslassungspunkten (...) erweitert die Menüoptionen für den ausgewählten Workflow.
  3. Wählen Sie die Menüoption Statusbadge erstellen aus.

    GitHub: Create status badge

  4. Wählen Sie die Schaltfläche Statusbadgemarkdown kopieren aus.

    GitHub: Copy status badge Markdown

  5. Fügen Sie das Markdown in die Datei README.md ein, speichern Sie die Datei, und committen und pushen Sie die Änderungen.

Weitere Informationen finden Sie unter Hinzufügen eines Workflowstatusbadges.

Beispiel für das Statusbadge des Veröffentlichungsworkflows

Erfolgreich ist fehlerhaft Kein Status
GitHub: publish passing badge GitHub: publish failing badge GitHub: publish no-status badge

Siehe auch

Nächste Schritte