Teil 6 – Workflows für Deployment und Automatisierung

Sep. 14, 2025

—

von

Warum Workflows mehr sind als CI

Im letzten Teil haben wir gesehen, wie GitHub Actions genutzt werden, um Code automatisch zu bauen und zu testen.
Doch Workflows können noch viel mehr:

Deployment von Anwendungen
Automatisierung von Routineaufgaben
Sicherheitsscans
Release-Management

👉 Workflows sind damit das Rückgrat moderner DevOps-Pipelines direkt in GitHub.

Was ist Deployment?

Deployment bedeutet: den Code aus dem Repository in eine Umgebung bringen, in der er läuft.
Das kann sein:

eine statische Website auf GitHub Pages
ein Webservice in AWS, Azure oder GCP
ein Container-Image in Docker Hub oder Kubernetes
eine Mobile App im App Store

Früher waren Deployments oft manuell und fehleranfällig. Mit GitHub Actions geht das automatisch – nach jedem Commit oder Release.

Beispiel 1: Deployment auf GitHub Pages

GitHub Pages ist ein Service, um statische Websites direkt aus einem Repo zu hosten. Perfekt für:

Projektseiten
Dokumentationen
persönliche Blogs

Workflow-Beispiel

name: Deploy to GitHub Pages

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build site
        run: npm run build
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

👉 Bei jedem Push auf main wird die Website neu gebaut und veröffentlicht.

Beispiel 2: Deployment zu Docker Hub

Container sind heute Standard für Deployments. Mit GitHub Actions kann man automatisch Docker-Images bauen und pushen.

Workflow

name: Build and Push Docker Image

on:
  push:
    branches: [ main ]

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Login to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
      - name: Build and push
        uses: docker/build-push-action@v4
        with:
          push: true
          tags: meinname/meinapp:latest

👉 Ergebnis: Bei jedem Push gibt es ein aktuelles Docker-Image im Docker Hub.

Beispiel 3: Deployment auf AWS

Viele Unternehmen nutzen Cloud-Plattformen. Auch hier lässt sich Deployment automatisieren.

Workflow (verkürzt)

name: Deploy to AWS

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-central-1
      - name: Deploy app
        run: aws s3 sync ./dist s3://meinbucket

👉 Damit wird bei jedem Push der Inhalt von ./dist automatisch in ein S3-Bucket hochgeladen.

Automatisierung über Deployment hinaus

Workflows können nicht nur deployen – sie können jede Routineaufgabe automatisieren.

Beispiele:

Code-Qualität prüfen - name: Run ESLint run: npm run lint
Sicherheit prüfen (z. B. Abhängigkeiten scannen) - uses: github/codeql-action/init@v2
Automatisch Releases erstellen - name: Create Release uses: softprops/action-gh-release@v1 with: tag_name: v1.0.0
Alte Issues schließen - uses: actions/stale@v8 with: days-before-stale: 30 days-before-close: 7

👉 So spart man Zeit und sorgt für saubere Projekte.

Secrets – das Herzstück der Sicherheit

Viele Workflows brauchen Zugangsdaten (z. B. für AWS, Docker oder Datenbanken).
Diese sollten niemals im Code stehen. Stattdessen:

In GitHub: Settings → Secrets → New Repository Secret
Zugriff im Workflow: with: token: ${{ secrets.MEIN_SECRET }}

👉 So bleiben Deployments sicher und trotzdem automatisierbar.

Komplexe Pipelines

Große Projekte brauchen oft mehrstufige Workflows:

Build → Code kompilieren.
Test → Unit- und Integrationstests.
Deploy-Staging → auf Testsystem ausrollen.
Manuelle Freigabe → menschlicher Check.
Deploy-Production → in Produktion ausrollen.

Beispiel: Staging + Production mit Approval

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to Staging"

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://meine-app.com
    steps:
      - run: echo "Deploy to Production"

👉 GitHub bietet hier sogar Environment Protection Rules: z. B. „Deployment nur nach Freigabe durch einen Maintainer“.

Best Practices für Workflows

Keep it simple
- Workflows klein und modular halten.
Test vor Deploy
- Deployment sollte nur laufen, wenn Tests bestanden haben.
Secrets richtig verwenden
- Keine Passwörter im Code.
Cache nutzen
- Dependencies und Builds cachen, um Zeit zu sparen.
Workflows wiederverwenden
- workflow_call erlaubt, Workflows in mehreren Projekten zu teilen.
Automatisierung konsequent einsetzen
- Alles, was manuell ist und sich wiederholt, gehört automatisiert.

Praktisches Szenario: Web-App Deployment

Ein Team entwickelt eine React-App. Workflow:

Push auf main löst Workflow aus.
Build mit npm run build.
Tests laufen.
Wenn erfolgreich: Docker-Image bauen.
Image wird automatisch in Docker Hub gepusht.
In AWS ECS wird die neue Version deployed.

👉 Ergebnis: Jeder Commit ist automatisch live – fehlerfrei, reproduzierbar und dokumentiert.