DevOps

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

DevOps beschreibt einen Prozessverbesserungs-Ansatz aus den Bereichen der Softwareentwicklung und Systemadministration. DevOps ist ein Kofferwort aus den Begriffen Development (englisch für Entwicklung) und IT Operations (englisch für IT-Betrieb). 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.[1] Mit DevOps sollen die Qualität der Software, die Geschwindigkeit der Entwicklung und der Auslieferung sowie das Miteinander der beteiligten Teams 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. Ein prominentes Beispiel ist Amazon. Bei dem Online-Versandhändler und Betreiber von Cloud-Diensten wurde im Mai 2011 mithilfe eines Continuous-Deployment-Ansatzes durchschnittlich alle 11,6 Sekunden ein neues Deployment angestoßen, wobei durchschnittlich 10.000 Hosts gleichzeitig ein Deployment erhielten.[2]

Was ist DevOps?[Bearbeiten | Quelltext bearbeiten]

Von DevOps existieren im Jahr 2015 unterschiedliche Interpretationen und Definitionen. Der Begriff ist am ehesten als eine Philosophie oder ein Meta-Begriff zu verstehen. Eine 2014 aktuelle Beispiel-Definition ist Folgende:

“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…
Rob England: The IT Skeptic[3]

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).[4]

Wasserfall, agile Methoden und DevOps[Bearbeiten | Quelltext bearbeiten]

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.[5]:8 f.

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 Testfällen und dem Durchführen von Unit-Tests bindet das Prototyping sowohl die Entwickler als auch die Business-Seite in den Softwareentwicklungsprozess mit ein. Die agile Softwareentwicklung, Extreme Programming (XP) oder Scrum greifen auf den generischen Ansatz des RAD-Modells mit der Zielsetzung einer Beschleunigung der Softwareentwicklung zurück.[5]

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.[4]:1

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. Dieser Ansatz und die Maßnahmen dazu werden seit der ersten DevOpsDays-Konferenz 2009 in Gent unter dem Begriff DevOps zusammengefasst.[6][7]

Einführung von DevOps[Bearbeiten | Quelltext bearbeiten]

Für die erfolgreiche Einführung bzw. Umsetzung von DevOps werden einige Maßnahmen empfohlen:[8]:16 ff.

  • Erstellung von Business Cases zum Belegen der Notwendigkeit von DevOps,[9]
  • Erfolgreiche Business Cases (englisch: Success stories) zur Steigerung der Akzeptanz der Anwender und des Managements,[9]
  • 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[Bearbeiten | Quelltext bearbeiten]

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.[9]

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.[9]

Entwickler und IT-Betrieb müssen sich eventuell auf neue, bereichsübergreifende Key Performance Indicators (KPIs) und damit gemeinsame Anreiz-Metriken einstellen.[9]

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.[1]:5

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.[1]:5-11

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 Softwareentwicklungsprozesses 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),
  • ReleaseChange 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.

Zu den 2016 bekannten Tools gehören zum Beispiel Docker (Bereitstellen und Verteilen von Software-Containern), Jenkins (Continuous Integration), Ansible (Configuration Management), Puppet (Infrastructure as Code) oder Vagrant (Virtualisierungsplattform).

Weblinks[Bearbeiten | Quelltext bearbeiten]

  • Operations heute und morgen (Artikelserie auf heise developer zu den Themen IT, ITIL, DevOps, Virtualisierung & Containerisierung, Hochverfügbarkeit, Big Data und Monitoring)
  • Nach dem Change Management ist vor dem Change Management (Artikelserie auf heise developer zu den Themen kontinuierliche Veränderungen (in) der IT, agiles Projektmanagement, DevOps und der Notwendigkeit einer Etablierung eines Change Managements in einer Organisation)

Literatur[Bearbeiten | Quelltext bearbeiten]

  • Jez Humble, David Farley: Continuous Delivery. Reliable Software Releases Through Build, Test, and Deployment Automation. Addison-Wesley, Upper Saddle River 2010, ISBN 978-0-321-60191-9 (englisch).
  • Michael Hüttermann: DevOps for Developers. Integrate Development and Operations, The Agile Way. Apress, New York 2012, ISBN 978-1-4302-4569-8 (englisch).

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b c Wilhelm Hasselbring: DevOps. Softwarearchitektur an der Schnittstelle zwischen Entwicklung und Betrieb. In: GI-Fachtagung Architekturen 2015, Hamburg. 10. Juli 2015, abgerufen am 24. Februar 2016 (PDF; 2.614 KB).
  2. Jon Jenkins: Velocity 2011. Velocity Culture (Minute 10:21). In: youtube.com. amazon.com, Juni 2011, abgerufen am 17. Februar 2016 (englisch).
  3. Rob England: Define DevOps. What is DevOps? In: www.itskeptic.org. 29. November 2014, abgerufen am 17. Februar 2016 (englisch).
  4. a b Brian Fitzgerald, Klaas-Jan Stol: Continuous Software Engineering - A Roadmap and Agenda. In: Journal of Systems and Software, 4. Juli 2015 doi:10.1016/j.jss.2015.06.063
  5. a b Nayan B. Ruparelia: Software Development Lifecycle Models. In: ACM SIGSOFT Software Engineering Notes 35 No. 3. 10. Januar 2010, abgerufen am 24. Februar 2016 (PDF; 345 KB, englisch).
  6. DevOpsDays 2009 Ghent. In: devopsdays.org. 2009, abgerufen am 17. Februar 2016 (englisch).
  7. Patrick Debois: DevOps. A software revolution in the making? In: Cutter IT Journal 24, No. 8. 2011, abgerufen am 11. August 2015 (englisch).
  8. Floris Erich, Chintan Amrit, Maya Daneva: Report. DevOps Literature Review. 6. Oktober 2014, abgerufen am 24. Februar 2016 (PDF; 248 KB, englisch).
  9. a b c d e Patrick Peschlow: Die DevOps-Bewegung. Was ist das eigentlich und was bedeutet es für uns? In: Javamagazin 1.2012. codecentric AG, Januar 2012, abgerufen am 24. Februar 2016.