DevOps beschleunigt die Bereitstellung qualitativ hochwertigerer Software, indem die Prozesse zwischen Softwareentwicklung und operationalen IT-Teams kombiniert und automatisiert werden.

DevOps beschreibt – per definitionem – sowohl einen Softwareentwicklungsprozess als auch einen Kulturwandel im Unternehmen, der die Lieferung qualitativ hochwertigerer Software beschleunigt, indem die Prozesse zwischen Teams in der Softwareentwicklung und im IT-Betrieb kombiniert und automatisiert werden – also von zwei Gruppen, die traditionell getrennt voneinander oder in Silos gearbeitet haben.

In der Praxis gehen die besten DevOps-Prozesse und -Kulturen über die Entwicklung und den Betrieb hinaus. Sie beziehen die Beiträge aller an der Anwendung Beteiligten – einschließlich Plattform- und Infrastruktur-Engineering, Sicherheit, Compliance, Governance, Risikomanagement, Geschäftsleitung, Endbenutzer und Kunden – in den Lebenszyklus der Softwareentwicklung mit ein.

DevOps stellt den aktuellen Stand der Evolution der Software-Bereitstellungszyklen in den letzten 20+ Jahren dar: von riesigen anwendungsweiten Code-Releases im Abstand von einigen Monaten oder sogar Jahren zu iterativen kleineren Feature- oder Funktions-Updates, die täglich oder sogar mehrmals täglich veröffentlicht werden.

Letztlich geht es bei DevOps darum, die ständig steigenden Anforderungen der Software-Anwender an häufige, innovative neue Funktionen und ununterbrochene Leistung und Verfügbarkeit zu erfüllen.

Bis kurz vor dem Jahr 2000 wurde der Großteil der Software nach der Wasserfallmethode entwickelt und aktualisiert, d. h. nach einem linearen Ansatz für groß angelegte Entwicklungsprojekte. Teams in der Softwareentwicklung verbrachten normalerweise Monate damit, große Mengen an neuem Code zu entwickeln, der den Großteil oder die gesamte Anwendung betraf. Da die Änderungen so umfangreich waren, verbrachten sie mehrere weitere Monate damit, diesen neuen Code in die Codebasis zu integrieren. 

Als nächstes verbrachten die Teams für Qualitätssicherung (QA), Sicherheit und Betrieb weitere Monate damit, den Code zu testen. Dadurch lagen Monate oder sogar Jahre zwischen den einzelnen Software-Releases und oft mussten zwischen den Releases auch mehrere wichtige Patches oder Fehlerbehebungen bereitgestellt werden. Und dieser „Big Bang“-Ansatz, d. h. die Strategie für die „urknallartige“ Bereitstellung von Features, war oft von komplexen und riskanten Implementierungsplänen, von einem schwer zu terminierenden Ineinandergreifen von vorgelagerten und nachgelagerten Systemen, und der „großen Hoffnung“ der IT-Abteilung gekennzeichnet, dass sich die Geschäftsanforderungen in den Monaten vor dem Produktionsstart nicht drastisch geändert hatten.

Um die Entwicklung zu beschleunigen und die Qualität zu verbessern, begannen Entwicklungsteams damit, agile Softwareentwicklungsmethoden einzusetzen, die eher iterativ als linear sind und sich auf kleinere, häufigere Aktualisierungen der Anwendungscodebasis konzentrieren. Die wichtigsten dieser Methoden sind CI/CD, d. h. Continuous Integration (Kontinuierliche Integration) und Continuous Delivery (Kontinuierliche Bereitstellung). Im Rahmen von CI/CD werden kleinere Teile des neuen Codes alle ein bis zwei Wochen in die Codebasis eingebunden und dann automatisch integriert, getestet und für die Bereitstellung in der Produktionsumgebung vorbereitet. Agile Softwareentwicklung entwickelte den „Big Bang“-Ansatz in mehrere „kleinere Vorfälle“, wodurch auch die Risiken aufgeteilt werden.

