Im letzten Teil der 8 stufigen Wolkenkunde geht es heute um den Begriff “DevOps”. Gern als ein neuer Job im IT Umfeld verstanden, bestehend aus Developern (“Devs”) auf der Entwicklungs- und “SysOps” bzw. “SysAdmins” (“Operationals”) auf der Betriebsseite der IT.
DevOps beschreibt aber einen Prozessverbesserungs-Ansatz aus den Bereichen der Softwareentwicklung und Systemadministration. DevOps soll durch gemeinsame Anreize, Prozesse und Werkzeuge (englisch: Tools) eine effektivere und effizientere Zusammenarbeit der Bereiche Dev, Ops und Qualitätssicherung (QS) ermöglichen. Mit DevOps sollen die Qualität der Software, die Geschwindigkeit der Entwicklung und der Auslieferung sowie das Miteinander der beteiligten Teams enorm verbessert werden.
Die Entwicklung einer Software wird stark beeinflusst durch einen Mix speziell aufeinander abgestimmter Tools, Infrastruktur und organisatorischer Prozesse. Je besser die beteiligten Teams, Tools und die Infrastruktur aufeinander abgestimmt sind, desto schneller sollen Organisationen ihre Software in einer besseren Qualität ausliefern können.
Was ist DevOps?
Von DevOps existieren unterschiedliche Interpretationen und Definitionen.
“DevOps is agile IT (operations) delivery, required to match the cadence of agile IT development. DevOps is a philosophy, not a method, or framework, or body of knowledge, or *shudder* vendor’s tool. DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production.
- Culture=behaviour, teamwork, responsibility/accountability, trust/empowerment…
- Practice=policy, roles/RACI, processes/procedures, metrics/reporting, KPIs/improvement…
- Tools=shared skills, toolmaking for each other, common technology platforms…”
Während für die Einführung von agiler Softwareentwicklung ein Wandel in der Art und Weise des Programmierens im Team erforderlich wird, stellt DevOps einen Wandel in der Unternehmenskultur dar.
Der DevOps-Gedanke kann auch als eine bereichsübergreifende, unternehmensweite Kollaboration der Manager, Entwickler, Tester und Administratoren unter Einbeziehung der Kunden verstanden werden. Alle Beteiligten arbeiten zusammen an der Erreichung des gemeinsamen Ziels: der Bereitstellung einer Software für den Kunden. Dieser unternehmensphilosophische Ansatz trägt den Namen BizDevOps (Business plus DevOps).
Wasserfall, agile Methoden und DevOps
Im Prozess der Softwareentwicklung bedient man sich in der Regel eines oder mehrerer Vorgehensmodelle, beispielsweise des Wasserfallmodells oder des V-Modells. Ein Software-Lebenszyklus kann je nach verwendetem Vorgehensmodell die Phasen Planung, Analyse, Design, Entwicklung, Test, Auslieferung oder andere Phasen umfassen.
1991 stellte James Martin in seinem Modell Rapid Application Development das Prinzip des Prototyping für einen iterativen Entwicklungsansatz vor. In Kombination mit dem Erstellen von test case und dem Durchführen von unit test bindet das Prototyping sowohl die Entwickler als auch die Business-Seite in den Softwareentwicklungsprozess mit ein.
Der Einsatz agiler Methoden im Softwareentwicklungsprozess bietet mehr Flexibilität und die Möglichkeit schneller Anpassung an neuen Anforderungen. Codeentwicklung und -ausführung sollten eng miteinander verzahnt sein, damit Fehler zeitnah gefunden und behoben werden können. Continuous-Integration-(CI-)Software wie Jenkins ermöglicht automatisierte Software-Builds mit dem Ziel, eine höhere Code-Qualität und Widerstandsfähigkeit (Robustheit) im Fehlerfall zu erhalten.
Das Ausliefern (englisch: deployment) einer neuen Softwareversion sorgt traditionell für Spannungen zwischen Entwicklern und dem IT-Betrieb. Die Entwickler möchten möglichst schnell Updates oder neue Funktionalitäten dem Kunden zur Verfügung stellen. Der IT-Betrieb sieht tendenziell in jeder Veränderung (Change) ein Ausfallrisiko für das IT-System. Der belgische Systemadministrator Patrick Debois erkannte, dass eine verbesserte Art und Weise der Zusammenarbeit zwischen Dev und Ops zu einer schnelleren und fehlerfreieren Softwareauslieferung führen kann. Der Ansatz und Maßnahmen werden seit der ersten DevOpsDays-Konferenz 2009 in Gent unter dem Begriff DevOps zusammengefasst.
DevOps-Methoden und -Prozesse vereinen bisherige Ansätze wie agile Softwareentwicklung und das vom IT-Betrieb zu verantwortende „Configuration“ oder „Systems Management“ zu einem agilen Gesamtkonzept. Continuous Delivery, das hochfrequente und kontinuierliche Ausliefern von hochqualitativen Softwareversionen, wird durch die Verwendung von DevOps begünstigt.
Das automatisierte Ausliefern von fertigen Softwareversionen als lauffähiges virtualisiertes Betriebssystem (Container) erleichtert das Bereitstellen von Anwendungen. Docker (Software) ist seit dem Jahre 2015 der bekannteste Vertreter für Continuous Deployment.
Einführung von DevOps
Für die erfolgreiche Einführung bzw. Umsetzung von DevOps werden einige Maßnahmen empfohlen:
- Erstellung von Business Cases zum Belegen der Notwendigkeit von DevOps.
- Erfolgreiche Business Cases (englisch: Success stories) zur Steigerung der Akzeptanz der Anwender und des Managements.
- Aufbau einer ganzheitlichen Kultur der Zusammenarbeit.
- Umsetzung von Maßnahmen zur Nutzung von Automatisierung.
- Gemeinsame Metriken zur Messung des Erfolgs für Dev– und Ops-Teams oder
- Harmonisierung mit (bestehenden) IT-Standards oder -Frameworks wie CMMI oder ITIL.
DevOps in der Praxis
Die Verwendung des DevOps-Ansatzes bedeutet für die Entwickler eine vermehrte Beschäftigung mit dem Installieren von virtuellen Maschinen, mit Aspekten der IT-Sicherheit („DevSec“) oder mit der Planung und Durchführung von Auslieferungen.
Neu für die Administratoren wird die Beschäftigung mit Automatisierung in Kombination mit „Infrastructure as Code“ sowie der Umgang mit Versionsverwaltung und automatisierten Tests sein.
Entwickler und IT-Betrieb müssen sich eventuell auf neue, bereichsübergreifende Key Performance Indicators (KPIs) und damit gemeinsame Anreiz-Metriken einstellen.
Mit DevOps sollen viele stabile Releases ermöglicht werden. Dazu ist die Entwicklung einer verbesserten (agilen) Zusammenarbeit von Entwicklern und IT-Betrieb notwendig. Ebenso wichtig sind die Sicherstellung der Code-Qualität sowie effizienteres Arbeiten durch eine verstärkte Automatisierung von Dev– und Ops-Aufgaben.
Automatisiert ablaufen sollen zum Beispiel der Build aus dem Repository, statische und dynamische Code-Analysen sowie Unit-, Integrations-, System- und Performance-Tests. Ein kontinuierliches, möglichst automatisiertes Monitoring überwacht die sogenannte Deployment Pipeline.
Continuous-Integration- und Continuous-Delivery-Werkzeuge ermöglichen den erforderlichen hohen Grad an Automatisierung der „Deployment Pipeline“. Mehrere Tools in Kombination werden im Rahmen des Sofwareentwicklungsprozesses als eine „Toolchain“ genutzt.
- Code – Code-Entwicklung und Code-Review (Continuous-Integration-Tools),
- Build – Tools zur Versionskontrolle, Zusammenfügen von Code (Merge),
- Test – Statische und dynamische Code-Analysen und Tests,
- Package – Package Manager zum Ausliefern von binären Formaten (ZIP, JAR, WAR, DLL, Docker Image),
- Release – Change Management, z. B. nach ITIL, Freigabe von Releases (Application-Release-Automation-(ARA-)Tools),
- Configure – „Configuration“ oder „Systems Management“-Werkzeuge (Infrastructure as Code-Werkzeuge),
- Monitor – Monitoring von Applikationen (Application performance management), Kunden-Feedback.
Quellenhinweise: