DevOps und Continuous Delivery
In dieser Lerneinheit tauchst du in die Grundlagen von DevOps und Continuous Delivery ein, wobei der Fokus auf der praktischen Arbeit mit Git als Versionsverwaltungssystem liegt. Du lernst die wichtigsten Git-Befehle und Workflows kennen und verstehst, wie Versionsverwaltung die kontinuierliche Software-Auslieferung ermöglicht. Durch konkrete Beispiele erfährst du, wie moderne Entwicklungsteams Code verwalten, Änderungen nachverfolgen und effizient zusammenarbeiten.
Einführung
Stell dir vor, dein Team hat einen kritischen Bug gefixt. In traditionellen Prozessen dauert es Wochen, bis der Fix bei den Nutzenden ankommt: Manuelles Testen (3-5 Tage), Freigabe-Meetings (1 Woche), kompliziertes Deployment (2-3 Tage). Rollbacks dauern genauso lang.
Während dieser Zeit leiden Kunden unter dem Bug, Konkurrenten ziehen vorbei und das Team ist frustriert.
DevOps und Continuous Delivery lösen dieses Problem. Moderne Teams nutzen automatisierte Prozesse, um Änderungen in Minuten statt Wochen sicher auszurollen.
In dieser Lerneinheit lernst du die Werkzeuge und Praktiken kennen, die diesen Wandel ermöglichen: Git für Zusammenarbeit, CI/CD für Automatisierung, Docker für Konsistenz und Kubernetes für Skalierung.
Lernziele
Nach dieser Lerneinheit kannst du:
- Git für Versionsverwaltung im Team nutzen
- Den Unterschied zwischen CI und CD erklären
- Docker-Container erstellen und verstehen
- Kubernetes-Grundkonzepte anwenden
- Den Ablauf einer modernen DevOps-Pipeline beschreiben
Überleitung
Um zu verstehen, wie DevOps das Problem langsamer Deployments löst, schauen wir uns zunächst die Grundlage an: Versionsverwaltung mit Git.
Danach lernst du, wie Continuous Integration und Deployment diese Basis nutzen, um automatisierte Pipelines zu bauen. Schließlich siehst du, wie Container-Technologien den gesamten Prozess konsistent und skalierbar machen.
Was ist DevOps?
DevOps verbindet Entwicklung (Development) und IT-Betrieb (Operations). Das Ziel ist, Software schneller und zuverlässiger auszuliefern.
Traditionell arbeiteten beide Bereiche getrennt:
- Entwicklung baut neue Features
- Operations sorgt für Stabilität in Produktion
Wenn diese Teams nicht zusammenarbeiten, entstehen Konflikte: Entwickler wollen schnelle Änderungen, Operations will Stabilität.
DevOps löst diesen Konflikt durch gemeinsame Verantwortung, automatisierte Prozesse und kontinuierliche Zusammenarbeit. Beide Teams nutzen dieselben Werkzeuge und Praktiken.
Versionsverwaltung mit Git: Grundkonzepte
Git ist ein Versionsverwaltungssystem, das die Zusammenarbeit im Team ermöglicht. Es speichert den gesamten Verlauf deines Codes und erlaubt parallele Entwicklung.
| Konzept | Beschreibung |
|---|---|
| Repository (Repo) | Speicher für Code und dessen Historie |
| Branch | Unabhängige Entwicklungslinie für Features/Fixes |
| Commit | Schnappschuss des Projekts zu einem Zeitpunkt |
| Merge | Zusammenführen von Änderungen aus verschiedenen Branches |
| Pull Request (PR) | Anfrage zur Integration von Änderungen mit Code-Review |
Faustregel: Jeder Branch ist ein isolierter Arbeitsbereich. Commits speichern Fortschritt. Merges bringen Änderungen zusammen.
Wichtige Git-Befehle
Diese Befehle bilden den Kern deines Git-Workflows:
| Befehl | Funktion |
|---|---|
git clone [URL] | Kopiert Repository auf lokalen Computer |
git branch [name] | Erstellt neuen Branch |
git switch [name] | Wechselt zu einem Branch (modern) |
git add [datei] | Fügt Datei zur Staging-Area hinzu |
git commit -m "msg" | Erstellt Commit mit Nachricht |
git merge [branch] | Führt Branch in aktuellen Branch ein |
git push | Lädt lokale Commits auf Remote-Server |
git pull | Holt Änderungen vom Remote-Server |
Wichtig: git switch ist der moderne Ersatz für git checkout zum Branch-Wechsel (seit Git 2.23).
Codereview-Prozesse
Codereviews verbessern die Codequalität durch gegenseitiges Überprüfen. Bevor Code in den Hauptbranch kommt, prüfen Kollegen ihn.
Ziele von Codereviews
- Fehlererkennung: Bugs finden, die Tests übersehen haben
- Wissensaustausch: Neue Techniken und Standards lernen
- Konsistenz: Code folgt einheitlichem Stil
- Sicherheit: Sicherheitslücken identifizieren
Best Practices
- Kleine Pull Requests: Leichter zu verstehen als große Änderungen
- Positive Kommunikation: Konstruktives, ermutigendes Feedback
- Checklisten nutzen: Wichtige Prüfpunkte nicht vergessen
- Automatisierung: Linters und Tests vor manueller Review
- Schnelles Feedback: Reviews zeitnah durchführen
Build-Automatisierung und Dependency Management
Build-Automatisierung kompiliert Code, lädt Abhängigkeiten und führt Tests automatisch aus. Tools wie Jenkins, GitLab CI oder GitHub Actions übernehmen diese Arbeit.
Warum ist das wichtig?
- Effizienz: Spart Zeit und reduziert manuelle Fehler
- Konsistenz: Jeder Build folgt dem gleichen Prozess
- Schnelle Fehlererkennung: Probleme werden sofort erkannt
- Integration: Passt nahtlos in CI/CD-Pipelines
Dependency Management
Dependency Management verwaltet externe Bibliotheken und Frameworks. Jede Sprache hat eigene Tools:
- Java: Maven, Gradle
- JavaScript: npm, Yarn
- Python: pip
Herausforderungen: Version-Konflikte, transitive Abhängigkeiten, inkonsistente Umgebungen
Continuous Integration (CI): Automatisierte Integration
Continuous Integration bedeutet, dass Entwickler ihre Änderungen häufig (mindestens täglich) in ein gemeinsames Repository integrieren. Jede Integration wird automatisch getestet.
Wie funktioniert CI?
- Entwickler pusht Code ins Repository
- CI-Server (Jenkins, GitLab CI, GitHub Actions) erkennt Änderung
- Automatischer Build startet
- Tests laufen automatisch (Unit-Tests, Integrationstests)
- Sofortiges Feedback: Erfolg oder Fehler
Warum ist das wichtig?
Frühe Fehlererkennung: Probleme werden sofort erkannt, nicht erst Wochen später. Code-Integration ist kein großer, riskanter Schritt mehr, sondern ein kontinuierlicher Prozess.
Verbesserte Qualität: Automatische Tests fangen Bugs ab, bevor sie in Produktion gehen.
Continuous Deployment (CD): Automatisierte Auslieferung
Continuous Deployment ist der nächste Schritt nach CI. Sobald Tests erfolgreich sind, wird der Build automatisch in Produktion ausgerollt.
Wie funktioniert CD?
- CI-Pipeline war erfolgreich (Build + Tests OK)
- CD-Pipeline startet automatisch
- Weitere Tests in Staging-Umgebung (optional)
- Automatisches Deployment in Produktion
- Monitoring nach Deployment
Warum ist das wichtig?
Schnelle Markteinführung: Features und Bugfixes erreichen Nutzende in Minuten, nicht Wochen.
Weniger manuelle Fehler: Automatisierung eliminiert menschliche Fehler beim Deployment.
Kleinere, sicherere Änderungen: Häufige, kleine Deployments sind sicherer als seltene, große.
CI vs CD: Der wichtige Unterschied
Viele verwechseln CI und CD. Der Unterschied ist entscheidend:
| Aspekt | CI (Integration) | CD (Deployment) |
|---|---|---|
| Ziel | Code integrieren + testen | In Produktion ausrollen |
| Endet bei | Erfolgreichem Build + Tests | Deployment in Produktion |
| Frequenz | Bei jedem Commit | Nach jedem erfolgreichen CI |
| Hauptrisiko | Merge-Konflikte, Testfehler | Deployment-Fehler, Rollback |
Merksatz: CI sorgt dafür, dass der Code funktioniert. CD sorgt dafür, dass er bei Nutzenden ankommt.
Continuous Delivery (mit “e”) ist eine Variante: Der Build ist deployment-bereit, aber ein menschlicher Klick startet das Deployment.
Die CI/CD-Pipeline: Wie alles zusammenspielt
Eine CI/CD-Pipeline verbindet alle Schritte von Code-Änderung bis Produktion. Jeder Schritt ist automatisiert.
Typische Pipeline-Stufen
- Source: Code-Änderung wird erkannt (Git Push)
- Build: Code wird kompiliert, Dependencies geladen
- Test: Unit-Tests, Integrationstests, Security-Scans
- Package: Build-Artefakte werden erstellt (z.B. Docker-Image)
- Deploy Staging: Deployment in Test-Umgebung
- Deploy Production: Automatisches oder manuelles Deployment
- Monitor: Überwachung nach Deployment
Best Practices
- Feature Toggles: Features ein/ausschalten ohne neues Deployment
- Schnelles Feedback: Pipeline sollte < 10 Minuten dauern
- Rollback-Plan: Schnelles Zurückrollen bei Problemen
Containerisierung mit Docker: Grundlagen
Container verpacken Anwendungen mit allen Abhängigkeiten in eine isolierte Einheit. Die Anwendung läuft überall identisch, egal ob auf deinem Laptop oder einem Server.
Docker-Konzepte
| Konzept | Beschreibung |
|---|---|
| Image | Schreibgeschützte Vorlage für Container (wie ein Bauplan) |
| Container | Isolierte Laufzeitumgebung basierend auf einem Image |
| Dockerfile | Textdatei mit Anweisungen zum Erstellen eines Images |
| Docker Hub | Service zum Teilen und Verwalten von Images |
Warum Container?
Konsistenz: “Es läuft auf meinem Rechner” ist kein Problem mehr. Container laufen überall gleich.
Isolation: Jeder Container hat seine eigene Umgebung. Konflikte zwischen Anwendungen werden verhindert.
Kubernetes: Container-Orchestrierung bei Skalierung
Wenn du viele Container verwaltest, wird es schnell komplex. Kubernetes (oft K8s) automatisiert Deployment, Skalierung und Verwaltung von Container-Anwendungen.
Grundlegende Kubernetes-Konzepte
| Konzept | Beschreibung |
|---|---|
| Pod | Kleinste Einheit, enthält einen oder mehrere Container |
| Deployment | Verwaltet Pods, ermöglicht Updates und Rollbacks |
| Service | Macht Pods als Netzwerkdienst zugänglich |
| ReplicaSet | Sorgt für konstante Anzahl laufender Pods |
Warum Kubernetes?
Automatische Skalierung: Mehr Container bei hoher Last, weniger bei niedriger.
Self-Healing: Abgestürzte Container werden automatisch neu gestartet.
Load Balancing: Traffic wird auf mehrere Pods verteilt.
Docker in der Praxis: Sichere Container bauen
Ein Dockerfile definiert, wie dein Image aufgebaut wird. Hier ein sicheres Beispiel für eine Node.js-App mit wichtigen Best Practices.
Sicheres Dockerfile-Beispiel
Dieses Beispiel zeigt drei wichtige Sicherheitsaspekte:
1. Versionierte Base Images:
FROM node:18.20.4-alpineNutze node:18.20.4-alpine statt nur node:18. Das macht Builds reproduzierbar.
2. Non-root User:
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuserContainer sollten niemals als root laufen. Das verhindert Privilege-Escalation.
3. Alpine Linux: Alpine ist ein minimales Base-Image (5 MB statt 100+ MB). Weniger Code bedeutet weniger Angriffsfläche.
Kubernetes in der Praxis: Deployment und Service
Ein Deployment definiert, wie deine App laufen soll. Ein Service macht sie erreichbar.
Deployment-Konfiguration
Ein Deployment verwaltet deine Pods. Wichtige Felder:
- replicas: Anzahl der Pods (z.B. 2 für Redundanz)
- image: Versioniertes Docker-Image (z.B. myregistry/node-app:1.0.0)
- containerPort: Port, den die App nutzt (z.B. 8080)
Wichtig: Nutze private Registries und versionierte Images. Niemals latest-Tag in Produktion verwenden.
Service-Konfiguration
Ein Service macht deine Pods erreichbar. Wichtige Typen:
- ClusterIP: Nur innerhalb des Clusters (Standard)
- NodePort: Über Node-IP erreichbar (Entwicklung)
- LoadBalancer: Externer Load Balancer (Cloud-Umgebungen)
LoadBalancer funktioniert in AWS, GCP und Azure automatisch. Für lokale Entwicklung nutzt du NodePort oder ClusterIP.
Zusammenfassung und Ausblick
Zusammenfassung
DevOps verbindet Entwicklung und Operations für schnellere, zuverlässigere Software-Auslieferung. Diese Lesson hat die Werkzeuge und Praktiken behandelt, die moderne Teams nutzen:
Git ermöglicht Zusammenarbeit durch Versionsverwaltung. Wichtige Befehle wie git switch, git commit und git merge bilden den Workflow. Pull Requests und Code Reviews sichern Qualität.
Continuous Integration (CI) testet Code automatisch bei jeder Änderung. Continuous Deployment (CD) rollt erfolgreiche Builds automatisch in Produktion aus. Der Unterschied: CI endet bei Tests, CD geht bis zur Produktion.
Docker verpackt Anwendungen in Container für Konsistenz. Wichtig: Versionierte Images, non-root User, minimale Base Images (Alpine).
Kubernetes orchestriert viele Container. Pods, Deployments und Services automatisieren Skalierung und Verfügbarkeit.
Ausblick
In der nächsten Lerneinheit geht es um Fallstudien und praktische Übungen, wo du das Gelernte in realistischen Szenarien anwendest. Du siehst, wie echte Teams DevOps-Praktiken nutzen und übst die Integration aller Werkzeuge.