Continuous Deployment in der Staging-Umgebung

Einführung

Continuous Deployment (CD) bezeichnet die Phase, in der geprüfte Software in eine Umgebung bereitgestellt wird, in der sie ausgeführt werden kann.

Stellen Sie sich wieder unsere Softwarefabrik vor:

CI: Der Roboter prüft die Software auf Fehler.
Artefakt: Der Roboter verpackt das Produkt in eine Box.
CD: Der Lieferwagen bringt die Box zum Geschäft (Server), damit die Kunden sie verwenden können.

In der Praxis bedeutet die Bereitstellung häufig, laufende Systeme über SSH, APIs oder plattformspezifische Release-Mechanismen zu aktualisieren. In diesem Lab simulieren Sie diesen Prozess. Die wichtigste Erkenntnis ist jedoch der Bereitstellungsablauf – vom getesteten Code bis zur laufenden Umgebung.

Das ist der wesentliche Unterschied zwischen CI und CD. CI bestätigt, dass Änderungen stabil genug für eine Auslieferung sind. CD übernimmt die kontrollierte Übertragung dieser geprüften Änderungen in eine Umgebung.

In diesem Lab werden Sie:

das Konzept manueller Trigger (Bereitstellung per Klick) kennenlernen;
einen Bereitstellungs-Workflow schreiben, der den realen Prozess simuliert;
Ihren „Lieferwagen“ (CD) mit Ihrer „Qualitätskontrolle“ (CI) verbinden.

Voraussetzungen

Wir verwenden weiterhin das Repository github-actions-basics.

Manuelle Bereitstellung erstellen

Manchmal möchten Sie nicht jedes Mal eine Bereitstellung ausführen, wenn Sie Code pushen. Vielleicht möchten Sie erst eine Genehmigung abwarten oder nur dann bereitstellen, wenn Sie dazu bereit sind.

Deshalb sind manuelle Trigger und Staging-Umgebungen so verbreitet. Bereitstellungspipelines müssen häufig zwischen Geschwindigkeit und betrieblicher Vorsicht abwägen, anstatt jeden erfolgreichen Build sofort in die Produktion zu übertragen.

Mit GitHub Actions können Sie Workflows erstellen, die nur ausgeführt werden, wenn Sie eine Schaltfläche anklicken. Dazu verwenden Sie den Trigger workflow_dispatch.

Wechseln Sie in das Workflow-Verzeichnis Ihres Projekts.

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

Hinweis: Ersetzen Sie your-username durch Ihren tatsächlichen GitHub-Benutzernamen.

Erstellen Sie eine neue Datei mit dem Namen deploy.yml.

touch .github/workflows/deploy.yml

Öffnen Sie die Datei mit nano.

nano .github/workflows/deploy.yml

Fügen Sie den folgenden Inhalt ein:

name: Deploy to Production

on: workflow_dispatch

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploying
        run: echo "Starting deployment..."

Sehen Sie on: workflow_dispatch? Das ist die magische Schaltfläche.

Speichern und schließen Sie nano. Pushen Sie anschließend diese Datei zu GitHub.

git add .
git commit -m "Add manual deployment workflow"
git push

Öffnen Sie nun auf GitHub den Tab Actions.

Klicken Sie in der linken Seitenleiste auf Deploy to Production.
Sie sehen ein blaues Banner mit dem Text „This workflow has a dispatch event trigger.“
Klicken Sie auf die Schaltfläche Run workflow und anschließend im Dropdown-Menü auf die grüne Schaltfläche Run workflow.

Run workflow

Sie haben gerade eine Bereitstellungspipeline manuell ausgelöst!

Bereitstellungsschritte simulieren

Reale Bereitstellungsskripte können komplex sein. Meist folgen sie jedoch einem einfachen Muster:

Mit dem Server verbinden.
Die neue Softwareversion abrufen.
Die Anwendung neu starten.

Auch wenn sich die technischen Details unterscheiden, folgen die meisten Bereitstellungspipelines weiterhin diesem allgemeinen Ablauf: authentifizieren, das gewünschte Artefakt abrufen und die laufende Umgebung auf dieses Artefakt umstellen.

