Microlearning
MicrolearningJedes Mal, wenn du pushst und eine CI/CD-Pipeline loslegt, startet irgendwo ein Server, installiert Dependencies, baut dein Projekt und führt Tests aus. Das braucht echte Rechenzeit auf echten Servern – und damit Strom.
Typische Energiefresser in Pipelines:
- Unnecessary Rebuilds – jeder Push triggert einen vollständigen Build, auch wenn sich nur eine README geändert hat
- npm install bei jedem Run – Tausende Pakete werden jedes Mal neu heruntergeladen statt gecacht
- Docker Images ohne Layer Caching – jedes Layer wird jedes Mal neu gebaut
- Doppelte Pipelines – Build läuft auf Push UND auf Pull Request, also zweimal
Green CI Practices:
- Caching nutzen – Dependencies, Docker Layers, Build-Artefakte
- Conditional Builds – nur bauen, wenn relevante Dateien geändert wurden (
paths-Filter in GitHub Actions) - Monorepo-Tools wie Nx oder Turborepo bauen nur, was sich geändert hat
- Concurrency abbrechen – wenn ein neuer Push kommt, alte Runs stoppen
- Lightweight Runner wählen – nicht jeder Job braucht eine fette VM
Tat / Einstellung
Tat / EinstellungAnalysiere deine eigene Pipeline – wie effizient ist dein Build-Prozess wirklich?
Aufgabe 1: GitHub Actions prüfen
- Öffne ein Projekt auf GitHub und gehe zu Actions
- Zähle: Wie viele Runs liefen in der letzten Woche?
- Wie lange dauert ein durchschnittlicher Run?
- Gibt es Runs, die unnötig waren (z. B. nur Doku-Änderungen)?
Aufgabe 2: Caching einrichten
- Öffne deine
.github/workflows/*.ymlDatei - Prüfe, ob
actions/cacheverwendet wird. Falls nicht, füge es hinzu - Nutze
actions/setup-node@v4mitcache: 'npm'für automatisches Node-Caching - Alternativ: Manuelles Caching mit
actions/cache@v4aufnode_modules
Aufgabe 3: Concurrency einrichten
- Füge in deinem Workflow
concurrencyhinzu, damit alte Runs abgebrochen werden, wenn ein neuer Push kommt - Setze
cancel-in-progress: true, um laufende Jobs bei neuem Push zu stoppen - So vermeidest du doppelte Builds auf dem gleichen Branch
Reflexion
ReflexionIst es besser, schnell und oft zu deployen – oder seltener und bewusster?
Die DevOps-Kultur sagt: «Ship early, ship often.» Aber das heisst nicht, dass jeder Commit sofort in die Pipeline muss. Batching von Änderungen, bewusste Push-Zeitpunkte und gute Branch-Strategien können die Anzahl der Runs drastisch senken – ohne dass die Qualität leidet. Es geht um den Sweet Spot zwischen Agilität und Ressourcenbewusstsein.
Challenge
ChallengeOptimiere eine CI/CD Pipeline
- Wähle ein Projekt mit einer bestehenden GitHub Actions Pipeline
- Implementiere mindestens 2 der folgenden Optimierungen:
- Dependency Caching hinzufügen
- Conditional Builds mit
paths-Filter einrichten - Concurrency mit
cancel-in-progressaktivieren - Von npm auf pnpm wechseln
Dokumentiere die Build-Zeit vorher vs. nachher.