Was ist DevOps? Kultur, Prozesse und Tools einfach erklärt

Was ist DevOps?

DevOps ist eine Kultur und eine Sammlung von Praktiken, bei denen Softwareentwicklung (Dev) und Betrieb (Ops) gemeinsam Verantwortung tragen, Wiederkehrendes automatisieren und aus ständigem Feedback lernen. Ziel ist es also, Software häufiger, in kleineren Schritten und mit weniger Risiko auszuliefern. DevOps ist also eine Arbeitsweise, kein Werkzeug und kein Jobtitel.

Ein Alltagsbild beantwortet die Frage was ist DevOps dann sofort. In einem Restaurant kochen die Köche, und die Kellner servieren. Wenn beide Gruppen nie miteinander reden, landen kalte Teller und falsche Bestellungen auf dem Tisch. DevOps stellt daher Küche und Gastraum hinter ein gemeinsames Ziel. Dadurch kommt das Essen schnell und richtig an.

Konkret ist die Küche in der Software das Team, das den Code schreibt. Der Gastraum ist die Seite, die diesen Code zu den Nutzern bringt und am Laufen hält. Zunächst erklären wir in diesem Leitfaden Kultur, Lebenszyklus, Kernpraktiken und Messgrößen. Außerdem geben wir eine Starter Roadmap und eine Checkliste für kleine Teams.

Warum entstand DevOps, und wie unterscheidet es sich vom alten Mauermodell?

Im alten Modell bekamen Entwickler Lob für neue Funktionen. Der Betrieb dagegen bekam Lob dafür, dass das System lief. Diese beiden Ziele stehen im Konflikt, denn jede Änderung gefährdet ein laufendes System.

Deshalb wuchs zwischen den Teams eine Mauer. Die Entwickler schlossen den Code ab, warfen ihn über die Mauer und hielten die Arbeit für erledigt. Der Betrieb übernahm ihn dann oft, ohne zu wissen, wie er laufen sollte. Wenn etwas ausfiel, gab jede Seite der anderen die Schuld.

Deshalb will DevOps diese Mauer abbauen. Ein gemeinsames Team verantwortet die Arbeit von der ersten Codezeile bis zum laufenden Dienst. Somit verliert der Satz "bei mir hat es funktioniert" seinen Sinn.

• Zunächst: Im Mauermodell sind Releases selten, groß und riskant.
• Dagegen sind bei DevOps Releases häufig, klein und leicht umkehrbar.
• Außerdem beginnt im Mauermodell nach einem Fehler die Suche nach einem Schuldigen.
• Andererseits beginnt bei DevOps nach einem Fehler die Suche nach einer Prozessverbesserung.

Dieser Unterschied entlastet den Alltag also spürbar. Allerdings entsteht die Entlastung nicht allein durch neue Werkzeuge. Zuerst ändert sich die Haltung, dann unterstützen die Werkzeuge diese neue Haltung.

Was ist DevOps im Kern? Die CALMS Prinzipien

Eine beliebte Merkhilfe für die Prinzipien ist das Kürzel CALMS. Es steht also für Culture, Automation, Lean, Measurement und Sharing. CALMS ist kein offizieller Standard, taugt aber gut als Checkliste in der Praxis.

1. Kultur: Teams fürchten Fehler nicht. Wenn etwas ausfällt, prüfen sie dann den Prozess statt der Person.
2. Automatisierung: Sie überlassen Wiederkehrendes wie Bauen, Testen und Ausliefern den Maschinen.
3. Schlankes Denken: Sie teilen Arbeit daher in kleine Stücke. Zudem streichen Sie Wartezeiten und unnötige Schritte.
4. Messung: Sie entscheiden mit Daten statt nach Bauchgefühl. Sie verfolgen zum Beispiel Auslieferungshäufigkeit und Fehlerquote.
5. Teilen: Teams teilen Wissen, Verantwortung und Ziele offen miteinander.

Diese fünf Ideen hängen also voneinander ab. Ohne Messung wissen Sie zum Beispiel nicht, ob die Automatisierung hilft. Ohne Kultur bleibt das Teilen auf dem Papier.

Wie sieht eine DevOps Kultur im Alltag aus?