Je effektiver diese agilen Entwicklungspraktiken die Softwareentwicklung und -bereitstellung beschleunigten, desto mehr entlarvten sie den noch isolierten IT-Betrieb – Systembereitstellung, Konfiguration, Abnahmetests, Management, Überwachung – als nächsten Engpass im Lebenszyklus der Softwarebereitstellung. 

DevOps hat also seinen Ursprung in der agilen Softwareentwicklung. Es wurden neue Prozesse und Tools hinzugefügt, die die kontinuierliche Iteration und Automatisierung von CI/CD auf den Rest des Lebenszyklus der Softwarelieferung ausweiteten. Und es wurde die enge Zusammenarbeit zwischen Entwicklungs- und Betriebsteams bei jedem Schritt des Prozesses eingeleitet.

Der DevOps-Lebenszyklus (manchmal auch als „Continuous-Delivery-Pipeline“, also Pipeline für kontinuierliche Bereitstellung bezeichnet, wenn er linear dargestellt wird) ist eine Reihe von iterativen, automatisierten Entwicklungsprozessen oder Workflows, die im Rahmen eines größeren, automatisierten und iterativen Entwicklungszyklus ausgeführt werden, der wiederum die schnelle Bereitstellung von qualitativ hochwertiger Software optimieren soll. Der Name und die Anzahl der Workflows können variieren, je nachdem, wen Sie fragen, aber in der Regel geht es im Wesentlichen um die folgenden sechs Workflows:

• Planung (oder Ideenbildung). In diesem Arbeitsablauf skizzieren die Teams neue Features und Funktionalitäten für das nächste Release, wobei sie sich auf priorisiertes Endbenutzer-Feedback und Fallstudien sowie auf Inputs von allen internen Stakeholdern stützen. Das Ziel in der Planungsphase besteht darin, den Geschäftswert des Produkts zu maximieren, indem ein Backlog, eine Liste von noch zu schaffenden Features erstellt wird, die bei der Lieferung ein gewünschtes Ergebnis erzeugen, das Wert für das Unternehmen hat.
  
  
• Entwicklung. Dies ist der Programmierschritt, in dem Entwickler neue und erweiterte Features testen, codieren und erstellen, die auf Benutzergeschichten und im Backlog erfassten Arbeitselementen basieren. Eine Kombination von Verfahren wie z. B. Test-driven Development (TDD, testgesteuerte Entwicklung), Pair Programming (Paarprogrammierung) und Peer-Code-Reviews (Code-Überprüfung durch einen anderen Programmierer) ist dabei häufig anzutreffen. Entwickler verwenden oft ihre lokalen Workstations, um den „internen Loop“ des Schreibens und des Testens von Code auszuführen, bevor sie diesen an die Continuous Delivery Pipeline weitergeben.
  
  
• Integration (oder Continuous Integration und Continuous Delivery (CI/CD)). Wie bereits erwähnt, wird in diesem Workflow der neue Code in die bestehende Codebasis integriert, dann getestet und in eine ausführbare Datei für die Bereitstellung verpackt. Zu den typischen Aktivitäten im Bereich der Automatisierung gehören das Zusammenführen von Codeänderungen in einer „Master“-Kopie, das Auschecken dieses Codes aus einem Quellcode-Repository und das Automatisieren der Kompilierung, des Komponententests und der Verpackung in einer ausführbaren Datei. Die Best Practice besteht darin, das Arbeitsprodukt der CI-Phase in einem binären Repository für die nächste Phase zu speichern.
  
  
• Bereitstellung (meist kontinuierliche Bereitstellung genannt). Hier wird der Runtime-Build-Output (aus der Integration) in einer Laufzeitumgebung bereitgestellt – in der Regel eine Entwicklungsumgebung, in der Laufzeittests für Qualität, Compliance und Sicherheit durchgeführt werden. Wenn Fehler oder Defekte gefunden werden, haben Entwickler die Chance, Probleme zu identifizieren und zu beheben, bevor sie Endbenutzern auffallen. In der Regel gibt es Umgebungen für die Entwicklung, den Test und die Produktion, wobei jede Umgebung zunehmend „strengere“ Quality Gates/Qualitätsstandards erfordert. Ein bewährtes Verfahren für die Bereitstellung in einer Produktionsumgebung besteht darin, zunächst eine Untergruppe von Endbenutzern und dann schließlich alle Benutzer einzubeziehen, sobald die Stabilität hergestellt ist.
  
  
• Betrieb. Wenn das Abrufen von Features, die an eine Produktionsumgebung geliefert werden, als „Tag 1“  gekennzeichnet ist, treten nach der Ausführung von Funktionen in der Produktion „Tag 2“-Vorgänge auf. Das Monitoring der Leistung, des Verhaltens und der Verfügbarkeit von Funktionen stellt sicher, dass die Funktionen den Endnutzern Mehrwert bieten können. Der Betrieb stellt sicher, dass die Features reibungslos laufen und es keine Serviceunterbrechungen gibt, indem sichergestellt wird, dass das Netzwerk, der Speicher, die Plattform, die Datenverarbeitung und die Sicherheitslage alle in einwandfreiem Zustand sind! Wenn ein Problem auftritt, stellt der IT-Betrieb sicher, dass Vorfälle erkannt, das richtige Personal alarmiert, Probleme identifiziert und Korrekturen vorgenommen werden.
  
  
• Lernen (manchmal kontinuierliches Feedback genannt). Dabei handelt es sich um das Sammeln von Feedback von Endanwendern und Kunden zu Features, Funktionalität, Leistung und Geschäftswert, um dieses Feedback in die Planung von Verbesserungen und Features für die nächste Version einfließen zu lassen. Dies umfasst außerdem all das, was der IT-Betrieb selbst aus seinen Aktivitäten gelernt hat, sowie die Elemente, die sich noch im Backlog befinden und die es Entwicklern ermöglichen könnten, proaktiv Vorfälle zu vermeiden, die sich bereits ereignet haben, aber in der Zukunft noch einmal passieren könnten. An genau diesem Punkt findet der erneute Übergang zur Planungsphase statt: „Der Kreis schließt sich“ und wir beginnen den „Prozess der kontinuierlichen Verbesserung“.

