{"meta":{"title":"Implementierung mit GitHub Actions","intro":"GitHub Actions bietet Ihnen eine differenzierte Kontrolle über Bereitstellungen mit Umgebungen, Parallelitätsgruppen und Schutzregeln.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/how-tos","title":"Anleitungen"},{"href":"/de/actions/how-tos/deploy","title":"Bereitstellen"},{"href":"/de/actions/how-tos/deploy/configure-and-manage-deployments","title":"Konfigurieren und Verwalten von Bereitstellungen"},{"href":"/de/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments","title":"Steuern von Bereitstellungen"}],"documentType":"article"},"body":"# Implementierung mit GitHub Actions\n\nGitHub Actions bietet Ihnen eine differenzierte Kontrolle über Bereitstellungen mit Umgebungen, Parallelitätsgruppen und Schutzregeln.\n\n## Voraussetzungen\n\nSie sollten mit der Syntax für GitHub Actions. Weitere Informationen finden Sie unter [Schreiben von Workflows](/de/actions/how-tos/write-workflows).\n\n## Auslösen deiner Bereitstellung\n\nDu kannst deinen Bereitstellungsworkflow mit einer Vielzahl von Ereignissen auslösen. Einige der gängigsten Optionen sind `pull_request`, `push` und `workflow_dispatch`.\n\nBeispielsweise löst ein Workflow unter folgenden Bedingungen Ausführungen aus:\n\n* Es gibt einen Push in den `main`-Branch.\n* Ein Pull Request, der auf den `main`-Branch ausgerichtet ist, wird geöffnet, synchronisiert oder erneut geöffnet.\n* Jemand löst ihn manuell aus.\n\n```yaml\non:\n  push:\n    branches:\n      - main\n  pull_request:\n    branches:\n      - main\n  workflow_dispatch:\n```\n\nWeitere Informationen finden Sie unter [Ereignisse zum Auslösen von Workflows](/de/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n## Verwenden von Umgebungen\n\nUmgebungen werden verwendet, um ein allgemeines Bereitstellungsziel wie `production`, `staging` oder `development` zu beschreiben. Wenn ein GitHub Actions Workflow in einer Umgebung bereitgestellt wird, wird die Umgebung auf der Hauptseite des Repositorys angezeigt. Du kannst Umgebungen verwenden, um für die Fortsetzung von Aufträgen eine Genehmigung zu erzwingen, einzuschränken, welche Branches einen Workflow auslösen können, Bereitstellungen mit benutzerdefinierten Bereitstellungsschutzregeln zu schützen oder den Zugriff auf Geheimnisse zu beschränken. Weitere Informationen zum Erstellen von Umgebungen findest du unter [Verwalten von Umgebungen für die Bereitstellung](/de/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).\n\nDu kannst Umgebungen mit Schutzregeln und Geheimnissen konfigurieren. Wenn ein Workflowauftrag auf eine Umgebung verweist, wird der Auftrag erst dann gestartet, wenn alle Schutzregeln der Umgebung erfüllt sind. Ein Job kann außerdem erst dann auf Geheimnisse zugreifen, die in einer Umgebung definiert sind, wenn alle Regeln zum Schutz der Bereitstellung erfüllt sind. Weitere Informationen findest du in diesem Artikel unter [Verwenden von benutzerdefinierten Bereitstellungsschutzregeln](#using-custom-deployment-protection-rules).\n\n## Verwenden von Parallelität\n\nParallelität stellt sicher, dass jeweils nur ein einziger Auftrag oder Workflow mit derselben Parallelitätsgruppe ausgeführt wird. Sie können Parallelität nutzen, um sicherzustellen, dass in einer Umgebung maximal eine Bereitstellung gleichzeitig in Bearbeitung. Weitere Informationen über Parallelität finden Sie unter [Steuern der Gleichzeitigkeit von Workflows und Aufträgen](/de/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency).\n\n## Verwenden von Umgebungen ohne Bereitstellungen\n\nWenn ein Workflowauftrag auf eine Umgebung verweist, wird standardmäßig ein Bereitstellungsobjekt erstellt, GitHub um die Bereitstellung nachzuverfolgen. Sie können sich von der Bereitstellungserstellung abmelden, indem Sie `deployment` auf `false` in der Umgebungskonfiguration festlegen. Die gültigen Werte sind `true` (Standard) und `false`. Sie können auch einen Ausdruck verwenden, z. B `deployment: ${{ github.ref_name == 'main' }}`. .\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    environment:\n      name: staging\n      deployment: false\n    steps:\n      - name: run tests\n        env:\n          API_KEY: ${{ secrets.API_KEY }}\n        run: echo \"Running tests with staging secrets\"\n```\n\nWenn `deployment` auf `false` gesetzt ist:\n\n* Der Job hat vollen Zugriff auf Umgebungsgeheimnisse und Variablen.\n* Es wird kein GitHub Bereitstellungsobjekt erstellt– der Bereitstellungsverlauf für die Umgebung wird nicht aktualisiert.\n* Die Regeln zum Schutz der Wartezeit gelten nach wie vor - der Job wartet für die konfigurierte Dauer.\n* Erforderliche Prüfer bleiben bestehen - die Prüfer müssen weiterhin genehmigen, bevor der Job ausgeführt wird.\n\nDies ist nützlich, wenn Sie Umgebungen für Folgendes verwenden möchten:\n\n* **Organisieren von Geheimnissen – gruppieren** verwandter Geheimnisse unter einem Umgebungsnamen, ohne dass Bereitstellungsdatensätze erstellt werden.\n* **Zugriffssteuerung** – Schränken Sie ein, welche Branches bestimmte Secrets über Umgebungs-Zweigrichtlinien verwenden können, ohne die Bereitstellung nachzuverfolgen.\n* **CI- und Test-Jobs**-referenzieren eine Umgebung für ihre Konfiguration, ohne die Historie für die Bereitstellung zu stören.\n\n### Interaktion mit Schutzregeln\n\nDie `deployment` Eigenschaft steuert, welche Schutzregeln gelten:\n\n\\| Schutzregel |\n`deployment: true` (Standardwert) | `deployment: false` |\n\\|----------------|------------------------------|---------------------|\n\\| **None** | Bereitstellung erstellt, Job läuft | Keine Bereitstellung, Job wird ausgeführt |\n\\| **Wartezeitzeitgeber** | Wartetimer wird aktiviert | Wartetimer wird weiterhin angewendet |\n\\| **Erforderliche Prüfer** | Prüfer müssen genehmigen | Prüfer müssen genehmigen |\n\\| **Angepasste Regel zum Schutz der Bereitstellung App** | Der gesendete Webhook der App muss genehmigt werden. |\n**Job schlägt mit Fehler fehl** |\n\nBenutzerdefinierte Bereitstellungsschutzregeln (GitHub Apps) erfordern eine Funktion des Bereitstellungsobjekts. Wenn Sie für eine Umgebung mit benutzerdefinierten Bereitstellungsschutzregeln festlegen `deployment: false` , schlägt der Auftrag sofort mit einer Anmerkung oder Fehlermeldung fehl, in der erläutert wird, dass die Schutzregeln der Umgebung mit `deployment: false`nicht kompatibel sind. Entfernen Sie `deployment: false` entweder aus Ihrem Workflow, oder entfernen Sie die benutzerdefinierten Bereitstellungsschutzregeln aus der Umgebung.\n\nBeachten Sie, dass `concurrency` und `environment` nicht verbunden sind. Der Parallelitätswert kann eine beliebige Zeichenfolge sein.Er muss kein Umgebungsname sein. Wenn ein anderer Workflow die gleiche Umgebung verwendet, aber keine Parallelität angibt, unterliegt dieser Workflow keinen Parallelitätsregeln.\n\nWenn beispielsweise der folgende Workflow ausgeführt wird, wird er mit dem Status `pending` angehalten, wenn ein Auftrag oder Workflow, der die Parallelitätsgruppe `production` verwendet, aktiv ist. Außerdem werden alle Aufträge oder Workflows abgebrochen, die die Parallelitätsgruppe `production` verwenden und den Status `pending` haben. Das bedeutet, dass es maximal einen aktiven und einen ausstehenden Auftrag oder Workflow gibt, der die Parallelitätsgruppe `production` verwendet.\n\n```yaml\nname: Deployment\n\nconcurrency: production\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nDu kannst Parallelität auch auf Auftragsebene angeben. Dadurch können andere Aufträge im Workflow fortgesetzt werden, auch wenn der parallele Auftrag `pending` ist.\n\n```yaml\nname: Deployment\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    concurrency: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nDu kannst auch mit `cancel-in-progress` alle derzeit ausgeführten Aufträge oder Workflows in derselben Parallelitätsgruppe abbrechen.\n\n```yaml\nname: Deployment\n\nconcurrency:\n  group: production\n  cancel-in-progress: true\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nEine Anleitung zum Schreiben von bereitstellungsspezifischen Schritten finden Sie unter [Beispiele für die Bereitstellung finden](#finding-deployment-examples).\n\n## Anzeigen des Bereitstellungsverlaufs\n\nWenn ein GitHub Actions Workflow in einer Umgebung bereitgestellt wird, wird die Umgebung auf der Hauptseite des Repositorys angezeigt. Weitere Informationen zum Anzeigen von Bereitstellungen in Umgebungen finden Sie unter [Anzeigen des Bereitstellungsverlaufs](/de/actions/how-tos/deploy/configure-and-manage-deployments/view-deployment-history).\n\nIhre Organisation kann Bereitstellungsdatensätze für alle Ihre Builds an einem zentralen Ort sammeln, indem Sie Daten in die linked artifacts page-Datei hochladen. Weitere Informationen findest du unter [Informationen zu verknüpften Artefakten](/de/code-security/concepts/supply-chain-security/linked-artifacts).\n\n## Überwachen von Workflowausführungen\n\nJede Workflowausführung generiert ein Echtzeitdiagramm, das den Ausführungsfortschritt veranschaulicht. Du kannst dieses Diagramm verwenden, um Bereitstellungen zu überwachen und zu debuggen. Weitere Informationen findest du unter [Verwenden des Visualisierungsdiagramms](/de/actions/how-tos/monitor-workflows/use-the-visualization-graph).\n\nDu kannst auch die Protokolle jeder Workflowausführung und den Verlauf von Workflowausführungen anzeigen. Weitere Informationen finden Sie unter [Anzeigen des Ausführungsverlaufs eines Workflows](/de/actions/how-tos/monitor-workflows/view-workflow-run-history).\n\n## Verwenden von erforderlichen Überprüfungen in Workflows\n\nAufträge, die auf eine Umgebung verweisen, die mit erforderlichen Reviewern konfiguriert wurde, warten auf eine Genehmigung, bevor sie gestartet werden. Während ein Auftrag auf die Genehmigung wartet, hat er den Status „Warten“. Wenn ein Auftrag nicht innerhalb von 30 Tagen genehmigt wird, schlägt er automatisch fehl.\n\nWeitere Informationen über Umgebungen und erforderliche Genehmigungen finden Sie unter [Verwalten von Umgebungen für die Bereitstellung](/de/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments). Weitere Informationen zum Überprüfen von Bereitstellungen mit der REST-API findest du unter [REST-API-Endpunkte für Workflowausführungen](/de/rest/actions/workflow-runs).\n\n## Verwenden von benutzerdefinierten Regeln für den Bereitstellungsschutz\n\n> \\[!NOTE]\n> Benutzerdefinierte Regeln für den Bereitstellungsschutz befinden sich derzeit in der Öffentliche Vorschau. Änderungen sind vorbehalten.\n\nDu kannst deine eigenen benutzerdefinierten Regeln für den Bereitstellungsschutz aktivieren, um Bereitstellungen mit Drittanbieterdiensten zu schützen. Sie können z. B. Dienste wie Datadog, Honeycomb und ServiceNow verwenden, um automatisierte Genehmigungen für Bereitstellungen in GitHub zu ermöglichen.\n\nBenutzerdefinierte Bereitstellungsschutzregeln werden von GitHub Apps angetrieben und basieren auf Webhooks und Rückrufen. Die Genehmigung oder Ablehnung eines Workflowauftrags basiert auf der Nutzung des `deployment_protection_rule`-Webhooks. Weitere Informationen findest du unter [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#deployment_protection_rule) und [Genehmigen oder Ablehnen von Bereitstellungen](/de/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules#approving-or-rejecting-deployments).\n\nNachdem du eine benutzerdefinierte Bereitstellungsschutzregel erstellt und in deinem Repository installiert hast, ist diese Regel automatisch für alle Umgebungen im Repository verfügbar.\n\nBereitstellungen in einer Umgebung können basierend auf den in jedem externen Dienst definierten Bedingungen genehmigt oder abgelehnt werden, z. B. basierend auf genehmigten Tickets in einem ITSM-System (IT-Service-Management), Ergebnissen von Überprüfungen auf Sicherheitsrisiken bei Abhängigkeiten oder Integritätsmetriken einer Cloudressource. Die Entscheidung, Bereitstellungen zu genehmigen oder abzulehnen, liegt im Ermessen der integrierenden Drittanbieteranwendung und der darin definierten Schutzbedingungen. Im Folgenden findest du einige Anwendungsfälle, für die du eine Regel für den Bereitstellungsschutz erstellen kannst.\n\n* ITSM & Security Operations: Sie können die Readiness von Diensten überprüfen, indem Sie Qualitäts-, Sicherheits- und Compliance-Prozesse validieren, die die Bereitstellungsbereitschaft verifizieren.\n* Einblicksysteme: Du kannst Überwachungs- oder Einblicksysteme (Systeme zur Verwaltung der Ressourcenleistung und Protokollierungsaggregatoren, Systeme zur Überprüfung der Cloudressourcenintegrität usw.) konsultieren, um die Sicherheits- und Bereitstellungsbereitschaft zu überprüfen.\n* Code Quality Tools & Testen: Sie können automatisierte Tests für CI-Builds überprüfen, die in einer Umgebung bereitgestellt werden müssen.\n\nAlternativ dazu kannst du eigene Schutzregeln für jeden der oben genannten Anwendungsfälle schreiben oder benutzerdefinierte Logik definieren, um Bereitstellungen aus Vorproduktionsumgebungen in Produktionsumgebungen sicher zu genehmigen oder abzulehnen.\n\n## Nachverfolgen von Bereitstellungen über Apps\n\nWenn Ihr persönliches Konto oder Ihre Organisation auf GitHub in Microsoft Teams oder Slack integriert ist, können Sie Bereitstellungen nachverfolgen, die Umgebungen über Microsoft Teams oder Slack verwenden. Du kannst beispielsweise Benachrichtigungen über die App erhalten, wenn für eine Bereitstellung eine Genehmigung aussteht, wenn eine Bereitstellung genehmigt wird oder wenn sich der Bereitstellungsstatus ändert. Weitere Informationen zum Integrieren von Microsoft Teams oder Slack finden Sie unter [Empfohlene GitHub Integrationen](/de/integrations/concepts/featured-github-integrations#team-communication-tools).\n\nDu kannst auch eine App erstellen, die Bereitstellungs- und Bereitstellungsstatuswebhooks verwendet, um Bereitstellungen nachzuverfolgen.\nWenn ein Workflowauftrag, der auf eine Umgebung verweist, erstellt er ein Bereitstellungsobjekt mit der Eigenschaft `environment`, die auf den Namen Deiner Umgebung festgelegt ist. Im Verlauf des Workflows werden außerdem Bereitstellungsstatusobjekte erstellt, deren Eigenschaft `environment` auf den Namen Deiner Umgebung, deren Eigenschaft `environment_url` auf die URL der Umgebung (falls im Workflow angegeben) und deren Eigenschaft `state` auf den Status des Auftrags gesetzt ist. Weitere Informationen finden Sie unter [GitHub-App-Dokumentation](/de/apps) und [Webhook-Ereignisse und Webhook-Nutzlasten](/de/webhooks/webhook-events-and-payloads#deployment).\n\n## Die Auswahl eines Runners\n\nSie können Ihren Workflow entweder auf GitHub-gehosteten Runners oder auf selbstgehosteten Runners ausführen. Der Datenverkehr von GitHub-gehosteten Runnern kann aus einem [breiten Spektrum von Netzwerkadressen](/de/rest/meta/meta#get-github-meta-information) stammen. Wenn Sie in einer internen Umgebung bereitstellen und Ihr Unternehmen den externen Datenverkehr in private Netzwerke einschränkt, können GitHub Actions Workflows, die auf GitHub-gehosteten Runnern ausgeführt werden, möglicherweise nicht mit Ihren internen Diensten oder Ressourcen kommunizieren. Um dies zu vermeiden, kannst du deine eigenen Runner hosten. Weitere Informationen findest du unter [Selbstgehosteten Runnern](/de/actions/concepts/runners/self-hosted-runners) und [Von GitHub gehostete Runner](/de/actions/concepts/runners/github-hosted-runners).\n\n## Anzeigen eines Statusbadges\n\nDu kannst ein Statusbadge verwenden, um den Status deines Bereitstellungsworkflows anzuzeigen. Ein Statusbadge zeigt an, ob ein Workflow derzeit fehlerhaft oder korrekt ausgeführt wird. Ein gängiger Ort für ein Statusbadge ist die Datei `README.md` deines Repositorys, du kannst den Badge aber zu jeder beliebigen Webseite hinzufügen. Standardmäßig zeigen Badges den Status deines Standardbranchs an. Wenn in Ihrem Standardbranch kein Workflow ausgeführt wird, wird der Status der letzten Ausführung über alle Branches hinweg angezeigt. Sie können den Status einer Workflowausführung für einen bestimmten Branch oder ein bestimmtes Ereignis anzeigen, indem Sie die Abfrageparameter `branch` und `event` in der URL verwenden.\n\n![Screenshot eines Workflowstatus-Badges In der Reihenfolge von rechts nach links wird angezeigt: das GitHub-Logo, der Workflowname („GitHub Actions Demo“) und der Status („passing“).](/assets/images/help/repository/actions-workflow-status-badge.png)\n\nWeitere Informationen finden Sie unter [Hinzufügen eines Badges für den Workflowstatus](/de/actions/how-tos/monitor-workflows/add-a-status-badge).\n\n## Suchen nach Bereitstellungsbeispielen\n\nIn diesem Artikel wurden die Features von GitHub Actions demonstriert, die Sie zu Ihren Bereitstellungs-Workflows hinzufügen können.\n\nGitHubbietet Bereitstellungsworkflowvorlagen für mehrere beliebte Dienste, z. B. Azure Web App. Informationen zu den ersten Schritten mit einer Workflowvorlage findest du unter [Verwenden von Workflowvorlagen](/de/actions/how-tos/write-workflows/use-workflow-templates). Alternativ kannst du die [vollständige Liste der Bereitstellungs-Workflowvorlagen durchsuchen](https://github.com/actions/starter-workflows/tree/main/deployments). Du kannst dir auch unsere ausführlicheren Leitfäden für bestimmte Bereitstellungsworkflows ansehen, wie zum Beispiel [Bereitstellen von Node.js für Azure App Service](/de/actions/how-tos/deploy/deploy-to-third-party-platforms/nodejs-to-azure-app-service).\n\nViele Anbieter bieten auch Aktionen auf GitHub Marketplace zur Bereitstellung in ihrem Dienst an. Die vollständige Liste finden Sie unter [GitHub Marketplace](https://github.com/marketplace?category=deployment\\&type=actions)."}