DevOps-Prozesse mit Tools unterstützen

DevOps ist keine Abteilung und kein einzelnes Tool, sondern eine Arbeitsweise, bei der Entwicklung und Betrieb gemeinsam Verantwortung tragen. Du analysierst, wo Änderungen heute hängen bleiben, führst klare Regeln für Branches und Reviews ein und baust eine Pipeline, die jede Änderung automatisch prüft und ausliefert. Umgebungen entstehen aus Code, und Monitoring zeigt dem Team, wie sich Releases auswirken. Am Ende kannst du mit Kennzahlen belegen, dass Auslieferungen schneller und sicherer geworden sind.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Den Weg einer Änderung vom Commit bis zur Produktion analysieren und Engpässe benennen

   Kompetenz A, F

   Du zeichnest auf, welche Schritte eine Änderung durchläuft, wie lange sie wartet und wo manuelle Arbeit oder Fehler entstehen. Mit den vier DORA-Kennzahlen machst du den Ist-Zustand messbar.

   Situation

   Ein Softwarehaus in Zug liefert seine Kundenportal-App einmal pro Monat aus. Jedes Release dauert einen halben Tag, und jedes dritte braucht einen Hotfix.

   Deine Aufgabe

   Erstelle eine Wertstromanalyse und erhebe die DORA-Kennzahlen.

   Gutes Ergebnis

   Ein Diagramm zeigt: Code wartet im Schnitt 4 Tage auf Review und 9 Tage auf das nächste Release-Fenster, Tests laufen manuell. Kennzahlen: Deployment-Frequenz monatlich, Lead Time 16 Tage, Change Failure Rate 33 %, Wiederherstellung 6 Std. Die drei grössten Engpässe sind priorisiert.

   WertstromanalyseLead TimeDeployment-FrequenzChange Failure RateTime to Restore
2. 2

   Eine Branching-Strategie mit Pull Requests und geschützten Branches einführen

   Kompetenz B

   Du legst fest, wie das Team mit Branches arbeitet, und erzwingst Qualität technisch: Kein Merge ohne grüne Pipeline und ohne Review. Kurze Branches verhindern grosse, riskante Merges.

   Situation

   Im Kundenportal-Team leben Feature-Branches oft drei Wochen. Merges dauern Stunden, und auf main landet manchmal Code, der nicht kompiliert.

   Deine Aufgabe

   Führe Trunk-Based Development mit kurzlebigen Branches ein.

   Gutes Ergebnis

   Branches leben höchstens 2 Tage, main ist geschützt: 1 Review, grüne Pipeline und aktueller Stand sind Pflicht. Eine PR-Vorlage fragt nach Tests und Screenshots, CODEOWNERS weist Reviews automatisch zu. Nach einem Monat ist die mittlere Review-Wartezeit von 4 Tagen auf 6 Stunden gesunken.

   Trunk-Based DevelopmentGitFlowPull / Merge RequestBranch ProtectionCODEOWNERS
3. 3

   Eine CI-Pipeline mit Build, Tests, Codeanalyse und Sicherheitsprüfung aufbauen

   Kompetenz C

   Jeder Push wird automatisch gebaut, getestet und geprüft. Du ordnest die Schritte so an, dass schnelle Prüfungen zuerst laufen, nutzt Caching und sorgst dafür, dass die Pipeline auch bei Sicherheitslücken in Abhängigkeiten anschlägt.

   Situation

   Die Tests des Kundenportals laufen nur, wenn jemand daran denkt. Eine veraltete Bibliothek mit bekannter Lücke ist seit Monaten im Projekt.

   Deine Aufgabe

   Baue eine GitHub-Actions-Pipeline, die bei jedem Pull Request läuft.

   Gutes Ergebnis

   Jobs: Lint und Unit-Tests parallel (2 Min.), danach Integrationstests mit PostgreSQL-Service-Container, SonarQube Cloud-Analyse mit Quality Gate, Abhängigkeitsscan mit Dependabot und Trivy. Mit Caching dauert der ganze Lauf 7 statt 15 Minuten, und die alte Bibliothek ist ersetzt.

   Continuous IntegrationJob / StageCachingQuality GateDependency ScanningArtefakt
