„DevOps“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
[gesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
K →‎Einführung von DevOps: Leerzeichen vor Beleg entfernt
Zeile 105: Zeile 105:
|Originaltitel=The Science of DevOps Accelerate. Building and Scaling High Performing Technology Organizations
|Originaltitel=The Science of DevOps Accelerate. Building and Scaling High Performing Technology Organizations
|Originalsprache=en}}
|Originalsprache=en}}
* {{Literatur
|Autor= Jürgen Halstenberg, Bernd Pfitzinger, Thomas Jestädt
|Titel=DevOps. Ein Überblick
|Verlag=Springer Vieweg
|Ort=Wiesbaden
|Datum=2020
|ISBN=978-3-658-31404-0}}
* {{Literatur
* {{Literatur
|Autor=Jez Humble, David Farley
|Autor=Jez Humble, David Farley

Version vom 12. Januar 2021, 13:37 Uhr

DevOps beschreibt einen Ansatz, wie die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb verbessert werden kann. DevOps ist ein Kofferwort aus den Begriffen Development (englisch für Entwicklung) und IT Operations (englisch für IT-Betrieb)[1]. DevOps soll durch gemeinsame Anreize, Prozesse und Software-Werkzeuge (englisch: tools) eine effektivere und effizientere Zusammenarbeit der Bereiche Dev, Ops, Qualitätssicherung (QS) und Fachbereichen ermöglichen.[2] 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 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.

Begriff

Von DevOps existierten im Jahr 2015 unterschiedliche Interpretationen und Definitionen. Der Begriff ist am ehesten als Beschreibung eines Betriebsverfahrens in Abgrenzung zu früheren Methoden zu verstehen. Ein Beispiel einer Definition aus dem Jahr 2014 ist folgendes:

“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…”

„DevOps bedeutet eine agile IT (Betriebs-) Bereitstellung, was erforderlich ist, um dem Rhythmus der agilen IT Entwicklung zu entsprechen. DevOps ist eine Philosophie, nicht eine Methode, ein Modell, ein Wissensfundus, oder *schauder* ein käufliches Werkzeug. DevOps ist die Philosophie der Vereinheitlichung von Entwicklung und Betrieb auf Kultur-, Praxis- und Werkzeug-Ebene, um eine schnellere und häufigere Umsetzung von Änderungen in der Produktion zu erreichen.

  • Kultur=Verhalten, Zusammenarbeit, Verantwortlichkeit/Haftung, Vertrauen/Bevollmächtigung…
  • Praxis=Grundsatz, Rollen/RACI, Prozesse/Prozeduren, Metriken/Berichtswesen, KPIs/Verbesserung…
  • Werkzeug=Geteiltes Wissen, gegenseitiger Werkzeugbau, gemeinsame Technologieplattformen…“
Rob England: The IT Skeptic[3]

Die agile Softwareentwicklung ändert die Art und Weise des Programmierens im Team. DevOps hingegen stellt – ausgehend von der Art, Software in Betrieb zu nehmen und zu betreiben – einen Wandel in der Unternehmenskultur dar.

Der DevOps-Gedanke kann auch als eine bereichsübergreifende, unternehmensweite Zusammenwirkung 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

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 (RAD) 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 neue 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 dem Kunden möglichst schnell Updates oder neue Funktionalitäten 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 fehlerärmeren 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

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 durch Anwender und Management,[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.

Stark betont wird in der Literatur[10] die Rolle der kulturellen Hindernisse bei einer Einführung.

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

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.

Code
Code-Entwicklung und Code-Review, Werkzeuge zur Versionskontrolle, Zusammenfügen von Code (Merge),
Build
Werkzeuge zur kontinuierlichen Integration und Erstellung eines „Build Status“,
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.

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

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.

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:

Literatur

  • Gene Kim, Jez Humble, Patrick Debois, John Willis: Das DevOps Handbuch. Teams, Tools und Infrastrukturen erfolgreich umgestalten. O'Reilly, Heidelberg 2017, ISBN 978-3-96009-047-2 (englisch: The DevOps Handbook. How to Create World-Class Agility, Reliability, & Security in Technology Organizations.).
  • Nicole Forsgren, Jez Humble, Gene Kim: Das Mindset von DevOps Accelerate. 24 Schlüsselkompetenzen, um leistungsstarke Technologieunternehmen zu entwickeln und zu skalieren. Vahlen, München 2019, ISBN 978-3-8006-5963-0 (englisch: The Science of DevOps Accelerate. Building and Scaling High Performing Technology Organizations.).
  • Jürgen Halstenberg, Bernd Pfitzinger, Thomas Jestädt: DevOps. Ein Überblick. Springer Vieweg, Wiesbaden 2020, ISBN 978-3-658-31404-0.
  • 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).
  • DevOps. Informatik Aktuell – Artikelserie zu DevOps, 1. Februar 2019, abgerufen am 7. März 2019.
  • Felix Massem: Operations heute und morgen. heise developer, 28. April 2015, abgerufen am 7. März 2019.
  • Fabian Schaub: DevOps unter der Lupe. Browigo, 22. April 2018, abgerufen am 22. April 2018.
  • Brian Dawson: Missverständnisse rund um DevOps – und wie man es richtig macht. Was ist eigentlich DevOps? In: Entwickler.de. Software & Support Media, 6. Januar 2017, abgerufen am 19. April 2017 (Teil 1/2).
  • Brian Dawson: Warum DevOps so wichtig ist. DevOps ist keine Eintagsfliege. In: Entwickler.de. Software & Support Media, 9. Januar 2017, abgerufen am 19. April 2017 (Teil 2/2).
  • Asami Novak: Going to Market Faster. Most Companies Are Deploying Code Weekly, Daily, or Hourly. In: New Relic Blog: Modern Software. 4. Februar 2016, abgerufen am 19. April 2017 (englisch).
  • Ravi Tharisayi: DevOps 101. Moving Fast With Confidence. In: New Relic Blog: Modern Software. 13. April 2017, abgerufen am 19. April 2017 (englisch).
  • Thomas Fischer: DevOps als modernes IT-Outsourcing. (PDF) Agile Softwareentwicklung bis zum Ende gedacht. In: noris.de. 14. August 2017, abgerufen am 14. August 2017.

Einzelnachweise

  1. J. Halstenberg, B. Pfitzinger, Th. Jestädt: Dev-Ops – Ein Überblick; Springer-Vieweg (Heidelberg) 2020
  2. a b c Wilhelm Hasselbring: DevOps. (PDF; 2.614 kB) Softwarearchitektur an der Schnittstelle zwischen Entwicklung und Betrieb. In: GI-Fachtagung Architekturen 2015, Hamburg. 10. Juli 2015, abgerufen am 24. Februar 2016.
  3. Rob England: Define DevOps. What is DevOps? In: The IT Skeptic. 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. (PDF; 345 kB) In: ACM SIGSOFT Software Engineering Notes 35 No. 3. Mai 2010, abgerufen am 24. Februar 2016 (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. (PDF; 248 kB) DevOps Literature Review. 6. Oktober 2014, abgerufen am 26. Mai 2019 (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 29. Juni 2020.
  10. J. Halstenberg, B. Pfitzinger, Th. Jestädt: Dev-Ops – Ein Überblick; Springer-Vieweg (Heidelberg) 2020