DevOps

DevOps ist eine Sammlung unterschiedlicher technischer Methoden und eine Kultur zur Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb. DevOps soll durch gemeinsame Prozesse und Software-Werkzeuge eine effektivere und effizientere Zusammenarbeit der Bereiche Softwareentwicklung (Dev), Systemadministratoren (Ops), aber auch Qualitätssicherung und der Nutzerschaft ermöglichen. Mit DevOps sollen die Softwarequalität, die Geschwindigkeit der Entwicklung und der Auslieferung, sowie das Miteinander der beteiligten Teams verbessert werden. ⓘ

Softwareentwicklung wird stark durch eine Kombination speziell aufeinander abgestimmter Werkzeuge, Infrastruktur und organisatorischer Prozesse beeinflusst. Je besser die beteiligten Teams, Werkzeuge und die Infrastruktur aufeinander abgestimmt sind, desto schneller sollen Organisationen ihre Software in einer besseren Qualität ausliefern können. Die Entwicklung möchte dem Kunden möglichst schnell Updates oder neue Funktionalitäten zur Verfügung stellen. Der IT-Betrieb muss die Betriebstabilität sicherstellen und potentielle technische Defekte durch Änderungen verhindern. DevOps soll diese beiden Ziele vereinen helfen. ⓘ

Der belgische Systemadministrator Patrick Debois erkannte, dass eine verbesserte Art und Weise der Zusammenarbeit zwischen Dev und Ops zu einer schnelleren und fehlerärmeren Softwareauslieferung führen kann. Während der Velocity Conference im Juni 2009 in San José entstand dabei der Begriff DevOps. Im Oktober 2009 organisierte Patrick Debois dann die erste DevOpsDays-Konferenz in Gent. ⓘ

Definition

Abgesehen davon, dass es sich um eine funktionsübergreifende Kombination (und ein Portmanteau) der Begriffe und Konzepte für "Entwicklung" und "Betrieb" handelt, haben Wissenschaftler und Praktiker keine allgemeingültige Definition für den Begriff "DevOps" entwickelt. Meistens wird DevOps durch Schlüsselprinzipien charakterisiert: gemeinsame Verantwortung, Automatisierung von Arbeitsabläufen und schnelles Feedback. ⓘ

Aus akademischer Sicht schlugen Len Bass, Ingo Weber und Liming Zhu - drei Informatikforscher des CSIRO und des Software Engineering Institute - vor, DevOps als "eine Reihe von Praktiken zu definieren, die darauf abzielen, die Zeit zwischen der Übergabe einer Änderung an ein System und der Überführung der Änderung in die normale Produktion zu verkürzen und gleichzeitig eine hohe Qualität sicherzustellen". ⓘ

Der Begriff wird jedoch in verschiedenen Kontexten verwendet. In seiner erfolgreichsten Form ist DevOps eine Kombination aus spezifischen Praktiken, Kulturwandel und Tools. ⓘ

DevOps ist ein Kofferwort aus den Begriffen Development (englisch für Entwicklung) und IT Operations (engl. für IT-Betrieb). ⓘ

Von DevOps existieren unterschiedliche Interpretationen und Definitionen. Der Begriff ist nicht geschützt, es gibt mehrere unterschiedliche Zertifizierungspfade. ⓘ

Der Begriff DevOps – als Zusammenarbeits-Modell von traditionell verschiedenen interdependenten Arbeitsbereichen – wurde auch auf explizit andere Gebiete außerhalb von Entwicklung und Betrieb übertragen. So gibt es die Begriffe BizDevOps (Business plus DevOps)., aber auch DevSecOps (das Security einschließt) oder DataOps (das Datenanalyse benennt). Gemeint ist jeweils, dass diese Gebiete unter Verwendung gemeinsamer Methoden und Werkzeuge eng zusammenarbeiten. ⓘ

Geschichte

1993 definierte das Telecommunications Information Networking Architecture Consortium (TINA-C) ein Modell für einen Service-Lebenszyklus, das die Softwareentwicklung mit dem Betrieb von (Telekommunikations-)Diensten verbindet. ⓘ

Im Jahr 2009 fand in Gent, Belgien, die erste Konferenz mit dem Namen devopsdays statt. Die Konferenz wurde von dem belgischen Berater, Projektmanager und agilen Praktiker Patrick Debois gegründet. Die Konferenz hat sich inzwischen auf andere Länder ausgeweitet. ⓘ

Im Jahr 2012 wurde der State of DevOps-Bericht von Alanna Brown von Puppet konzipiert und veröffentlicht. ⓘ

