DevOps: Entwicklung und Betrieb als ein Team

DevOps: Entwicklung und Betrieb als ein Team

https://bildung.social/@oerinformatik/

https://oer-informatik.de/devops

DevOps, Vorgehensmodelle, Continuous Integration, Continuous Delivery, Continuous Deployment, Infrastructure as Code, Monitoring, DORA-Kennzahlen, CALMS, Automatisierung, Softwarebetrieb

tl/dr; (ca. 14 min Lesezeit): DevOps verbindet Softwareentwicklung (Development) und IT-Betrieb (Operations) zu einer gemeinsamen Verantwortung: Änderungen sollen klein, häufig, automatisiert und sicher in Betrieb gehen, und Messwerte aus dem Betrieb fließen direkt in die Entwicklung zurück. Der Artikel erklärt Herkunft und Grundprinzipien (CALMS, Three Ways), die DevOps-Schleife und die CI/CD-Pipeline, Rollen und Teamformen, den Testansatz, die DORA-Kennzahlen sowie Grenzen von DevOps [AI-Assisted]. (Zuletzt geändert am 30.10.2026)

Disclaimer: Teile des Textes stammen von einer KI. Inhalte sind nicht automatisch zuverlässig; überprüfe Fakten und zitiere vertrauenswürdige Quellen.

Dieser Artikel ist Teil einer Artikelreihe über Vorgehensmodelle: Überblick: klassisch und agil / Wasserfallmodell / V-Modell / Spiralmodell / Scrum / Extreme Programming / Kanban / SAFe / DevOps / Übungsaufgaben

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

In einem Satz: DevOps zeichnet sich dadurch aus, dass Entwicklung und Betrieb gemeinsam die Verantwortung für eine Software über ihren ganzen Lebenszyklus tragen und Änderungen durch Automatisierung klein, häufig und sicher in Betrieb bringen, während Messwerte aus dem Betrieb laufend in die Entwicklung zurückfließen.

Das Bild der liegenden Acht steht für diesen endlosen Kreislauf: Die linke Schleife ist die Entwicklung (Dev), die rechte der Betrieb (Ops).

Herkunft: die Mauer zwischen Dev und Ops einreißen

DevOps entstand Ende der 2000er Jahre aus einem Konflikt: Entwicklungsteams arbeiteten zunehmend agil und wollten häufig liefern, der Betrieb sollte Stabilität sichern und sah jede Änderung als Risiko. 2008 sprachen Patrick Debois und Andrew Clay Shafer über „Agile Infrastructure“; 2009 zeigten John Allspaw und Paul Hammond auf der Konferenz Velocity, wie Flickr mehr als zehn Mal am Tag auslieferte. Im selben Jahr organisierte Patrick Debois in Gent die ersten DevOpsDays, die dem Begriff seinen Namen gaben. Bücher wie „Continuous Delivery“ (Jez Humble, David Farley, 2010), „The Phoenix Project“ (2013), das „DevOps Handbook“ (2016) und „Accelerate“ (Nicole Forsgren, Jez Humble, Gene Kim, 2018) prägten die Bewegung. Eine zentrale Definition oder ein Herausgeber fehlt: DevOps ist eher eine Kultur mit Praktiken als ein festes Vorgehensmodell. Ziel ist, Software schneller und zugleich stabiler bereitzustellen. Typische Einsatzbereiche sind Webanwendungen, Cloud-Dienste und alle Produkte, die laufend weiterentwickelt und betrieben werden.

Grundprinzipien: CALMS und die drei Wege

Ein verbreitetes Merkwort ist CALMS:

• Culture: gemeinsame Verantwortung, Vertrauen, aus Fehlern lernen statt Schuldige suchen,

• Automation: Build, Test, Bereitstellung und Infrastruktur werden automatisiert,

• Lean: kleine Änderungen, wenig Wartezeit, Verschwendung vermeiden,

• Measurement: Fluss und Betrieb werden gemessen,

• Sharing: Wissen, Werkzeuge und Verantwortung werden geteilt.

