Warum braucht mein Unternehmen DevOps?
Dieses Streben nach unterschiedlichen Zielen hat unzufriedene Kunden und ein unbefriedigendes Endprodukt zur Folge. Das erhöht auch den Kosten- und Zeitaufwand. Somit wird deutlich, weshalb die Zusammenarbeit zwischen Entwicklung und IT-Betrieb unentbehrlich ist.
Der Lösungsansatz: DevOps
Die Zusammenarbeit zwischen der Entwicklung (Development) und dem IT-Betrieb (IT Operations) wird als „DevOps" bezeichnet. Das Vorgehen nach dem DevOps-Paradigma bietet viele Vorteile wie Stabilität, Zuverlässigkeit, Verfügbarkeit und Sicherheit für ein Projekt. Somit ist es einem Unternehmen möglich, seinen Kunden Bugfixes und Features schneller und zuverlässiger bereitzustellen.
Die Zusammenarbeit von Softwareentwicklung und operationalen IT-Teams wirkt den Veröffentlichungen von enorm großen Entwicklungsständen entgegen, indem Veränderungen nach Absprache mit dem IT-Betrieb in kleinen Etappen produktiv geschaltet werden.
Phasen des Paradigmas
Die Prozesse laufen innerhalb des DevOps-Paradigmas in einer zyklischen Prozesskette ab. Diese wird in der folgenden Abbildung grafisch dargestellt:
In der ersten Phase „Plan" werden Anforderungen, Vorgehensweisen, Verbesserungsvorschläge bis hin zu Lösungen für das Projekt diskutiert. Zudem werden bereits an dieser Stelle Kundenbedürfnisse berücksichtigt.1
Entscheidungen aus der Planungsphase werden nun in dem Abschnitt „Code" umgesetzt. Hauptsächlich geht es in dieser Phase um das Entwickeln von IT-Services. Die Aufgaben werden in kleinen Arbeitspaketen im Entwicklungsteam verteilt. Für die erfolgreiche Bearbeitung der Aufgaben ist eine enge Kommunikation innerhalb des Entwicklungsteams essenziell. Die Entwicklungsstände werden anschließend in Repositorys hochgeladen und mittels einer Versionsverwaltungssoftware verwaltet. Des Weiteren ist es Aufgabe der Entwickler, Testfälle unter Berücksichtigung der Test- und Produktionsumgebung zu implementieren. Tests, die die Lauffähigkeit der entwickelten Funktionen prüfen, bezeichnet man als Unit-Tests.2
In der nächsten Phase ist es das Ziel, aus dem Entwicklungsstand ein Produkt in Form eines Images zu erstellen. Um dies zu erreichen, werden die Änderungen aus dem Repository bestenfalls automatisch in den entsprechenden Entwicklungsstand integriert und zusammen mit den benötigten Abhängigkeiten paketiert. Diese Phase wird als „Build" bezeichnet.3
Innerhalb der nächsten Phase „Test" durchläuft die Anwendung automatisierte Tests. Hierbei werden zu Beginn simple Tests wie die zuvor implementierten Unit-Tests ausgeführt, um Funktionen sowie Schnittstellen der Anwendung zu überprüfen und offensichtliche Fehler auszuschließen. Die Anzahl der Testungen steigt auf dem Weg zur Veröffentlichung an, wodurch eine Überprüfung des gesamten Systems erfolgt.4
Die Phase von der Integration bis zur Bereitstellung eines Features für einen Kunden wird als „Release" bezeichnet. Der letzte Schritt dieser Phase, die Bereitstellung eines Features, kann hierbei mit der nächsten Phase übereinstimmen.5
Falls die Anwendung erfolgreich getestet wurde, wird sie in die Produktionsumgebung überführt. Diese Phase wird als „Deploy" bezeichnet. Das Veröffentlichen von der Pre-Produktions- auf die Produktionsumgebung erfolgt so spät wie möglich. Das System wird hierzu innerhalb der Pre-Produktionsumgebung durch die zuvor implementierten Tests auf seine Lauffähigkeit überprüft, bevor die Freigabe für die Veröffentlichung auf die Produktionsumgebung erfolgt.6
Die Betriebsphase, gekennzeichnet als „Operate", sorgt dafür, dass in einem angemessenen Umfang Hard- und Software zur Verfügung gestellt werden. Bei Ausfällen oder Störungen ist der IT-Betrieb der Ansprechpartner des Anwenders. Der IT-Betrieb ist dafür zuständig, die Verfügbarkeit umgehend wiederherzustellen.7
Um Fehler im produktiven Betrieb zu erkennen und daraus Maßnahmen zur kontinuierlichen Verbesserung abzuleiten, wird die Anwendung überwacht. Diese Phase wird als „Monitor" bezeichnet. Den Entwicklern wird zu jeder neuen Planungsphase ein Feedback, anhand der Daten aus der Produktionsumgebung, von dem operativen Betrieb zu Verfügung gestellt. Durch eine Bewertung dieser Daten ist eine Planung unter Berücksichtigung realistischer Bedingungen möglich.8
Ein Ziel des DevOps-Paradigmas ist es, so viele Tätigkeiten wie möglich auf die ersten Phasen der Prozesskette zu verlagern und die nachfolgenden Schritte zu automatisieren. Hierdurch werden Risiken minimiert, indem Fehler frühzeitig erkannt werden. Dies reduziert die Arbeitspakete in den späteren Phasen. Das Vorgehen wird als „Shift-Left" bezeichnet.9
Hierzu werden Testfälle wie Unit-, Akzeptanz- und Integrationstests automatisiert innerhalb des Entwicklungszyklus integriert. Unit-Tests werden von den Entwicklern erstellt und dienen zur Überprüfung der technischen Lauffähigkeit von Entwicklungen. Dies wird realisiert, indem die erwarteten Ergebnisse der Funktionen durch die Testfälle überprüft werden.10
Die Abdeckung von Code durch Unit-Tests wird als „Code Coverage" bezeichnet.11
Mit dem Akzeptanztest werden Regressionsfehler ausgeschlossen. Die gesamte Anwendung wird getestet, um festzustellen, ob die Anwendung nach den Änderungen immer noch ohne Fehler funktioniert.12
Die Integrationstests stellen sicher, dass die Interaktion der Anwendung mit anderen Produktionsanwendungen und Services fehlerfrei funktioniert.13
Fazit
Eine Studie, die sich auf über 25.000 Daten von Technologieexperten beruft, belegt, dass das Arbeiten nach dem DevOps-Paradigma zu häufigeren Code- und Änderungsveröffentlichungen sowie zu kürzeren Vorbereitungen führt. Dies ermöglicht eine höhere Wahrscheinlichkeit, Produktivitäts-, Marktanteils- und Profitabilitätsziele zu erreichen.14
Aus der Studie geht hervor, dass die Einführung von DevOps in Projekten empfehlenswert ist, in denen eine permanente Weiterentwicklung von Software gefordert wird und zugleich hohe Ansprüche in Bezug auf Qualität, Sicherheit und Zuverlässigkeit von den Kunden erhoben werden.
In unserem nächsten Blogartikel zum Thema DevSecOps werden wir noch das Thema Sicherheit in diesen Kreislauf einbringen. Freuen Sie sich auch schon auf den letzten Teil dieser Reihe, wo wir über die konkrete Umsetzung anhand einer CI/CD-Pipeline berichten.
Sie haben Interesse an einer Weiterbildung oder Fragen zum Thema DevOps? Sprechen Sie uns an oder besuchen Sie einen unserer Kurse aus unserem Seminarshop:
Zu unseren Seminaren
Quellen
[1] vgl. Halstenberg et al., 2020, S.16
[2] vgl. Halstenberg et al., 2020, S.18 f.
[3] vgl. Halstenberg et al., 2020, S.19.
[4] vgl. Halstenberg et al., 2020, S.19.
[5] vgl. Halstenberg et al., 2020, S.20.
[6] vgl. Halstenberg et al., 2020, S.20.
[7] vgl. Wagner, 2017, S.469 f.
[8] vgl. Halstenberg et al., 2020, S.21.
[9] vgl. Halstenberg et al., 2020, S.15.
[10] vgl. Trautsch und Grabowski, 2017, S.207.
[11] vgl. Albunian et al., 2020, S.1204.
[12] vgl. Kim et al., 2017, S. 125.
[13] vgl. Kim et al., 2017, S. 125.
[14] vgl. Kim et al., 2017, S.XXXIV.
Albunian, N., Fraser, G. & Sudholt, D. (2020). Causes and Effects of Fitness Landscapes in Unit Test Generation. https://doi.org/10.1145/3377930.3390194
Halstenberg, J., Pfitzinger, B. & Jestädt, T. (2020). DevOps : ein Überblick (1. Auflage). Springer Vieweg. https://doi.org/10.1007/978-3-658-31405-7
Kim, G., Humble, J., Debois, P. & Willis, J. (2017). Das DevOps-Handbuch: Teams, Tools und Infrastrukturen erfolgreich umgestalten (1. Auflage). O'Reilly.
Trautsch, F. & Grabowski, J. (2017). Are There Any Unit Tests? An Empirical Study on Unit Testing in Open Source Python Projects. 2017 IEEE International Conference on Software Testing, Verification and Validation (ICST), 207–218. https://doi.org/10.1109/ICST.2017.26
Wagner, F. (2017). Gabler Versicherungslexikon (2. Auflage). Springer Gabler. https://doi.org/https://doi.org/10.1007/978-3-8349-4625-6
Junior Consultant bei ORDIX.
Bei Updates im Blog, informieren wir per E-Mail.
Kommentare