Ab 2014 wurde der jährliche State of DevOps-Bericht von Nicole Forsgren, Gene Kim, Jez Humble und anderen veröffentlicht. Darin wird festgestellt, dass sich die Einführung von DevOps beschleunigt. Ebenfalls im Jahr 2014 schrieben Lisa Crispin und Janet Gregory das Buch More Agile Testing, das ein Kapitel über Testing und DevOps enthält. ⓘ

Im Jahr 2016 wurden die DORA-Metriken für Durchsatz (Bereitstellungshäufigkeit, Vorlaufzeit für Änderungen) und Stabilität (mittlere Wiederherstellungszeit, Ausfallrate von Änderungen) im State of DevOps-Bericht veröffentlicht. ⓘ

Beziehung zu anderen Ansätzen

Viele der Ideen, die den DevOps-Praktiken zugrunde liegen, sind von anderen bekannten Praktiken inspiriert oder spiegeln diese wider, wie z. B. Lean und Demings Plan-Do-Check-Act-Zyklus, bis hin zum Toyota Way und dem agilen Ansatz der Aufteilung in Komponenten und Losgrößen. Im Gegensatz zum "Top-Down"-Ansatz und dem starren Rahmen von ITIL in den 1990er Jahren ist DevOps "Bottom-Up" und eine flexible Praxis, die von Softwareingenieuren mit Blick auf die Bedürfnisse von Softwareingenieuren entwickelt wurde. ⓘ

Agil

Die Motivation für das, was heute zu modernem DevOps geworden ist, und für mehrere Standard-DevOps-Praktiken wie automatisiertes Erstellen und Testen, kontinuierliche Integration und kontinuierliche Bereitstellung hat ihren Ursprung in der agilen Welt, die (informell) auf die 1990er Jahre und formell auf 2001 zurückgeht. Agile Entwicklungsteams, die Methoden wie Extreme Programming verwenden, konnten den Kunden nur dann durch eine frühzeitige und kontinuierliche Bereitstellung wertvoller Software zufriedenstellen, wenn sie die mit ihren Anwendungen verbundenen Betriebs-/Infrastrukturaufgaben, von denen sie viele automatisierten, übernahmen. Da sich Scrum in den frühen 2000er Jahren als vorherrschendes agiles Framework herauskristallisierte und die technischen Praktiken, die Teil vieler agiler Teams waren, wegfielen, spaltete sich die Bewegung zur Automatisierung von Betriebs-/Infrastrukturfunktionen von Agile ab und entwickelte sich zu dem, was heute als DevOps bezeichnet wird. Heute konzentriert sich DevOps auf die Bereitstellung der entwickelten Software, unabhängig davon, ob sie mit agilen oder anderen Methoden entwickelt wurde. ⓘ

ArchOps

ArchOps stellt eine Erweiterung der DevOps-Praxis dar, die bei der Bereitstellung von Operationen von Artefakten der Softwarearchitektur ausgeht und nicht vom Quellcode. ArchOps besagt, dass architektonische Modelle bei der Softwareentwicklung, der Bereitstellung und dem Betrieb erstklassige Entitäten sind. ⓘ

CI/CD

Automatisierung ist ein Kernprinzip für den Erfolg von DevOps, und CI/CD ist eine entscheidende Komponente. Außerdem trägt eine verbesserte Zusammenarbeit und Kommunikation zwischen und innerhalb von Teams zu einer schnelleren Markteinführung bei geringeren Risiken bei. ⓘ

Website-Zuverlässigkeitstechnik

Im Jahr 2003 entwickelte Google das Site Reliability Engineering (SRE), einen Ansatz für die kontinuierliche Freigabe neuer Funktionen in großen, hochverfügbaren Systemen bei gleichzeitiger Aufrechterhaltung einer qualitativ hochwertigen Endnutzererfahrung. Obwohl SRE der Entwicklung von DevOps vorausging, werden sie im Allgemeinen als miteinander verwandt angesehen. ⓘ

Toyota-Produktionssystem, schlankes Denken, Kaizen

Das Toyota-Produktionssystem, auch bekannt unter dem Akronym TPS, stand Pate für das Lean-Denken mit seinem Schwerpunkt auf kontinuierlicher Verbesserung, Kaizen, Fluss und kleinen Chargen. Das Andon-Cord-Prinzip zur schnellen Rückmeldung, zum Schwärmen und zur Problemlösung geht auf TPS zurück. ⓘ

DevSecOps, Sicherheit nach links verlagern