Zwischen diesen Workflows laufen drei weitere wichtige kontinuierliche Workflows ab:

Kontinuierliches Testen: Klassische DevOps-Lebenszyklen umfassen eine diskrete „Test“-Phase, die zwischen den Schritten der Integration und der Bereitstellung stattfindet. DevOps ist jedoch nun so weit entwickelt, dass bestimmte Elemente des Testens bereits während der Planung (verhaltensgesteuerte Entwicklung), Entwicklung (Komponententests, Vertragstests), Integration (statische Codescans, CVE-Scans, Linting), Bereitstellung (Rauchtests, Penetrationstests, Konfigurationstests), Operationen (Chaos-Tests, Konformitätsprüfung) und Lernen (A/B-Tests) durchgeführt werden können. Testen ist ein sehr effektives Werkzeug zur Identifizierung von Risiken und Schwachstellen und bietet der IT die Möglichkeit, Risiken entweder zu akzeptieren, zu mindern oder zu beseitigen.

Sicherheit: Während Wasserfallmethoden und agile Implementierungen Sicherheitsabläufe nach der Bereitstellung oder Implementierung „anheften“, ist DevOps bestrebt, Sicherheit von Anfang an (Planung) – wenn Sicherheitsprobleme am einfachsten und am kostengünstigsten zu lösen sind – und kontinuierlich während des gesamten Entwicklungszyklus zu integrieren. Dieses Sicherheitskonzept wird als Linksverschiebung bezeichnet (was leichter zu verstehen ist, wenn Sie sich die Abbildung 1 ansehen). Einige Unternehmen hatten mit diesem Ansatz weniger Erfolg als andere, was zur Entstehung von DevSecOps führte (siehe unten).