Gene Kim beschreibt dazu drei Wege (Three Ways): (1) Fluss von der Entwicklung in den Betrieb beschleunigen, (2) Feedback aus dem Betrieb schnell zurück in die Entwicklung bringen, (3) eine Kultur des ständigen Lernens und Experimentierens pflegen. Besonders an DevOps ist, dass es den Betrieb ausdrücklich einschließt: Agile Modelle wie Scrum enden oft beim fertigen Increment, DevOps geht bis zur laufenden Software und zurück. Der Grundsatz „You build it, you run it“ (Werner Vogels, Amazon) bringt das auf den Punkt.

Ablauf: die Schleife und die Pipeline

Die DevOps-Schleife hat acht Phasen, die endlos wiederholt werden:

1. Plan: Anforderungen und Änderungen planen (oft mit Scrum oder Kanban),

2. Code: entwickeln, in die Versionsverwaltung einchecken,

3. Build: automatisch bauen,

4. Test: automatisiert testen,

5. Release: freigeben, Versionen bilden,

6. Deploy: automatisch in die Zielumgebung bringen,

7. Operate: betreiben, skalieren, Störungen beheben,

8. Monitor: überwachen, messen, Rückmeldungen sammeln – und zurück zu Plan.

Technisch wird der Weg von Code zu Betrieb durch eine CI/CD-Pipeline automatisiert. Dabei werden drei Stufen unterschieden:

• Continuous Integration (CI): Jede Änderung wird mehrmals täglich in den Hauptzweig integriert, automatisch gebaut und getestet.

• Continuous Delivery: Jede Änderung, die die Pipeline besteht, ist jederzeit auslieferbar; die Auslieferung in den Betrieb wird per Knopfdruck ausgelöst.

• Continuous Deployment: Jede bestandene Änderung geht ohne manuellen Schritt automatisch in Betrieb.

Feste Meetings schreibt DevOps nicht vor. Typisch sind kurze Abstimmungen des Teams, Post-Mortems nach Störungen (ohne Schuldzuweisung, blameless) und regelmäßige Auswertungen der Kennzahlen. Die Planung erfolgt meist mit Scrum oder Kanban.

Rollen: gemeinsame Verantwortung statt Übergabe

DevOps ist ausdrücklich keine einzelne Rolle, sondern eine gemeinsame Verantwortung. Trotzdem haben sich Team- und Rollenformen herausgebildet:

Die Teamkultur ist geprägt von gemeinsamer Verantwortung, Vertrauen, Transparenz und einer fehlerfreundlichen Lernkultur. Mit Team Topologies (Matthew Skelton, Manuel Pais, 2019) gibt es ein verbreitetes Modell, wie solche Teams geschnitten werden.

Artefakte: alles als Code

DevOps beschreibt möglichst viel als Code (versioniert, geprüft, automatisch anwendbar):

Die Dokumentation ist leichtgewichtig, aber maschinenlesbar: Was automatisiert ist, ist zugleich dokumentiert und jederzeit reproduzierbar.

Qualität und Test: automatisiert und früh

Qualität entsteht durch Testautomatisierung in der Pipeline, meist nach der Testpyramide: viele schnelle Unit-Tests, weniger Integrationstests, wenige End-to-End-Tests. Tests und Sicherheitsprüfungen werden möglichst früh ausgeführt (Shift Left). Weil Fehler nie ganz vermeidbar sind, sichert DevOps auch den Betrieb ab: Monitoring und Alarme, schnelle Rollbacks, schrittweise Auslieferung an wenige Nutzende (Canary Release), parallele Umgebungen (Blue-Green Deployment) und Funktionsschalter (Feature Toggles). Das Ziel ist nicht nur „keine Fehler“, sondern „Fehler schnell bemerken und beheben“.

Stakeholder: Rückmeldung aus dem Betrieb

Stakeholder sind über das Vorgehensmodell der Planung (z. B. Scrum) eingebunden. DevOps ergänzt eine zweite Feedback-Quelle: echte Nutzungsdaten aus dem Betrieb, etwa Fehlerraten, Antwortzeiten oder die Nutzung neuer Funktionen. Mit A/B-Tests lässt sich prüfen, welche Variante einer Funktion besser angenommen wird. Weil Änderungen klein und häufig ausgeliefert werden, sehen Kundschaft und Fachbereiche neue Funktionen oft schon nach Stunden oder Tagen.