DevSecOps ist eine Erweiterung von DevOps, um die Integration von Sicherheitspraktiken in den DevOps-Ansatz zu ermöglichen. Im Gegensatz zu einem traditionellen Modell mit zentralisierten Sicherheitsteams ist jedes Bereitstellungsteam befugt, die richtigen Sicherheitskontrollen in die Softwarebereitstellung einzubeziehen. Sicherheitspraktiken und -tests werden zu einem früheren Zeitpunkt im Entwicklungslebenszyklus durchgeführt, daher der Begriff "shift left". Die Sicherheit wird in drei Hauptbereichen getestet: statisch, Softwarekomposition und dynamisch. ⓘ

Die statische Überprüfung des Codes durch statische Anwendungssicherheitstests (SAST) ist ein White-Box-Test mit besonderem Schwerpunkt auf der Sicherheit. Je nach Programmiersprache werden für eine solche statische Code-Analyse unterschiedliche Tools benötigt. Die Softwarezusammensetzung wird analysiert, insbesondere werden Bibliotheken und ihre Versionen mit den von CERT und anderen Expertengruppen veröffentlichten Schwachstellenlisten abgeglichen. Bei der Weitergabe von Software an Kunden stehen die Lizenzen und deren Übereinstimmung mit der verteilten Software im Mittelpunkt, insbesondere Copyleft-Lizenzen. Dynamische Tests werden auch als Blackbox-Tests bezeichnet. Die Software wird getestet, ohne ihre inneren Funktionen zu kennen. In DevSecOps wird es zum einen dynamisch (DAST) genannt, oder Penetrationstests. Ziel ist es, unter anderem Fehler wie Cross-Site-Scripting oder SQL-Injection frühzeitig zu erkennen. Bedrohungsarten werden z.B. vom Open Web Application Security Project veröffentlicht, z.B. dessen TOP10. Auf der anderen Seite ist gerade bei Microservices interaktives Application Testing (IAST) hilfreich, um zu prüfen, welcher Code bei automatisierten Funktionstests ausgeführt wird, um Schwachstellen innerhalb der Anwendungen zu erkennen. Im Gegensatz zu SAST und DAST arbeitet IAST innerhalb der Anwendung. ⓘ

Kultureller Wandel

DevOps-Initiativen können einen kulturellen Wandel in Unternehmen bewirken, indem sie die Art und Weise der Zusammenarbeit zwischen Betrieb, Entwicklern und Testern während der Entwicklungs- und Bereitstellungsprozesse verändern. Eine entscheidende Herausforderung bei der Einführung von DevOps in Unternehmen ist es, diese Gruppen dazu zu bringen, zusammenzuarbeiten. Bei DevOps geht es ebenso sehr um die Kultur wie um die Toolchain. ⓘ

Microservices

Obwohl DevOps im Prinzip mit jedem Architekturstil praktiziert werden kann, entwickelt sich die Microservices-Architektur zum Standard für den Aufbau kontinuierlich bereitgestellter Systeme. Durch die geringe Größe der Dienste kann sich die Architektur eines einzelnen Dienstes durch kontinuierliches Refactoring herausbilden. ⓘ

DevOps-Automatisierung

Sie unterstützt auch Konsistenz, Zuverlässigkeit und Effizienz innerhalb des Unternehmens und wird in der Regel durch ein gemeinsames Code-Repository oder eine Versionskontrolle ermöglicht. Wie DevOps-Forscher Ravi Teja Yarlagadda vermutet: "Bei DevOps wird davon ausgegangen, dass alle Funktionen an einem zentralen Ort mit einem einfachen Code ausgeführt, kontrolliert und verwaltet werden können." ⓘ

Automatisierung mit Versionskontrolle

Viele Unternehmen nutzen Versionskontrolle, um DevOps-Automatisierungstechnologien wie virtuelle Maschinen, Containerisierung (oder Virtualisierung auf Betriebssystemebene) und CI/CD zu unterstützen. In dem Papier DevOps: Entwicklung einer Toolchain im Bankenbereich wird darauf hingewiesen, dass bei Entwicklerteams, die an demselben Projekt arbeiten, "alle Entwickler Änderungen an derselben Codebasis vornehmen und manchmal sogar dieselben Dateien bearbeiten müssen. Um effizient arbeiten zu können, muss es ein System geben, das den Ingenieuren hilft, Konflikte zu vermeiden und die Historie der Codebasis zu bewahren", wobei das Versionskontrollsystem Git und die Plattform GitHub als Beispiele genannt werden. ⓘ

GitOps