Kultur klingt zunächst abstrakt. In der Praxis hinterlässt sie jedoch sichtbare Spuren, und ein paar einfache Zeichen verraten, ob ein Team sie lebt.

Erstens sehen Entwickler, was in der Produktion passiert. Dazu haben sie Zugriff auf Dashboards und verfolgen, wie sich ihr eigener Code im Betrieb verhält. Zweitens sitzen Betriebsexperten in der Planung. So prüft das Team eine Funktion schon im Entwurf auf Betreibbarkeit.

Drittens verzichten Nachbesprechungen nach Störungen auf Schuldzuweisungen. Das Team fragt dann: "Wie hat das System das möglich gemacht?" statt "Wer war das?". Viertens teilt das Team den Bereitschaftsdienst. Denn ein Alarm in der Nacht betrifft alle, die das System bauen, nicht nur eine Person.

Solche Gewohnheiten entstehen nicht über Nacht. Außerdem setzt eine Anweisung der Chefetage sie nicht allein durch. Selbst in einem kleinen Team verändert eine kurze wöchentliche Rückschau die Kultur langsam.

Aus welchen Phasen besteht der DevOps Lebenszyklus?

Den DevOps Lebenszyklus zeichnet man meist als Unendlichkeitsschleife. Die Arbeit endet nie, denn was Sie aus dem Betrieb lernen, speist die nächste Planung. Quellen benennen die Phasen leicht unterschiedlich, dennoch bleibt die Logik gleich.

In diesem Leitfaden nutzen wir sieben Phasen: planen, programmieren, bauen, testen, ausliefern, betreiben und beobachten. Microsoft Learn fasst dieselbe Schleife in vier Abschnitte: Planung, Entwicklung, Auslieferung und Betrieb. Beide Darstellungen tragen also denselben Gedanken.

Jede Phase speist die nächste. Die letzte zählt besonders, denn die Beobachtung startet die Schleife neu.

Was passiert beim Planen und Programmieren?

Beim Planen zerlegt das Team eine Änderung in kleine, messbare Teile. Statt eine große Funktion auf einmal zu liefern, teilen Sie sie dann in mehrere kleine Schritte. Dann testen Sie jeden Schritt einzeln und nehmen ihn bei Bedarf zurück. Agile Methoden wie Scrum helfen dabei, und wir behandeln sie in unserem Leitfaden zu Scrum und Kanban.

Im Mittelpunkt des Programmierens steht die Versionskontrolle. Sie halten jede Änderung fest, ein Kollege prüft sie, und erst danach fließt sie in den Hauptcode. Somit trägt die Versionskontrolle fast alle anderen DevOps Praktiken. Schließlich lesen automatische Builds, Tests und Infrastrukturbeschreibungen aus demselben Repository.

In dieser Phase schützt das Team den Gedanken einer einzigen funktionierenden Quelle. Deshalb halten Sie Zweige kurz und führen oft zusammen. Zweige, die lange getrennt leben, verursachen beim Zusammenführen große Überraschungen. Kleine und häufige Merges sind also eine der einfachsten DevOps Gewohnheiten.

Was passiert beim Bauen, Testen und Ausliefern?

Beim Bauen wird aus geschriebenem Code ein lauffähiges Paket. Wenn Sie das von Hand tun, schleichen sich jedes Mal kleine Unterschiede ein. Ein automatischer Build folgt dagegen immer denselben Schritten in derselben Reihenfolge. Das heißt, das Problem "bei mir lief es" verschwindet größtenteils.

Beim Testen übernehmen dann automatische Tests. Unit Tests prüfen kleine Codeteile, während Integrationstests prüfen, wie die Teile zusammenarbeiten. Je früher ein Test läuft, desto günstiger ist die Korrektur. Zudem können Sie Sicherheitsscans in diese Phase einbauen.

Beim Ausliefern bringen Sie das Paket Schritt für Schritt über die Testumgebung in die Produktion. Diese automatische Kette erklären wir ausführlich in unserem CI/CD Leitfaden. Hier nennen wir daher nur ihre Rolle. Zunächst führt Continuous Integration Änderungen oft zusammen und testet sie. Danach hält Continuous Delivery ein freigegebenes Paket bereit.

Feature Flags senken außerdem das Risiko. Sie liefern neuen Code ausgeschaltet aus und schalten ihn ein, wenn Sie bereit sind. Diese Idee behandeln wir im Beitrag Was ist ein Feature Flag.