Planung und Kontrolle: die DORA-Kennzahlen

DevOps plant meist mit agilen Methoden und misst die Lieferfähigkeit eines Teams. Bekannt sind die Kennzahlen des Forschungsprogramms DORA (DevOps Research and Assessment), die seit 2024 in fünf Kennzahlen gefasst sind:

Die DORA-Studien zeigen, dass schnelle und stabile Auslieferung kein Widerspruch ist: Teams mit hohem Durchsatz haben oft auch weniger Fehler. Dazu kommen Betriebskennzahlen wie Verfügbarkeit, Antwortzeiten und vereinbarte Zuverlässigkeitsziele (Service Level Objectives).

Skalierung und Anpassbarkeit: vom Team zur Plattform

DevOps skaliert über Plattformen: Ein Plattformteam stellt Pipelines, Umgebungen und Werkzeuge bereit, die viele Produktteams in Selbstbedienung nutzen (Platform Engineering). Typische Erweiterungen sind DevSecOps (Sicherheit), GitOps (der Zustand des Betriebs wird über ein Git-Repository gesteuert), MLOps (Betrieb von KI-Modellen) und SRE. In skalierten Rahmenwerken wie SAFe ist DevOps als Continuous Delivery Pipeline eingebaut (siehe SAFe). Auch klassisch geplante Projekte können DevOps-Praktiken wie Automatisierung und Monitoring übernehmen.

Häufig genutzte Techniken

• Versionsverwaltung mit Git und kurzlebigen Zweigen (Trunk-based Development),

• CI/CD-Werkzeuge wie GitLab CI, GitHub Actions oder Jenkins,

• Container und Container-Orchestrierung,

• Infrastructure as Code und Konfigurationsmanagement,

• Monitoring, Logging und Tracing (Observability),

• Feature Toggles, Canary Releases, Blue-Green Deployment,

• Chaos Engineering: Ausfälle gezielt herbeiführen, um die Robustheit zu testen.

Ein Beispiel für eine Pipeline: Die Artikel von oer-informatik.de werden bei jeder Änderung von einer GitLab-CI-Pipeline automatisch mit pandoc gebaut und bereitgestellt.

Risiken, Stärken und Grenzen

Häufige Stolpersteine: DevOps wird auf Werkzeuge reduziert („Wir haben jetzt Jenkins, also machen wir DevOps“) oder auf eine neue Abteilung, die zur nächsten Mauer wird; die Automatisierung wird gebaut, aber die Testabdeckung ist zu gering; Entwickler*innen werden mit Rufbereitschaft überlastet; Sicherheit und Datenschutz kommen zu spät.

Typische Gegenmaßnahmen: mit Kultur und gemeinsamen Zielen beginnen, kleine Schritte automatisieren und messen, Testautomatisierung zuerst ausbauen, Plattformteams für Werkzeuge, faire Rufbereitschaftsregeln, Sicherheit in die Pipeline integrieren.

Stärken: kurze Zeit von der Idee bis zum Nutzen, häufige und risikoarme Auslieferungen, schnelle Fehlerbehebung, reproduzierbare Umgebungen, enge Rückkopplung zwischen Betrieb und Entwicklung.

Grenzen: DevOps regelt nicht, wie Anforderungen geplant werden (dafür braucht es z. B. Scrum oder Kanban); hoher Anfangsaufwand für Automatisierung; schwer umsetzbar bei Software, die selten ausgeliefert wird oder bei der Kundschaft installiert wird (z. B. Embedded-Systeme, regulierte Medizinprodukte), dort nur teilweise.

Praxisbeispiele und Anwendungsfelder

DevOps ist Standard bei Webanwendungen, Online-Shops, Streaming- und Cloud-Diensten sowie bei interner Unternehmenssoftware, die laufend weiterentwickelt wird. Beispiel: Das Team von Let’s Meet entwickelt und betreibt seine App selbst; jede Änderung läuft durch eine Pipeline mit automatischen Tests und geht zunächst an fünf Prozent der Nutzenden, bevor sie für alle freigeschaltet wird; ein Dashboard zeigt Fehlerraten und Antwortzeiten. Die Teamgröße entspricht meist der agiler Teams (etwa fünf bis zehn Personen je Produktteam), in großen Unternehmen ergänzt durch Plattform- und SRE-Teams.