4. 4

   Automatisch ausliefern und bei Problemen schnell zurückrollen

   Kompetenz D

   Was die CI-Prüfung besteht, wird automatisch in Test und nach Freigabe in Produktion ausgeliefert. Du wählst eine Strategie, mit der neue Versionen ohne Ausfall live gehen und bei Fehlern in Minuten zurückgenommen werden können. Feature Flags trennen Deployment und Freischaltung.

   Situation

   Releases des Kundenportals finden am Freitagabend mit 30 Minuten Wartungsfenster statt. Ein fehlerhaftes Release blieb einmal ein ganzes Wochenende online.

   Deine Aufgabe

   Stelle auf Continuous Delivery mit ausfallfreiem Deployment um.

   Gutes Ergebnis

   Jeder Merge auf main landet automatisch in Test, Produktion nach Klick auf 'Approve'. Container Apps Revisions mit 10 % Traffic auf die neue Version für 15 Minuten, dann 100 %. Rollback ist ein Klick oder ein Befehl, unfertige Features sind per Flag ausgeschaltet. Releases finden jetzt dienstags um 10 Uhr statt.

   Continuous Delivery / DeploymentBlue-GreenCanary ReleaseFeature FlagRollback
5. 5

   Umgebungen und Konfiguration als Code reproduzierbar machen

   Kompetenz E

   Test- und Produktionsumgebung sollen sich nur in klar definierten Werten unterscheiden. Du beschreibst Infrastruktur mit Terraform, legst Konfiguration pro Umgebung fest und lässt Änderungen daran ebenfalls durch Review und Pipeline laufen.

   Situation

   Ein Fehler tritt nur in Produktion auf, weil dort eine andere PostgreSQL-Version und andere Timeouts eingestellt sind.

   Deine Aufgabe

   Bringe beide Umgebungen unter Terraform und dokumentiere die Unterschiede.

   Gutes Ergebnis

   Ein Terraform-Modul für die App-Umgebung, aufgerufen mit 'test.tfvars' und 'prod.tfvars'. Unterschiede sind nur Grösse, Replikas und Domain. Infrastrukturänderungen laufen über Pull Requests, die Pipeline zeigt das Ergebnis von 'terraform plan' als Kommentar.

   Infrastructure as CodeUmgebungsparitättfvars / VariablenGitOpsSecrets-Management
6. 6

   Mit Monitoring und Logs Rückmeldung aus dem Betrieb ins Team holen

   Kompetenz F

   Nach dem Deployment ist nicht Schluss. Du sorgst dafür, dass das Team sieht, wie sich eine neue Version verhält: Fehlerquote, Antwortzeiten, Logs mit Version. Vorfälle werden ohne Schuldzuweisung nachbesprochen, und die Erkenntnisse landen im Backlog.

   Situation

   Nach einem Release beschweren sich Kundinnen über langsame Ladezeiten. Das Team merkt es erst nach zwei Tagen über den Support.

   Deine Aufgabe

   Mach die Auswirkungen von Releases sichtbar.

   Gutes Ergebnis

   Die App exportiert Metriken an Prometheus, ein Grafana-Dashboard zeigt Antwortzeit und Fehlerquote mit Markierungen für jedes Deployment. Ein Alarm meldet eine 95%-Antwortzeit über 800 ms in den Teamkanal. Nach dem Vorfall gibt es ein Post-Mortem mit drei konkreten Massnahmen im Backlog.

   ObservabilityMetriken / Logs / TracesDeployment-MarkerSLOPost-Mortem

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Selin ist im 4. Lehrjahr als Informatikerin Applikationsentwicklung bei der Seeland Mobility AG in Biel, 80 Mitarbeitende. Ihr Team entwickelt die Buchungs-App für E-Bike-Sharing mit einem Spring-Boot-Backend und einem React-Frontend. Releases gibt es einmal im Monat an einem Donnerstagabend, zwei Personen brauchen dafür vier Stunden, und danach folgen oft Hotfixes.