Was passiert beim Betreiben und Beobachten?

Wenn die Auslieferung endet, beginnt also die eigentliche Verantwortung. Beim Betreiben hält das Team den Dienst für die Nutzer verfügbar. Zum Beispiel gehören Kapazität, Backups, Sicherheitsupdates und Störungsbehandlung dazu. Wo die Anwendung läuft, auf dem eigenen Server oder in einem Cloud Dienst, bestimmt die Betriebslast. Diese Wahl erklärt unser Leitfaden zu IaaS, PaaS und SaaS.

Beobachten heißt, das echte Verhalten des Systems zu verfolgen. Konkret liefern Logs, Metriken und Traces dafür den Rohstoff. Außerdem sollten Alarme nur auslösen, wenn jemand wirklich handeln muss. Sonst stumpft das Team ab und übersieht die wichtige Warnung.

Die Beobachtungsdaten fließen dann in die nächste Planung. Wenn eine Seite zum Beispiel langsam lädt, planen Sie ihre Verbesserung im nächsten Durchlauf. Vertiefend lesen Sie dazu unseren Beitrag über Observability und OpenTelemetry.

Welche Kernpraktiken beantworten die Frage was ist DevOps im echten Projekt?

DevOps ist nicht eine einzige Praktik, sondern ein Bündel, das sich ergänzt. Die offiziellen Dokumente von AWS und Microsoft nennen eine ähnliche Liste: kontinuierliche Integration und Auslieferung, Infrastruktur als Code, Konfigurationsmanagement, Microservices, Monitoring und Logging sowie Kommunikation und Zusammenarbeit. Wir stellen daher jede kurz vor und verlinken auf einen vertiefenden Beitrag.

• CI/CD: Baut, testet und bereitet jede Änderung für die Auslieferung vor. Mehr dazu im Beitrag zu CI/CD.
• Infrastructure as Code: Sie legen Server und Netze über Beschreibungsdateien unter Versionskontrolle an, nicht von Hand. Das erklärt unser Leitfaden zu Infrastructure as Code.
• Container: Bündeln eine Anwendung mit ihren Abhängigkeiten, damit sie überall gleich läuft. Einen guten Einstieg bietet unser Docker und Container Leitfaden.
• Observability: Lässt Sie von außen verstehen, was im Inneren eines Systems passiert.
• Microservices: Teilen eine große Anwendung in kleine Dienste, die Sie unabhängig ausliefern. Vor- und Nachteile zeigt unser Vergleich von Microservices und Monolith.

Sie müssen nicht alles auf einmal einführen. Die meisten Teams starten zunächst mit Versionskontrolle und automatischen Tests. Danach ergänzen sie CI/CD und Monitoring.

Was sind DORA Kennzahlen, und wie zeigen sie den DevOps Erfolg?

DORA (DevOps Research and Assessment) ist ein langjähriges Forschungsprogramm, das heute zu Google Cloud gehört. Das bekannteste Ergebnis ist also eine kleine Gruppe von Kennzahlen für die Lieferleistung von Software. Sie teilen sich somit in zwei Gruppen: Durchsatz und Stabilität.

Laut dem offiziellen DORA Leitfaden gehören zum Durchsatz drei Größen: Durchlaufzeit einer Änderung, Auslieferungshäufigkeit und Wiederherstellungszeit nach einer fehlgeschlagenen Auslieferung. Zudem zählen zur Stabilität zwei Größen: die Fehlerquote von Änderungen und die Quote ungeplanter Nacharbeit. Früher sprach man zum Beispiel von "vier Schlüsselkennzahlen", und die Liste ist inzwischen gewachsen. Prüfen Sie deshalb die aktuellen Namen und Definitionen auf der offiziellen DORA Seite zu den Kennzahlen.

Die Stärke dieser Größen liegt darin, dass sie Tempo und Stabilität zusammen zeigen. Ein Team, das schnell liefert und ständig Fehler produziert, steht nicht gut da. Ebenso hat ein Team, das nie etwas kaputt macht, aber nur einmal im Jahr ausliefert, seine Beweglichkeit verloren. Also beobachten Sie beide Gruppen nebeneinander.