Bei GitOps wird der Sollzustand der Infrastruktur, aber auch der Anwendungen, in einem Git-Repository als „Single Source of Truth“ deklarativ verwaltet. Dieses Infrastruktur-Repository wird durch einen Softwareagenten nach dem Pull-Prinzip überwacht und Änderungen gegebenenfalls automatisch ausgerollt. Änderungen an der Infrastruktur kann im Infrastruktur-Repository mit Pull Requests vorgeschlagen, getestet, gereviewed und auch delivered werden. GitOps kann auch mit anderen Systemen zur Versionskontrolle genutzt werden. ⓘ

GitOps hat sich aus DevOps entwickelt. Der spezifische Zustand der Bereitstellungskonfiguration wird versionskontrolliert (z. B. mit Git). Änderungen an der Konfiguration können mithilfe von Code-Review-Verfahren verwaltet und mithilfe von Versionskontrollen rückgängig gemacht werden. ⓘ

Kultur

Das Kernstück der DevOps-Organisationskultur ist die Aufhebung der Trennung zwischen Entwicklung und Operations zugunsten einer Kooperation durch:

• gegenseitige Sichtbarkeit von Prozessen und Plänen und einer gemeinsamen Abstimmung von Änderungen, Prioritäten und Zuständigkeiten.
• gemeinsame Verantwortlichkeit des gesamten Teams für Kundenorientierung während des gesamten Software-Lebenszyklus.
• kürzere Releasezyklen um Planungen und das Risikomanagement zu vereinfachen
• häufige und offene Kommunikation ⓘ

Methoden

DevOps-Methoden umfassen mehrere, bereits unabhängig existierende Techniken. ⓘ

• Continuous-Integration- und Continuous-Delivery-Werkzeuge ermöglichen den erforderlichen hohen Grad an Automatisierung der „Deployment Pipeline“. Mehrere Werkzeuge in Kombination werden im Rahmen des Softwareentwicklungsprozesses zusammenhängend genutzt.
• Microservices, die komplexe Anwendungssoftware in entkoppelte Prozesse aufteilen und untereinander mit Programmierschnittstellen kommunizieren.
• „Infrastructure as Code“, Software-Configuration-Management und Versionsverwaltung erlauben es, die Konfiguration und die Systemumgebung transparent, replizierbar und wiederherstellbar zu verwalten.
• Ein kontinuierliches Service-Monitoring ermöglicht das proaktive Erkennen und Auffinden von Softwarefehlern oder Lastspitzen.
• Die agile Softwareentwicklung ändert die Art und Weise des Programmierens im Team; in Kombination mit DevOps stellt sie – ausgehend von der Art, Software in Betrieb zu nehmen und zu betreiben – einen Wandel in der Unternehmenskultur dar.
• automatisierte Softwaretests: statische und dynamische Code-Analysen sowie Unit-, Integrations-, System- und Performance-Tests
• bereichsübergreifende Key-Performance-Indicators (KPIs) und gemeinsame Anreiz-Metriken ⓘ

Werkzeuge

Diese DevOps-Werkzeuge unterstützen oder ermöglichen einzelne oder mehrere dieser Methoden:

• Jenkins (Continuous Integration)
• Ansible (Configuration Management)
• Puppet (Infrastructure as Code)
• Vagrant (Virtualisierungsplattform)
• GitHub sowie GitLab bieten neben einer Versionsverwaltung auch Continuous-Integration- und Continuous-Delivery-Werkzeuge sowie automatisierte Softwaretests.
• Im Microsoft-Umfeld ist zudem Team Foundation Server (TFS) bzw. Azure DevOps (für Continuous Integration, Build, Test, Paketierung, Releasemanagement, sowie Systems Management über PowerShell- oder AzureCLI Python-Skripte) und Microsoft Azure (Hosting und Monitoring) etabliert. ⓘ

Auch die Containervirtualisierung Docker oder die Container-Orchestrierung Kubernetes werden teilweise zu den DevOps-Werkzeugen gezählt. ⓘ

DevSecOps

Während sich DevOps um die Bereitstellung der Infrastruktur für Dienste und die Auslieferung dieser Dienste kümmert, ist DevSecOps für die Sicherheit dieser Infrastruktur und die IT-Compliance zuständig. ⓘ

Aufgabengebiete von DevSecOps:

• Zoning und Containment (z. B. Definition von Sicherheitsgruppen)
• IT-Anlagenwirtschaft und Geräteattestierung
• Logging, Monitoring, Auditing und OpsDB-Verwaltung
• Authentifizierungs- und Autorisierungsmechanismen
• Verschlüsselung und Verwaltung von digitalen Zertifikaten
• Network Access Control oder Software Defined Perimeter ⓘ