Compliance. Regulatorische Compliance (Governance und Risiko) wird idealerweise ebenfalls frühzeitig und während des gesamten Entwicklungslebenszyklus berücksichtigt. Regulierte Branchen sind oft verpflichtet, ein bestimmtes Maß an Beobachtbarkeit, Nachvollziehbarkeit und Zugriff darauf zu gewährleisten, wie Funktionen in ihrer Laufzeitumgebung innerhalb der betrieblichen Abläufe bereitgestellt und verwaltet werden. Dies erfordert Planung, Entwicklung, Testen und Durchsetzung von Richtlinien in der Pipeline für die kontinuierliche Lieferung und in der Laufzeitumgebung. Die Überprüfbarkeit von Compliance-Maßnahmen ist äußerst wichtig, um die Einhaltung von Compliance-Vorschriften gegenüber externen Prüfern beweisen zu können.

Es ist allgemein anerkannt, dass DevOps-Methoden nicht ohne ein Bekenntnis zur DevOps-Kultur funktionieren können, die sich als ein völlig anderer organisatorischer und technischer Ansatz zur Softwareentwicklung zusammenfassen lässt.

Auf organisatorischer Ebene erfordert DevOps eine kontinuierliche Kommunikation, Zusammenarbeit und gemeinsame Verantwortung aller an der Softwarebereitstellung Beteiligten, d. h. der Softwareentwicklungs- und IT-Betriebsteams, aber auch der Sicherheits-, Compliance-, Governance-, Risiko- und Geschäftsleitungsteams, um schnelle und kontinuierliche Innovationen zu erzielen und die Qualität der Software von Anfang an zu gewährleisten.

In den meisten Fällen lässt sich dies am besten erreichen, indem man diese Silos aufbricht und sie in funktionsübergreifende, autonome DevOps-Teams umorganisiert, die von Anfang bis Ende – von der Planung bis zum Feedback – an Code-Projekten arbeiten können, ohne Übergaben an andere Teams vorzunehmen oder auf deren Genehmigungen warten zu müssen. Im Kontext der agilen Entwicklung sind die gemeinsame Verantwortlichkeit und die Zusammenarbeit die Grundlage für einen gemeinsamen Produktfokus, der zu einem wertvollen Ergebnis führt.

Auf technischer Ebene erfordert DevOps ein Engagement für die Automatisierung, die Projekte innerhalb und zwischen Workflows in Bewegung hält. Außerdem sind Feedback und Messungen erforderlich, die es den Teams ermöglichen, die Zyklen kontinuierlich zu beschleunigen und die Softwarequalität und -leistung zu verbessern.

Die Anforderungen von DevOps und der DevOps-Kultur erfordern den Einsatz von Werkzeugen, die asynchrone Zusammenarbeit unterstützen, DevOps-Workflows nahtlos integrieren und den gesamten DevOps-Lebenszyklus so weit wie möglich automatisieren. Zu den Kategorien von DevOps-Tools gehören:

• Projektmanagement-Tools – Ermöglichen es Teams, ein Backlog mit Benutzergeschichten (Anforderungen) zu erstellen, die Codierungsprojekte bilden, diese in kleinere Aufgaben aufzuteilen und die Aufgaben bis zur Fertigstellung zu verfolgen. Viele unterstützen agile Projektmanagement-Praktiken wie Scrum, Lean und Kanban, die Entwickler in DevOps einbringen. Beliebte Open-Source-Optionen sind GitHub Issues und Jira.
  
  
• Kollaborative Quellcode-Repositories – Versionskontrollierte Codierungsumgebungen, in denen mehrere Entwickler an derselben Codebasis arbeiten können. Code-Repositories sollten mit CI/CD-, Test- und Sicherheits-Tools integriert werden, sodass wenn der Code in das Repository festgeschrieben wird, automatisch zum nächsten Schritt übergegangen werden kann. Open-Source-Code-Repositories umfassen GitHub und GitLab.
  
  
• CI/CD-Pipelines – Tools, die das Auschecken, Erstellen, Testen und Bereitstellen von Code automatisieren. Jenkins ist das beliebteste Open-Source-Tool in dieser Kategorie; viele Alternativen, die in der Vergangenheit Open-Source waren, wie z. B. CircleCI, sind heute nur noch in kommerziellen Versionen verfügbar. Im Bereich der Continuous Deployment (CD)-Tools bewegt sich Spinnaker zwischen den Code-Schichten Anwendung und Infrastruktur. ArgoCD ist eine weitere beliebte Open-Source-Wahl für Kubernetes-native CI/CD.
  
  
• Frameworks zur Testautomatisierung – Dazu gehören Software-Tools, Bibliotheken und Best Practices für die Automatisierung von Komponenten-, Vertrags-, Funktions-, Leistungs-, Benutzerfreundlichkeits-, Penetrations- und Sicherheitstests. Die besten dieser Tools unterstützen mehrere Sprachen; einige nutzen künstliche Intelligenz (KI), um Tests in Reaktion auf Codeänderungen automatisch neu zu konfigurieren. Die verfügbare Palette an Test-Tools und -Frameworks ist groß! Zu den beliebten Open-Source-Testautomatisierungs-Frameworks gehören Selenium, Appium, Katalon, Robot Framework und Serenity (früher bekannt unter dem Namen Thucydides).
  
  
• Tools für das Konfigurationsmanagement (Infrastructure as Code) – Ermöglichen es DevOps-Ingenieuren, eine vollständig versionierte und vollständig dokumentierte Infrastruktur durch Ausführen eines Scripts zu konfigurieren und bereitzustellen. Zu den Open-Source-Optionen gehören Ansible (Red Hat), Chef, Puppet und Terraform. Kubernetes übernimmt die gleiche Funktion für containerisierte Anwendungen (siehe „DevOps und cloudnative Entwicklung“ weiter unten).
  
  
• Überwachungstools – Diese Tools helfen DevOps-Teams bei der Identifizierung und Behebung von Systemproblemen; sie sammeln und analysieren außerdem Daten in Echtzeit, um aufzuzeigen, wie sich Codeänderungen auf die Anwendungsleistung auswirken. Zu den Open-Source-Monitoring-Tools gehören Datadog, Nagios, Prometheus und Splunk.
  
  
• Tools für kontinuierliches Feedback – Tools, die Feedback von den Benutzern zusammenstellen, entweder durch Heatmapping (Aufnahme der Benutzeraktionen auf dem Bildschirm), Umfragen oder Self-Service-Ticketing.

Cloudnativ ist ein Ansatz für die Erstellung von Anwendungen, die grundlegende Cloud-Computing-Technologien nutzen. Das Ziel bei der cloudnativen Vorgehensweise ist es, eine konsistente und optimale Anwendungsentwicklung, -bereitstellung, -verwaltung und -leistung in öffentlichen, privaten und Multicloud-Umgebungen zu ermöglichen. 

Heute werden cloudnative Anwendungen in der Regel:

• Erstellt mit Microservices – lose gekoppelte, unabhängig einsetzbare Komponenten, die über einen eigenen eigenständigen Stack verfügen und über REST-APIs, Ereignisstreaming oder Message Broker miteinander kommunizieren.
  
  
• Bereitgestellt in Containern – ausführbare Codeeinheiten, die alle Code-, Laufzeit- und Betriebssystemabhängigkeiten enthalten, die zum Ausführen der Anwendung erforderlich sind. (Für die meisten Unternehmen ist „Container“ gleichbedeutend mit Docker-Containern, es gibt aber auch andere Container.)
  
  
• Betrieben (im richtigen Maß) mit Kubernetes, einer Open-Source-Container-Orchestrierungsplattform für die Planung und Automatisierung der Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen.

In vielerlei Hinsicht sind cloudnative Entwicklung und DevOps wie füreinander geschaffen. 

Beispielsweise eignet sich die Entwicklung und Aktualisierung von Microservices – d. h. die iterative Bereitstellung kleiner Codeeinheiten an eine kleine Codebasis – perfekt für die schnellen Release- und Verwaltungszyklen von DevOps. Und es wäre schwierig, die Komplexität einer Microservices-Architektur ohne DevOps-Bereitstellung und -Betrieb zu bewältigen. Eine kürzlich von IBM durchgeführte Umfrage unter Entwicklern und IT-Führungskräften ergab, dass 78 % der aktuellen Microservices-Benutzer erwarten, den Zeit-, Geld- und Arbeitsaufwand, den sie in die Architektur investiert haben, zu erhöhen. 56 % der Nichtbenutzer werden wahrscheinlich innerhalb der nächsten zwei Jahre Microservices einführen. 