Hinweis: Wir nennen hier bewusst keine Schwellen oder Zielwerte. Denn jedes Team hat seinen eigenen Kontext. Messen Sie zuerst Ihren Ausgangspunkt, und vergleichen Sie sich dann mit Ihrer eigenen Vergangenheit. Wenn Sie die Kennzahlen zum Wettbewerb zwischen Teams machen, schadet das der Kultur.

Was ist DevOps im Vergleich zu DevSecOps und SRE?

Benachbarte Begriffe werden oft verwechselt, deshalb klären wir sie. DevSecOps bedeutet, Sicherheit in jede Phase zu tragen, statt sie ans Ende zu schieben. SRE (Site Reliability Engineering) ist Googles Disziplin, die den Betrieb als Softwareengineering Problem behandelt. Das SRE Buch von Google beschreibt beide als Verwandte mit gemeinsamen Prinzipien, nicht als Rivalen.

Die Tabelle zeigt eine Lehre: Diese Ideen ergänzen sich und ersetzen sich nicht. DevSecOps ist also eine Erweiterung mit Sicherheitsfokus. Eine konkrete Liste typischer Schwachstellen finden Sie in unserem Leitfaden zu den OWASP Top 10. SRE dagegen steuert die Zuverlässigkeit mit messbaren Zielen. Die Einleitung des SRE Buchs von Google erklärt den Unterschied.

Ist DevOps dasselbe wie Agile?

Nein, aber beide sind eng verwandt. Agile fragt zunächst, wie Sie Software planen und entwickeln. Dazu zählen vor allem kurze Zyklen, Kundenfeedback und Offenheit für Änderungen. Wer fragt, was ist DevOps neben Agile, erkennt den Unterschied schnell: DevOps fragt, wie diese Software in die Produktion kommt und dort lebt.

Noch ein Bild, dann wird es klar. Agile heißt, das Essen in kleinen Portionen zu kochen, während der Gast mitprobiert. DevOps heißt, diese Portionen schnell, warm und ohne Probleme von der Küche an den Tisch zu bringen. Zusammen sorgen beide also dafür, dass Sie das richtige Produkt bauen und pünktlich liefern.

Auch Microsoft Learn zählt Agile zu den DevOps Praktiken. Anders gesagt, Agile ist in vielen Teams das Planungsbein von DevOps. Ein Team ohne Agile kann trotzdem von DevOps profitieren. Wer beides nutzt, verbessert allerdings den Wertstrom von Anfang bis Ende.

Was macht ein DevOps Engineer?

Ein DevOps Engineer schließt die Lücke zwischen Entwicklung und Betrieb. Allerdings nutzt die Branche diesen Titel auf sehr unterschiedliche Weise. Zum Beispiel baut diese Person in manchen Firmen die Auslieferungspipeline. Anderswo verwaltet sie die Cloud Infrastruktur. Wieder andere Firmen sehen sie als Plattformteam, das anderen Teams Werkzeuge und Schulung gibt.

Im Allgemeinen umfasst die Rolle oft diese Aufgaben:

• Pipelines für Bauen, Testen und Ausliefern aufbauen und pflegen.
• Infrastruktur als Code beschreiben und Umgebungen somit wiederholbar machen.
• Außerdem Monitoring, Logging und Alarme einrichten.
• Zudem Sicherheitsscans in die Pipeline einbinden.
• Bei Störungen mit den Teams zusammenarbeiten und danach den Prozess verbessern.

Eine wichtige Warnung: DevOps ist nicht die Aufgabe einer einzelnen Person. Denn der Titel "DevOps Engineer" entbindet den Rest des Teams nicht von der Verantwortung. Sonst bauen Sie nur eine neue Mauer. Gehälter oder Marktwerte nennen wir hier nicht, weil diese Zahlen je nach Region und Zeit stark schwanken.

Wie gehört DevOps mit Containern und Orchestrierung zusammen?

Ein Container packt eine Anwendung also mit allem, was sie braucht, in ein Bündel. Deshalb läuft die App vom Laptop des Entwicklers auch in Test und Produktion gleich. Das ist eines der stärksten Mittel gegen das Problem "bei mir lief es". Die Grundlagen finden Sie dort in unserem Docker Leitfaden.