1. Kapitel 1

   Wo bleibt die Zeit?

   Selin verfolgt zehn abgeschlossene Änderungen vom ersten Commit bis zur Produktion und nutzt dafür Git-Log und Jira. Im Median dauert eine Änderung 19 Tage, davon warten 12 Tage auf das Release-Fenster und 4 Tage auf ein Review. Drei der letzten zehn Releases brauchten einen Hotfix. Auf einem Miro-Board zeichnet sie den Wertstrom und markiert das monatliche Release und die manuellen Tests als grösste Engpässe.

   Ziel 1

2. Kapitel 2

   Kurze Branches, schnelle Reviews

   Bisher lebten Feature-Branches einen ganzen Sprint lang, und vor jedem Release gab es Merge-Konflikte. Selin schlägt kurze Branches von höchstens zwei Tagen vor, Pull Requests mit einem Pflicht-Review und CODEOWNERS für das Zahlungsmodul. Am ersten Tag will ein Kollege einen Hotfix direkt auf main pushen und wird von der Branch Protection gestoppt. Das Team einigt sich darauf, dass auch Hotfixes über einen Pull Request gehen, mit einem Express-Review innerhalb von 30 Minuten.

   Ziel 2

3. Kapitel 3

   Die Pipeline als Türsteherin

   In GitHub Actions baut Selin eine Pipeline mit Maven-Build, Unit-Tests, SonarQube Cloud-Quality-Gate und einem Trivy-Scan des Docker-Images. Der erste Lauf dauert 14 Minuten, mit Caching der Abhängigkeiten sind es noch 6. Gleich beim ersten Scan meldet Trivy eine kritische Lücke in einer alten Jackson-Bibliothek. Dependabot erstellt dazu einen Pull Request, der nach grünen Tests gemergt wird.

   Ziel 3

4. Kapitel 4

   Ausliefern am Dienstagmittag

   Jeder Merge auf main landet jetzt automatisch in der Staging-Umgebung auf Azure Container Apps, für Produktion braucht es eine Freigabe im Pipeline-Lauf. Neue Versionen bekommen zuerst 10 Prozent des Verkehrs. Bei einem Release steigt die Fehlerrate im Canary, weil der QR-Code-Scan auf älteren Android-Geräten nicht mehr funktioniert. Selin schiebt den Verkehr in unter zwei Minuten zurück auf die alte Revision, und weil alle Datenbankänderungen abwärtskompatibel sind, geht dabei nichts verloren.

   Ziel 4

5. Kapitel 5

   Gleiche Umgebungen und ehrliche Zahlen

   Bei der Ursachensuche fällt auf, dass Staging von Hand eingerichtet war und eine Umgebungsvariable anders gesetzt hatte als Produktion. Selin beschreibt beide Umgebungen mit Terraform, die Unterschiede stehen nur noch in tfvars-Dateien und die Secrets im Key Vault. In Grafana zeigt ein Dashboard Fehlerrate und Antwortzeit mit Markern für jedes Deployment. Nach zwei Monaten liefert das Team zweimal pro Woche aus, die Lead Time liegt bei 3 Tagen, und Selin leitet das Post-Mortem zum QR-Fehler ohne Schuldzuweisung.

   Ziel 5Ziel 6

1. 1

   Ist-Zustand verstehen

   ca. 4 Std.

   Du analysierst ein bestehendes Projekt aus Schule oder Lehrbetrieb, bevor du etwas automatisierst.

   • Den Weg einer Änderung vom Ticket bis zur Produktion als Wertstrom aufzeichnen
   • Die vier DORA-Kennzahlen für das Projekt schätzen oder aus Git und Tickets auslesen
   • Die drei grössten Engpässe priorisieren und Ziele festlegen

   Trainiert Kompetenz A1A2

   Lernziel1

