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

In dieser Schnellstartanleitung erfahren Sie, wie Sie einen GitHub-Workflow erstellen, um Ihre .NET-App aus Quellcode zu veröffentlichen. Die automatische Veröffentlichung Ihrer .NET-App von GitHub an ein Ziel wird als kontinuierliche Bereitstellung (CD) bezeichnet. Es gibt viele mögliche Veröffentlichungsziele für eine Anwendung. In dieser Schnellstartanleitung veröffentlichen Sie Ihre Anwendung in Azure.

Voraussetzungen

• Ein GitHub-Konto.
• Ein .NET-Quellcode-Repository.
• Ein Azure-Konto mit einem aktiven Abonnement. Kostenlos ein Konto erstellen.
• Eine ASP.NET Core Web App.
• Eine Azure App Service-Ressource.

Veröffentlichungsprofil hinzufügen

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 RessourcenübersichtVeröffentlichungsprofil abrufen aus und speichern Sie die .PublishSetting-Datei lokal.

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 " Geheime Schlüssel" im linken Navigationsmenü aus. Wählen Sie "Neuer Repositoryschlüssel" aus, um einen neuen geheimen Schlüssel hinzuzufügen.

Geben Sie AZURE_PUBLISH_PROFILE als Namen ein, und fügen Sie den XML-Inhalt aus dem Veröffentlichungsprofil in den Textbereich "Wert" ein. Wählen Sie "Geheimen Schlüssel hinzufügen" aus. Weitere Informationen finden Sie unter Verschlüsselte geheime Schlüssel.

Erstellen einer Workflowdatei

Fügen Sie im GitHub-Repository eine neue YAML-Datei zum Verzeichnis ".github/workflows " hinzu. Wählen Sie einen aussagekräftigen Dateinamen aus, was eindeutig darauf hinweist, was der Workflow tun soll. Weitere Informationen finden Sie in der Workflowdatei.

Von Bedeutung

GitHub erfordert, dass Workflowkompositionsdateien im Github/Workflows-Verzeichnis platziert werden.

Workflowdateien definieren in der Regel eine Komposition einer oder mehrerer GitHub-Aktionen über die jobs.<job_id>/steps[*]. Weitere Informationen finden Sie unter Workflowsyntax für GitHub-Aktionen.

Erstellen Sie eine neue Datei mit dem Namen publish-app.yml, kopieren Sie den folgenden YML-Inhalt, und fügen Sie ihn 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'

In der vorherigen Workflowkomposition:

• Der name: publish definiert den Namen, "veröffentlichen" wird in Workflow-Statusanzeigen erscheinen.

  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 auf der production Verzweigung erfolgt.

• 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 Umgebungsvariable AZURE_WEBAPP_NAME wird der Wert DotNetWebzugewiesen.
  • Der Umgebungsvariable AZURE_WEBAPP_PACKAGE_PATH wird der Wert '.'zugewiesen.
  • Der Umgebungsvariable DOTNET_VERSION wird der Wert '6.0.401'zugewiesen. Auf die Umgebungsvariable wird später verwiesen, um die dotnet-versionactions/setup-dotnet@v3 GitHub-Aktion anzugeben.

• Der jobs Knoten erstellt die Schritte für den Workflow.

  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 einzigen Auftrag, publish, der auf der neuesten Version von Ubuntu ausgeführt wird.
  • Die actions/setup-dotnet@v3 GitHub-Aktion wird verwendet, um das .NET SDK mit der angegebenen Version aus der DOTNET_VERSION Umgebungsvariable einzurichten.
  • Der dotnet restore Befehl wird aufgerufen.
  • Der dotnet build Befehl wird aufgerufen.
  • Der dotnet publish Befehl wird aufgerufen.
  • Der dotnet test Befehl wird aufgerufen.
  • Die azure/webapps-deploy@v2 GitHub-Action stellt die App mit dem angegebenen publish-profile und package bereit.
    • Der publish-profile Schlüssel wird aus dem AZURE_PUBLISH_PROFILE Repositoryschlüssel zugewiesen.

Erstellen eines Workflowstatusabzeichens

Es ist üblich, dass GitHub-Repositorys über eine README.md Datei im Stammverzeichnis des Repositoryverzeichnisses verfügen. Ebenso ist es schön, den neuesten Status für verschiedene Workflows zu melden. Alle Workflows können ein Statussignal generieren, das in der README.md Datei visuell ansprechend ist. So fügen Sie das Workflow-Status-Abzeichen hinzu:

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

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

   • Die Schaltfläche mit den Auslassungspunkten (...) erweitert die Menüoptionen für den ausgewählten Workflow.

3. Wählen Sie die Menüoption "Statussignal erstellen" aus .

   

4. Wählen Sie die Schaltfläche "Statusabzeichen-Markdown kopieren" aus.

   

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

Weitere Informationen finden Sie unter Hinzufügen eines Workflow-Status-Symbols.

Beispiel für das Veröffentlichen eines Workflowstatussignals

Vorübergehend	Mangels	Kein Status

Siehe auch

• dotnet restore
• dotnet build
• dotnet test
• dotnet publish

Nächste Schritte

Schnellstart: Erstellen eines CodeQL-GitHub-Workflows