Wenn Sie viele Container betreiben, brauchen Sie eine Schicht, die sie startet, überwacht und neu startet. Diese Schicht heißt daher Orchestrierung, und Kubernetes ist das bekannteste Beispiel. Den Unterschied erklärt unser Beitrag Docker und Kubernetes im Vergleich.

Ein fairer Hinweis: Container und Orchestrierung sind keine Pflicht für DevOps. Eine kleine Anwendung lässt sich zum Beispiel auch ohne Container gesund ausliefern. Diese Werkzeuge helfen Ihnen vielmehr, Komplexität zu beherrschen, wenn Team und Last wachsen. Fügen Sie deshalb keine Komplexität hinzu, bevor Sie sie brauchen.

Wie gehen Sie mit Sicherheit in einem DevOps Team um?

Im alten Ansatz fand zunächst die Sicherheitsprüfung direkt vor dem Release statt, als letzte Station. Diese Kontrolle kommt allerdings zu spät. Ein Fund kostet dann viel und verzögert die Auslieferung. Der DevOps Ansatz verschiebt Sicherheit nach links, also in die frühen Phasen.

In der Praxis ist die Idee einfach. Erstens stellen Sie im Code Review eine Sicherheitsfrage. Zweitens scannen Sie Abhängigkeiten in der Pipeline auf bekannte Schwachstellen. Drittens bewahren Sie also geheime Schlüssel an einem getrennten, geschützten Ort auf statt im Code. Viertens begrenzen Sie dann Zugriffsrechte auf das, was jede Person braucht.

Zusammen bilden diese Gewohnheiten somit DevSecOps. Die Sicherheitsfachleute sitzen daher schon bei Planung und Entwurf am Tisch. Somit ist Sicherheit nicht mehr die Bremse, sondern eines der gemeinsamen Qualitätsziele.

Hinweis: Dieser Beitrag ist keine Rechts oder Prüfberatung. Für Pflichten Ihrer Branche sprechen Sie mit einer qualifizierten Fachperson.

Wie verteilen sich Rollen und Verantwortung in einem DevOps Team?

DevOps erwartet nicht, dass jeder alles kann. Es erwartet, dass jeder die ganze Arbeit sieht und zum gemeinsamen Ziel beiträgt. Fachwissen bleibt also wichtig. Neu ist dagegen, dass Fachleute nicht mehr isoliert arbeiten.

Der Entwickler kümmert sich zunächst darum, wie sich sein Code in der Produktion verhält. Dann steuert der Betriebsexperte die Zuverlässigkeit von Pipeline und Infrastruktur. Ein Testexperte entwirft die automatische Teststrategie, und der Sicherheitsexperte setzt Kontrollen in die Pipeline. Schließlich legt der Product Owner die Prioritäten fest.

Dort, wo sich diese Rollen überschneiden, entsteht somit gemeinsame Verantwortung. Wenn zum Beispiel ein Alarm kommt, übernimmt das Team die Lösung, das sich für den Dienst zuständig fühlt. Bereitschaftsplan, Nachbesprechungen und gemeinsame Dashboards stärken diese Verantwortung.

In kleinen Teams übernimmt eine Person oft mehrere Rollen. Das ist völlig normal, denn kleine Teams haben wenige Köpfe. Wichtig ist, dass die Rollen in Wissen und Verantwortung nicht voneinander abgeschottet bleiben.

Beispielszenario: Wie kann ein kleines E-Commerce Team zu DevOps wechseln?

Dies ist ein Beispielszenario und keine echte Kundengeschichte. Stellen Sie sich also ein kleines Team vor, das die Software seines eigenen Onlineshops baut. Es liefert zum Beispiel einmal im Monat nachts am Wochenende aus, und zwar von Hand. Jedes Release bringt ein paar kleine Fehler, und das Team verbringt den Montag mit Korrekturen.

Zunächst legt das Team den gesamten Code unter Versionskontrolle und prüft gegenseitig die Änderungen. Danach schreibt es automatische Tests für die wichtigsten Abläufe. Zum Beispiel laufen die Schritte "In den Warenkorb" und "Bezahlen" nun bei jeder Änderung automatisch durch.