2. 2

   Zusammenarbeit im Repository

   ca. 3 Std.

   Du richtest Regeln ein, die gute Zusammenarbeit technisch unterstützen.

   • Branch Protection, PR-Vorlage und CODEOWNERS in einem Übungsrepo einrichten
   • Trunk-Based Development und GitFlow für das eigene Team vergleichen
   • Mit einer Kollegin drei Pull Requests gegenseitig reviewen und Feedbackregeln festhalten

   Trainiert Kompetenz B1B2

   Lernziel2

3. 3

   Continuous Integration

   ca. 6 Std.

   Du baust eine schnelle, aussagekräftige CI-Pipeline. GitHub Actions ist für öffentliche Repos und mit dem Student Developer Pack grosszügig kostenlos nutzbar.

   • Workflow mit Lint, Unit-Tests und Build erstellen und mit Caching beschleunigen
   • Integrationstests mit einer Datenbank als Service-Container ergänzen
   • SonarQube Cloud und einen Abhängigkeitsscan einbinden und ein Quality Gate definieren

   Trainiert Kompetenz C1C2

   Lernziel3

4. 4

   Continuous Delivery

   ca. 6 Std.

   Du lieferst automatisch in zwei Umgebungen aus und übst das Zurückrollen.

   • Image in eine Registry pushen und in Test automatisch deployen
   • Produktions-Deployment mit Freigabe und Canary- oder Blue-Green-Strategie umsetzen
   • Ein Feature Flag einbauen und ein fehlerhaftes Release bewusst zurückrollen

   Trainiert Kompetenz D1D2

   Lernziel4

5. 5

   Infrastruktur und Konfiguration als Code

   ca. 5 Std.

   Du beschreibst beide Umgebungen mit Terraform und bindest Infrastrukturänderungen in den Pull-Request-Prozess ein.

   • Ein Terraform-Modul für die App-Umgebung schreiben und mit zwei tfvars-Dateien nutzen
   • 'terraform plan' in der Pipeline als PR-Kommentar ausgeben
   • Secrets aus der Pipeline in einen Key Vault oder Secrets Manager verschieben

   Trainiert Kompetenz E1E2

   Lernziel5

6. 6

   Feedback schliessen und Wirkung messen

   ca. 5 Std.

   Du machst Releases sichtbar, besprichst einen Vorfall nach und misst die Verbesserung.

   • Grafana-Dashboard mit Deployment-Markern aufbauen
   • Ein Post-Mortem zu einem echten oder simulierten Vorfall schreiben
   • Die DORA-Kennzahlen erneut erheben und mit dem Ausgangszustand vergleichen

   Trainiert Kompetenz F1F2A3

   Lernziel61

DevOps

Arbeitsweise, bei der Entwicklung und Betrieb gemeinsam Verantwortung für Auslieferung und Stabilität tragen.

Continuous Integration

Änderungen werden häufig zusammengeführt und jedes Mal automatisch gebaut und getestet.

Continuous Delivery

Jede geprüfte Version ist jederzeit auslieferbar, der Schritt in die Produktion ist ein Knopfdruck.

Trunk-Based Development

Alle arbeiten mit sehr kurzlebigen Branches nahe am Hauptzweig und mergen täglich.

Quality Gate

Automatische Schwelle, z.B. Testabdeckung oder keine kritischen Befunde, die erfüllt sein muss, damit es weitergeht.

Canary Release

Neue Version wird zuerst nur für einen kleinen Teil der Nutzenden ausgerollt.

Feature Flag

Schalter im Code, mit dem eine Funktion ohne neues Deployment ein- oder ausgeschaltet wird.

DORA-Kennzahlen

Vier Messgrössen für Leistungsfähigkeit in der Softwareauslieferung aus der DevOps-Forschung.

Post-Mortem

Strukturierte Nachbesprechung eines Vorfalls ohne Schuldzuweisung, mit Massnahmen.

Passende Module