Du hast von CI/CD gehört, aber keine Ahnung wie das konkret aussieht? Ich zeig dir, wie ich meinen ersten GitHub Actions Workflow gebaut hab – ohne komplizierte Theorie, direkt umsetzbar.

Warum GitHub Actions?

Nach 6 Monaten FISI-Umschulung hab ich gemerkt: Manuell deployen nervt. Jedes Mal die gleichen Befehle tippen, hoffen dass nichts schief geht, dann doch einen Fehler übersehen.

GitHub Actions automatisiert das. Jeder Push triggert Tests, Builds und Deployment. Einmal einrichten, für immer automatisch.

Was du brauchst

GitHub Account (kostenlos)
Ein Git-Repository mit Code
15 Minuten Zeit
Grundkenntnisse: Git, Terminal

Was ist CI/CD eigentlich?

CI (Continuous Integration): Code automatisch testen bei jedem Push
CD (Continuous Deployment): Automatisch auf Server deployen nach erfolgreichen Tests

Praktisch: Du pushst Code → GitHub testet → Bei Erfolg: Automatisches Deployment

Dein erster Workflow

Schritt 1: Workflow-Datei erstellen

GitHub Actions laufen über YAML-Dateien im Ordner .github/workflows/.

# Im Root deines Repositories
mkdir -p .github/workflows
cd .github/workflows
touch ci.yml

Schritt 2: Basis-Workflow konfigurieren

Beispiel: Node.js App testen

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
      - name: Code auschecken
        uses: actions/checkout@v4
      
      - name: Node.js einrichten
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      - name: Dependencies installieren
        run: npm ci
      
      - name: Tests ausführen
        run: npm test

Was passiert hier?

on: push → Workflow startet bei jedem Push
runs-on: ubuntu-latest → Läuft auf Ubuntu (kostenlos für Public Repos)
steps → Einzelne Aktionen, die nacheinander ausgeführt werden

Schritt 3: Workflow testen

# Workflow-Datei committen
git add .github/workflows/ci.yml
git commit -m "Add CI workflow"
git push origin main

Ergebnis prüfen:

Geh zu deinem Repository auf GitHub
Tab “Actions” öffnen
Dort siehst du deinen laufenden Workflow

Grüner Haken = Tests erfolgreich
Rotes X = Tests fehlgeschlagen

Praktische Workflows für FISI-Umschüler

Python-App testen

name: Python CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Python einrichten
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      
      - name: Dependencies installieren
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      
      - name: Tests mit pytest
        run: pytest

Docker-Image bauen und pushen

name: Docker Build

on:
  push:
    branches: [ main ]

jobs:
  docker:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Docker Login
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
      
      - name: Build und Push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: username/app:latest

Wichtig: Docker-Credentials als Secrets hinterlegen:

Repository → Settings → Secrets and variables → Actions
“New repository secret” → DOCKER_USERNAME und DOCKER_PASSWORD

Lint-Check für sauberen Code

name: Code Quality

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Python Linting
        run: |
          pip install flake8
          flake8 . --max-line-length=120

Häufige Fehler (die ich gemacht hab)

1. YAML-Einrückung falsch

Problem: Workflow startet nicht

# ❌ FALSCH - Einrückung nicht konsistent
steps:
- name: Test
run: npm test

# ✅ RICHTIG - 2 Leerzeichen pro Ebene
steps:
  - name: Test
    run: npm test

Tipp: Nutze einen YAML-Validator (yamllint.com)

2. Branch-Name falsch

# Prüf deinen Branch-Namen
on:
  push:
    branches: [ main ]  # Nicht "master"?

Check mit: git branch

3. Secrets nicht gesetzt

Fehler: Error: Username or password is incorrect

Lösung: Secrets in Repository-Settings hinterlegen (siehe oben)

4. Tests schlagen lokal nicht fehl

Problem: Workflow bricht ab, lokal laufen Tests

Ursache: Unterschiedliche Node/Python-Versionen

# Version explizit festlegen
- uses: actions/setup-node@v4
  with:
    node-version: '20.x'  # Exakt wie lokal

Deployment mit GitHub Actions

Server via SSH deployen

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/app
            git pull origin main
            npm install
            npm run build
            pm2 restart app

Secrets benötigt:

SERVER_HOST: Deine Server-IP
SERVER_USER: SSH-User (z.B. root)
SSH_PRIVATE_KEY: Private SSH-Key (ohne Passwort!)

Matrix-Builds: Mehrere Versionen testen

name: Multi-Version Test

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        node-version: [18, 20, 22]
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      
      - run: npm ci
      - run: npm test

Ergebnis: Tests laufen parallel mit Node 18, 20 und 22

Kostenlose Minuten

GitHub Free:

Public Repos: Unbegrenzt kostenlos
Private Repos: 2.000 Minuten/Monat

Tipp: Für FISI-Projekte reicht das locker. Ich hab noch nie das Limit erreicht.

Was ich daraus gelernt hab

Nach 3 Monaten GitHub Actions:

✅ Weniger Fehler in Production
Tests fangen Bugs vor dem Deployment

✅ Schnelleres Deployment
Push → 2 Minuten → Live (statt 15 Minuten manuell)

✅ Transparenz
Team sieht sofort wenn Tests fehlschlagen

❌ Debugging kann nerven
Workflow-Fehler sind manchmal schwer zu finden (Logs genau lesen!)

Nächste Schritte

Ersten Workflow erstellen (Node.js oder Python Beispiel von oben)
Tests schreiben (falls noch nicht vorhanden)
Secrets einrichten für echte Deployments
Matrix-Builds für mehrere Versionen testen

Ressourcen

GitHub Actions Docs - Offizielle Doku
Awesome Actions - Community-Actions
Actions Marketplace - Fertige Actions

Fazit

GitHub Actions ist kein Hexenwerk. Einmal 15 Minuten investieren, danach spart’s dir Stunden.

Ich hab den ersten Workflow auch dreimal neu gebaut. Normal. YAML kann nerven. Aber wenn’s läuft: Gold wert.

Mein Tipp: Klein anfangen. Erst nur Tests, dann Deployment hinzufügen.

Fragen? Schreib mir: schneider@alexle135.de

Weiterführende Artikel:

GitHub Actions für FISI: Dein erster CI/CD Workflow in 15 Minuten