Im dritten Schritt bindet das Team die Auslieferung an einen einzigen Befehl und übt den Rollback. Danach kommen die Releases wöchentlich, später täglich. Weil jedes Release kleiner ist, findet das Team die Ursache eines Fehlers schnell. Schließlich richtet es Monitoring ein und definiert einen Alarm für die Fehlerquote beim Bezahlen.

Am Ende verzichtet das Team daher auf das Wochenend Release. Denn kein Schritt in diesem Szenario braucht ein teures Werkzeug. Das meiste ist also eine Frage von Gewohnheit und Reihenfolge. Wir machen keine Aussage über Zahlen, denn die Ergebnisse unterscheiden sich in jedem Team.

Wann hilft DevOps, und wo liegen seine Grenzen?

DevOps schafft vor allem Nutzen bei Software, die sich oft ändert und Nutzer ständig bedient. Zum Beispiel zählen Webanwendungen, Backends für mobile Apps und SaaS Produkte dazu. Je öfter Sie etwas ändern, desto größer ist der Gewinn durch Automatisierung.

Andererseits hat DevOps Grenzen. Eine volle Pipeline kann für eine kleine Firmenwebsite, die Sie einmal im Jahr aktualisieren, unnötiger Ballast sein. Trotzdem helfen Versionskontrolle, Backups und einfaches Monitoring auch dort. Denken Sie DevOps also nicht als Alles oder Nichts.

In regulierten Bereichen, etwa bei Systemen mit personenbezogenen Daten, baut das Team Freigabe und Prüfschritte in die Pipeline ein. Das widerspricht DevOps also nicht. Im Gegenteil, Automatisierung macht die Nachweise verlässlicher. Für die rechtliche Einhaltung fragen Sie eine qualifizierte Beratung.

Schließlich ist DevOps keine Abkürzung. Wer ein fehlerhaftes System automatisiert, erzeugt somit dessen Probleme nur schneller. Verstehen Sie deshalb zuerst den Prozess, und automatisieren Sie ihn dann.

Was ist DevOps in der Praxis: Wie sieht die Roadmap für ein kleines Team aus?

Der größte Vorteil eines kleinen Teams ist, dass die Mauer ohnehin dünn ist. Daher passt die folgende Roadmap zu allen, die ohne schweres Transformationsprojekt starten wollen. Jeder Schritt baut also auf dem vorherigen auf.

1. Zunächst sammeln Sie allen Code und alle Konfigurationsdateien in einem Versionskontrollsystem.
2. Dann führen Sie für jede Änderung ein kurzes Code Review ein.
3. Danach lassen Sie den Build und die Basistests automatisch laufen.
4. Richten Sie eine Testumgebung ein, die der Produktion möglichst ähnelt.
5. Ermöglichen Sie die Auslieferung mit einem einzigen Befehl oder Knopf.
6. Außerdem üben Sie den Weg zurück, bevor Sie ihn brauchen.
7. Richten Sie Monitoring und Alarme ein, und lassen Sie nur die wirklich wichtigen aktiv.
8. Schließlich halten Sie nach jeder Störung eine kurze Rückschau ohne Schuldzuweisung.

Ändern Sie diese Reihenfolge daher nicht. Wenn Sie automatische Releases ohne Tests bauen, liefern Sie die Fehler ebenfalls automatisch aus. Ebenso verunsichern häufige Releases ohne Weg zurück das Team.

Infrastruktur als Code und Container folgen später. Steigen Sie also erst ein, wenn Sie sie brauchen. Wer am ersten Tag alles aufbauen will, ermüdet nur das Team.

Wie sieht eine Checkliste für Teams aus, die fragen was ist DevOps?

Die Liste unten zeigt Ihnen, wo Ihr Team heute steht. Zunächst beantworten Sie jeden Punkt mit Ja, Teilweise oder Nein. Danach notieren Sie jedes Nein als Kandidaten für die nächste Verbesserung.

• Liegen der gesamte Code und alle Konfigurationen unter Versionskontrolle?
• Prüft außerdem jemand anderes jede Änderung?
• Laufen Builds und Tests automatisch statt von Hand?
• Sind Ihre Auslieferungsschritte aufgeschrieben und wiederholbar?
• Können Sie ein Release in kurzer Zeit zurücknehmen?
• Haben Sie ein Monitoring, das zeigt, was in der Produktion passiert?
• Sind Ihre Alarme sinnvoll, oder erzeugen sie ständig Rauschen?
• Verbessern Sie nach Störungen dann den Prozess?
• Kennen Sie schließlich Ihre Auslieferungshäufigkeit und Ihre Fehlerquote?
• Laufen Sicherheitsprüfungen innerhalb der Pipeline?