Leitfragen

1. Welches Problem löst DevOps, und was bedeutet „You build it, you run it“? Antwort

DevOps überwindet die Trennung zwischen Entwicklung, die häufig liefern will, und Betrieb, der Stabilität sichern soll: Beide tragen gemeinsam die Verantwortung für die Software über ihren ganzen Lebenszyklus. „You build it, you run it“ heißt, dass das Team, das einen Dienst entwickelt, ihn auch betreibt, siehe Abschnitt „Herkunft“ und Abschnitt „Grundprinzipien“.

2. Welche Phasen hat die DevOps-Schleife? Antwort

Plan, Code, Build, Test (Entwicklung) sowie Release, Deploy, Operate, Monitor (Betrieb); danach beginnt der Kreislauf mit den Erkenntnissen aus dem Monitoring erneut, siehe Abschnitt „Ablauf“.

3. Was unterscheidet Continuous Integration, Continuous Delivery und Continuous Deployment? Antwort

Bei Continuous Integration wird jede Änderung häufig integriert, automatisch gebaut und getestet; bei Continuous Delivery ist jede bestandene Änderung jederzeit per Knopfdruck auslieferbar; bei Continuous Deployment geht sie ohne manuellen Schritt automatisch in Betrieb, siehe Abschnitt „Ablauf“.

4. Wie sichert DevOps die Qualität? Antwort

Durch automatisierte Tests in der Pipeline nach der Testpyramide und möglichst früh (Shift Left), dazu durch Monitoring, Rollbacks, Canary Releases, Blue-Green Deployment und Feature Toggles, damit Fehler im Betrieb schnell bemerkt und behoben werden, siehe Abschnitt „Qualität und Test“.

5. Welche DORA-Kennzahlen gibt es, und was sagen sie aus? Antwort

Change Lead Time, Deployment Frequency und Failed Deployment Recovery Time messen den Durchsatz, Change Fail Rate und Deployment Rework Rate die Instabilität. Zusammen zeigen sie, wie schnell und wie stabil ein Team Änderungen in Betrieb bringt, siehe Abschnitt „Planung und Kontrolle“.

6. Wofür steht CALMS? Antwort

Culture (gemeinsame Verantwortung, Lernkultur), Automation (Build, Test, Bereitstellung, Infrastruktur), Lean (kleine Änderungen, wenig Wartezeit), Measurement (Fluss und Betrieb messen) und Sharing (Wissen und Verantwortung teilen), siehe Abschnitt „Grundprinzipien“.

7. Wie verhält sich DevOps zu Scrum, und wo liegen seine Grenzen? Antwort

DevOps ergänzt agile Modelle um den Weg bis in den Betrieb und zurück, regelt aber nicht, wie Anforderungen geplant werden; dafür wird meist Scrum oder Kanban genutzt. Grenzen sind der hohe Anfangsaufwand für Automatisierung und Software, die selten ausgeliefert oder bei der Kundschaft installiert wird, siehe Abschnitt „Risiken, Stärken und Grenzen“.

Links und weitere Informationen

• Vorgehensmodelle: klassisch und agil (Überblick und Vergleich)

• Scrum, Kanban und Extreme Programming

• als Nachschlagewerk: DORA – DevOps Research and Assessment (Kennzahlen und jährliche Berichte)

• für den Einstieg: Gene Kim, Kevin Behr, George Spafford: The Phoenix Project. IT Revolution Press, 2013 (Roman)

• zum Weiterlesen: Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren: The DevOps Handbook. 2. Auflage, IT Revolution Press, 2021

• zum Weiterlesen: Nicole Forsgren, Jez Humble, Gene Kim: Accelerate. IT Revolution Press, 2018

• zum Weiterlesen: Jez Humble, David Farley: Continuous Delivery. Addison-Wesley, 2010

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “DevOps: Entwicklung und Betrieb als ein Team” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/devops veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 30.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]