DevOps Bootcamp · Lektion

Mit Freigabestufen in die Produktion deployen

Lernen Sie, Builds mithilfe von Umgebungsschutzregeln, manuellen Freigaben und Deployment-Gates in GitHub Actions sicher von Staging in die Produktion zu überführen.

Mit Freigabestufen in die Produktion deployen ist eine kostenlose DevOps Bootcamp-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des DevOps Bootcamp-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.

Warum Production Schutzmechanismen braucht

Continuous Deployment liefert Code automatisch aus, aber das direkte Ausliefern an die Production-Umgebung ohne Kontrollpunkt ist riskant. Eine fehlerhafte Version kann sofort alle Benutzer betreffen.

Ein Freigabe-Gate ist eine bewusst eingerichtete Pause, in der ein Mensch oder eine automatisierte Prüfung bestätigt, dass eine Bereitstellung fortgesetzt werden soll.

Begrenzt die Auswirkungen von Fehlern
Erstellt einen Prüfpfad darüber, wer was genehmigt hat
Ermöglicht die Trennung der Vertrauensstufen von staging und production

GitHub Environments

GitHub Actions bietet eine Funktion namens Environments. Eine Umgebung, etwa production, kann eigene Geheimnisse, Variablen und Schutzregeln enthalten.

Sie verweisen von einem Job aus über den Schlüssel environment auf eine Umgebung. Das bildet die Grundlage für Freigabe-Gates.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: echo 'Deploying to production'

Erforderliche Reviewer

In den Repository-Einstellungen können Sie unter Settings > Environments > production die Option Erforderliche Reviewer aktivieren.

Wenn ein Job auf diese Umgebung zielt, wird der Workflow-Lauf angehalten und wartet, bis einer der aufgelisteten Reviewer auf Approve klickt.

Es können bis zu 6 Reviewer konfiguriert werden
Standardmäßig hebt eine beliebige Genehmigung die Blockierung des Jobs auf
Je nach Einstellungen darf die genehmigende Person nicht die Person sein, die den Lauf ausgelöst hat

Ein vollständiger Workflow mit Freigabe-Gate

Hier wird zuerst ein build-Job ausgeführt. Anschließend hängt ein deploy-Job über needs von ihm ab und zielt auf die geschützte Umgebung production.

Die Bereitstellung startet erst, wenn der erforderliche Reviewer sie in der Actions-Benutzeroberfläche genehmigt.

name: Deploy
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo 'build artifact'
  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://myapp.example.com
    steps:
      - run: echo 'deploy to prod'

Warte-Timer

Neben Reviewern unterstützen Umgebungen auch einen Warte-Timer. Dieser erzwingt eine Verzögerung von bis zu 30 Tagen, bevor eine Bereitstellung fortgesetzt werden kann.

Ein kurzer Warte-Timer eignet sich als Sicherheitswartezeit: Er gibt dem Team Zeit, einen Lauf abzubrechen, bevor er die Production-Umgebung erreicht.

Branch-Einschränkungen für Bereitstellungen

Umgebungen können einschränken, von welchen Branches aus Bereitstellungen zulässig sind. Für production erlauben Sie normalerweise nur main oder Release-Tags.

Dadurch wird verhindert, dass versehentlich von einem Feature-Branch in die Production-Umgebung ausgeliefert wird.

Geschützte Branches – nur Branches mit Schutzregeln
Ausgewählte Branches – eine explizite Allowlist oder ein Tag-Muster

Umgebungsbezogene Geheimnisse

Jede Umgebung verfügt über eigene Geheimnisse. Eine Umgebung production kann PROD_DB_URL enthalten, während staging STAGING_DB_URL enthält.

Auf der Umgebung definierte Geheimnisse sind nur für Jobs verfügbar, die auf diese Umgebung zielen, und schaffen so eine zusätzliche Isolationsebene.

    steps:
      - name: Deploy
        env:
          DB_URL: ${{ secrets.PROD_DB_URL }}
        run: ./deploy.sh

Bereitstellungsstatus verfolgen

Wenn Sie eine url für die Umgebung festlegen, wird der Bereitstellung in der GitHub-Benutzeroberfläche ein anklickbarer Link hinzugefügt und über die Deployments API ein Bereitstellungsobjekt aufgezeichnet.

So erhalten Sie einen sichtbaren Verlauf: welcher Commit wann und von wem in die Production-Umgebung ausgeliefert wurde.

    environment:
      name: production
      url: https://myapp.example.com

Einen ausstehenden Lauf genehmigen

Wenn ein durch ein Gate geschützter Job wartet, sehen Sie auf der Seite des Workflow-Laufs ein gelbes Banner Review deployments.

Öffnen Sie den Lauf im Tab Actions
Klicken Sie auf Review deployments
Wählen Sie die Umgebung aus und klicken Sie auf Approve and deploy oder Reject

Sie können außerdem einen Kommentar hinterlassen, der die Entscheidung erklärt.

Mehrere Gates kombinieren

Das stärkste Gate für die Production-Umgebung kombiniert mehrere Regeln:

Erforderliche Reviewer (menschliche Genehmigung)
Ein Warte-Timer (Sicherheitswartezeit)
Branch-Einschränkungen (nur main)
Umgebungsbezogene Geheimnisse (Isolation)

Durch diese Kombination entsteht ein robuster Prozess zur Beförderung von staging nach production.

Gates sicher umgehen

Manchmal benötigen Sie einen dringenden Hotfix. Anstatt Schutzregeln zu entfernen, sollten Sie einen separaten, eng begrenzten Hotfix-Workflow mit eigener Protokollierung und strengeren Reviewern in Betracht ziehen.

Deaktivieren Sie Gates niemals dauerhaft aus Bequemlichkeit – dadurch wird der Zweck des Sicherheitsmechanismus zunichtegemacht.

Kurzer Test

Testen Sie Ihr Verständnis von Freigabe-Gates für die Production-Umgebung.

Zusammenfassung

Sie haben gelernt, wie Sie mit GitHub Environments Freigabe-Gates für Bereitstellungen in die Production-Umgebung einrichten.

Verwenden Sie den Schlüssel environment, um auf eine geschützte Umgebung zu zielen
Erforderliche Reviewer fügen eine menschliche Genehmigung hinzu
Warte-Timer schaffen eine Sicherheitswartezeit
Branch-Einschränkungen und umgebungsbezogene Geheimnisse sorgen für Isolation

Zusammen machen diese Gates die Beförderung von staging nach production sicher und nachvollziehbar.

Häufig gestellte Fragen

Ist die Lektion „Mit Freigabestufen in die Produktion deployen“ kostenlos?

Ja — der vollständige Text von „Mit Freigabestufen in die Produktion deployen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des DevOps Bootcamp-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der DevOps Bootcamp-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Mit Freigabestufen in die Produktion deployen“?

Lernen Sie, Builds mithilfe von Umgebungsschutzregeln, manuellen Freigaben und Deployment-Gates in GitHub Actions sicher von Staging in die Produktion zu überführen. Du übst DevOps Bootcamp mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um DevOps Bootcamp zu starten?

Keine Vorkenntnisse erforderlich. DevOps Bootcamp auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Mit Freigabestufen in die Produktion deployen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser DevOps Bootcamp-Lektion Code schreiben und ausführen?

Ja. Jede DevOps Bootcamp-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Einführung in Continuous Deployment
In eine Staging-Umgebung deployen
Umgebungsvariablen und Secrets
Mit Freigabestufen in die Produktion deployen

← Zurück zu DevOps Bootcamp