Sieben oder mehr Ja Antworten sind ein gutes Zeichen. Allerdings ist das keine Bewertung, sondern ein Gesprächsstarter. Entscheidend ist also, dass Sie die Liste gemeinsam mit Ihrem Team ausfüllen.

Welche Fehler machen Teams bei der Einführung von DevOps?

Viele Teams stolpern an denselben Stellen. Die Fehler zu kennen ist daher der erste Schritt, sie zu vermeiden.

• Mit Werkzeugen beginnen: Sie kaufen zuerst ein Tool und erwarten dann, dass der Prozess dazu passt.
• Ein neues Silo schaffen: Sie gründen ein DevOps Team und entlasten alle anderen von der Verantwortung.
• Nicht messen: Das heißt, Sie ändern Dinge, ohne zu wissen, ob etwas besser wird.
• Sicherheit ans Ende schieben: Sie führen alle Scans einmal direkt vor dem Release durch.
• Alles auf einmal ändern: Sie rufen den Wandel für die ganze Firma aus, statt klein zu pilotieren.
• Die Schuldkultur behalten: Sie suchen nach einer Störung eine Person und ignorieren den Prozess.

Alle diese Fehler haben eine Wurzel: Sie überspringen die Kultur. Ein Werkzeug kaufen Sie dagegen leicht. Eine Gewohnheit wächst jedoch nur mit Zeit und Vorbild.

Wo bekommen Sie Unterstützung für DevOps in einem Softwareprojekt?

Wenn Sie ein eigenes Team haben, starten Sie mit der Checkliste oben und halten Ihren Ist Zustand fest. Danach automatisieren Sie den einen Schritt, der am meisten Zeit kostet. Meist ist das also die manuelle Auslieferung oder der von Hand gestartete Test.

Wenn Sie kein fertiges Team haben und eine individuelle Software brauchen, denken wir als Talha Aslan und Team den Auslieferungsprozess von Projektbeginn an mit. Das tun wir in unserer individuellen Softwareentwicklung. Wenn Architektur, Versionskontrolle, Tests und Auslieferung gemeinsam entstehen, brauchen Sie später keine nachträglichen Flicken. Dennoch ist jedes Projekt anders, deshalb hören wir zuerst zu.

Auch die Kommunikation zwischen Diensten beeinflusst den Auslieferungsprozess. Wenn Sie zum Beispiel die Schnittstelle eines Dienstes ändern, können alle Dienste ausfallen, die sie nutzen. Den Begriff erklären wir im Beitrag Was ist eine API. Änderungen in der Datenschicht bergen ein ähnliches Risiko, und diese Wahl behandelt unser Vergleich von NoSQL und SQL.

Was ist DevOps in Kürze?

Kurz gesagt ist DevOps eine Arbeitsweise, die Entwicklung und Betrieb durch gemeinsame Verantwortung verbindet. Kultur, Automatisierung, Messung und Teilen bilden also die Basis. Der Lebenszyklus reicht vom Planen bis zum Beobachten, und was Sie beim Beobachten lernen, speist den nächsten Plan.

Bei den Praktiken fallen Versionskontrolle, CI/CD, Infrastructure as Code, Container und Observability auf. Den Erfolg verfolgen Sie mit den DORA Kennzahlen, die Tempo und Stabilität zusammen zeigen. DevSecOps vertieft also die Sicherheit, SRE vertieft die Zuverlässigkeit. Beide stehen neben DevOps, nicht an seiner Stelle, folglich ergänzen sie es.

Fangen Sie deshalb klein an: Versionskontrolle, automatische Tests und eine Auslieferung in einem Schritt. Danach messen, lernen und erweitern Sie. Entscheidend ist, dass die Gewohnheit der Zusammenarbeit Wurzeln schlägt, nicht die Werkzeuge. Als Quellen empfehlen wir die DevOps Definition von AWS und die DevOps Übersicht von Microsoft Learn. Beide bieten zudem einen neutralen Einstieg.