Durch die Paketierung und dauerhafte Festlegung aller Betriebssystemabhängigkeiten ermöglichen Container schnelle CI/CD- und Bereitstellungszyklen, da die gesamte Integration, das Testen und die Bereitstellung in der gleichen Umgebung stattfinden. Und die Kubernetes-Orchestrierung führt die gleichen kontinuierlichen Konfigurationsaufgaben für containerisierte Anwendungen aus, wie sie Ansible, Puppet und Chef für nicht containerisierte Anwendungen ausführen.

Die meisten führenden Cloud-Computing-Anbieter – darunter AWS, Google, Microsoft Azure und IBM Cloud – bieten eine Art verwaltete DevOps-Pipeline-Lösung an.

DevSecOps ist DevOps, das die Sicherheit während des gesamten DevOps-Lebenszyklus kontinuierlich integriert und automatisiert – von Anfang bis Ende, von der Planung bis zum Feedback und wieder zurück zur Planung.

Man kann es auch so ausdrücken: DevSecOps ist das, was DevOps von Anfang hätte sein sollen. Zwei der ersten großen (und eine Zeit lang unüberwindbaren) Herausforderungen bei der Einführung von DevOps waren jedoch die Integration von Sicherheitsexpertise in funktionsübergreifende Teams (ein kulturelles Problem) und die Implementierung von Sicherheitsautomatisierung in den DevOps-Lebenszyklus (ein technisches Problem). Sicherheit wurde als das „Team der Neinsager“ und als teurer Engpass in vielen DevOps-Verfahren wahrgenommen.

DevSecOps entstand daher als ein gezielter Versuch, Sicherheit zu integrieren und zu automatisieren, so wie es ursprünglich beabsichtigt war. In DevSecOps ist die Sicherheit ein „Bürger erster Klasse“ und ein Stakeholder auf gleicher Stufe wie Entwicklung und Betrieb und bringt das Element Sicherheit mit einem Produktfokus in den Entwicklungsprozess ein.

Sehen Sie sich „Was ist DevSecOps?“ an, um mehr über DevSecOps-Grundsätze, Vorzüge und Anwendungsfälle zu erfahren:

Beim Site Reliability Engineering (SRE) werden Softwaretechniken eingesetzt, um Aufgaben des IT-Betriebs zu automatisieren – z. B. die Verwaltung von Produktionssystemen, das Änderungsmanagement, die Reaktion auf Vorfälle und sogar die Reaktion auf Notfälle – die ansonsten von Systemadministratoren manuell durchgeführt würden. SRE zielt darauf ab, den klassischen Systemadministrator zu einem Ingenieur zu machen.

Das ultimative Ziel von SRE ähnelt dem von DevOps, ist aber spezifischer: SRE soll den Wunsch eines Unternehmens nach schneller Anwendungsentwicklung mit der Notwendigkeit in Einklang bringen, die in Service Level Agreements (SLAs) mit Kunden und Endbenutzern festgelegten Leistungs- und Verfügbarkeitsniveaus zu erfüllen. 

Ingenieure für Standortzuverlässigkeit erreichen dieses Gleichgewicht, indem sie ein akzeptables Niveau des durch Anwendungen verursachten Betriebsrisikos – genannt „Fehlerbudget“ – festlegen und die Abläufe so automatisieren, dass dieses Niveau eingehalten wird. 

In einem funktionsübergreifenden DevOps-Team kann SRE als Brücke zwischen Entwicklung und Betrieb dienen, indem es die Metriken und die Automatisierung zur Verfügung stellt, die das Team benötigt, um Code-Änderungen und neue Features so schnell wie möglich durch die DevOps-Pipeline zu pushen, ohne aber die Bedingungen der SLAs des Unternehmens zu „verletzen“. 

Mehr erfahren zum Site Reliability Engineering