Aktualisieren wir nun unsere Datei deploy.yml, um diese Schritte zu simulieren. Mit echo-Befehlen zeigen wir an, was dabei passieren würde.

Öffnen Sie die Datei erneut.

nano .github/workflows/deploy.yml

Ersetzen Sie den Abschnitt jobs durch diese ausführlichere Simulation:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Mock SSH Connection
        run: echo "Connecting to production server at 192.168.1.1..."

      - name: Pull New Image
        run: |
          echo "Logging into Registry..."
          echo "Pulling image ghcr.io/myname/app:latest..."

      - name: Restart Application
        run: |
          echo "Stopping old container..."
          echo "Starting new container..."
          echo "Deployment Successful!"

Speichern und schließen Sie die Datei. Pushen Sie anschließend Ihre Änderungen.

git add .
git commit -m "Update deployment steps"
git push

Kehren Sie zu GitHub Actions zurück und führen Sie den Workflow Deploy to Production erneut manuell aus. Beobachten Sie die Protokolle. Der Ablauf sieht genauso aus wie eine echte Bereitstellung!

Run workflow

Diese „Mock“-Technik ist tatsächlich sehr nützlich. In der professionellen Praxis erstellen wir oft zuerst solche „Skeleton“-Workflows, um den Prozess abzustimmen, bevor wir den tatsächlichen komplexen Code schreiben.

Sicherheitsprüfungen hinzufügen

Derzeit ist unser Workflow „Deploy“ vollständig von unserem Workflow „Test“ (CI) getrennt. In der Praxis möchten Sie jedoch niemals fehlerhaften Code bereitstellen. Der Lieferwagen soll nur losfahren, wenn die Qualitätsprüfung erfolgreich war.

Workflows können mit dem Schlüsselwort needs miteinander verknüpft werden. Das funktioniert am besten innerhalb einer einzelnen Datei. Bei getrennten Dateien steuern wir den Ablauf normalerweise über den Prozess: CI wird bei einem Push ausgeführt, CD bei einem Release oder manuell.

Lernen wir dennoch, wie Sie auch für eine manuelle Bereitstellung eine Sicherheitsprüfung hinzufügen. Wir gehen davon aus, dass wir nur dann bereitstellen möchten, wenn wir absolut sicher sind.

Öffnen Sie deploy.yml.

nano .github/workflows/deploy.yml

Fügen wir eine Simulation des Umgebungsschutzes hinzu. Ändern Sie den Abschnitt steps, sodass er eine Pause enthält.

steps:
  - name: Safety Check
    run: echo " verifying that CI passed..."

  - name: Mock SSH Connection
    run: echo "Connecting to production server at 192.168.1.1..."
  ## ... rest of the file

(Hinweis: In einer echten Enterprise-Umgebung würden wir eine Funktion namens GitHub Environments verwenden, um zu erzwingen, dass „CI erfolgreich sein muss“, bevor dieser Job ausgeführt werden kann. Dafür wäre jedoch eine Konfiguration außerhalb dieser Datei erforderlich.)

Speichern und schließen Sie die Datei vorerst. Pushen Sie anschließend Ihre Änderungen.

git add .
git commit -m "Add safety check"
git push

Führen Sie den Workflow ein letztes Mal manuell aus.

Zusammenfassung

Herzlichen Glückwunsch! Sie haben das GitHub-Actions-CICD-Modul abgeschlossen.

In diesem letzten Lab haben Sie gelernt:

Manuelle Trigger: wie Sie workflow_dispatch für kontrollierte Bereitstellungen verwenden;
Simulation: wie Sie einen Bereitstellungsprozess mit Mock-Schritten prototypisch umsetzen;
Der Gesamtzusammenhang: wie CI, Artefakte, Sicherheit und CD zusammenspielen.

Sie haben ohne Vorkenntnisse zu GitHub Actions begonnen. Nun verfügen Sie über ein vollständig funktionsfähiges Repository mit Skripten für automatisierte Tests, Paketierung und Bereitstellung. Sie sind bereit, Ihre eigenen Projekte zu automatisieren!