DevOps ist ein Kofferwort aus den Begriffen Development und IT Operations. Hinter dem Begriff verbirgt sich eine eine Kombination von Denkweisen, Praktiken und Tools, mit denen Unternehmen schneller und einfacher Anwendungen und Services bereitstellen können. Ziel einer DevOps Transformation ist es, eine eine Kultur zu erschaffen, die die Zusammenarbeit aller Rollen fördert, die an der Entwicklung und Wartung der Software beteiligt sind.
Daher ist für mich persönlich DevOps und Agilität nicht trennbar. Eine agile Vorgehensweise wie Scrum, aber auch Kanban erhält erst mit der DevOps Kultur die entsprechende Basis, um wirklich erfolgreich zu sein. Jedoch wird DevOps, genauso wie die Agilität, meiner Meinung nach in vielen Bereichen immer noch falsch verstanden. Ja, es hat etwas mit Tools zu tun, aber wie meistens nur als Mittel zum Zweck. Die ganzen Tools haben keinen Effekt, wenn nicht die dazugehörigen Tätigkeiten und daraus resultierende Inhalte vorhanden sind. Daher macht es meistens auch keinen Sinn unreflektiert ein Skalierungsframework umzusetzen. Wenn die grundlegende Basis dafür noch nicht richtig aufgestellt ist, wird dies zum Scheitern verurteilt sein.
Mir wurde vor einigen Jahren das Buch “Leading the Transformation – Applying Agile und DevOps Principles at Scale” und ich wurde nicht enttäuscht. Daher kann ich es mit gutem Wissen ebenfalls weiterempfehlen. Nachfolgend habe die wesentlichen Punkte zusammengefasst. In der Zusammenfassungen wird zu Beginn die Auswirkungen eier DevOps Transformationen sowie die 5 wichtigsten Schritte zu Beginn genannt. Danach werden die dazugehörigen Begriffe wie Continuous Delivery oder Trunk Base Development und die technischen Voraussetzungen erklärt.
Auswirkungen einer DevOps Transformation
Kulturwandel durch DevOps
Unternehmen haben angefangen auf Teamebene die Entwicklung mit Hilfe der agile Prinzipien zu verbessern, um auf den immer schneller werdenden Markt zu reagieren zu können und die richtigen Kundenbedürfnisse zu befriedigen, Dies hat insbesondere bei kleinen Unternehmen sehr gut funktioniert. Konzerne hingegen müssen einen aufwendigen Transformations-Prozess anstoßen, um organisationsweit eine Änderung zu bewirken. Dies beinhaltet einen gravierenden Kulturwandel:
Die Hauptaufgabe eines Entwicklers ist es einen stabilen Stand im Produktiven Umfeld bereitzustellen. Alle im Prozess Beteiligten nutzen gemeinsame Werkzeuge und Umgebungen, um sich auf ein gemeinsames Ziele auszurichten. Die gesamte Organisation ist damit einverstanden, dass die Definition of Done eines Release bedeutet, dass die Features gebrauchsfertig und fehlerfrei sind. Sichergestellt wird dies durch eine umfangreiche Testautomatisierung, auf Basis dessen eine aussagekräftige Testabdeckung und Auskunft über die Erfolgsquote resultiert.
Unternehmensweiter Prozess
Hierzu muss die Organisation einen unternehmensweiten Prozess bereitstellen, der folgende Anforderungen erfüllt:
- Fokus sollte nicht nur auf technischen Lösungen, sondern auch auf die Kundenbedürfnisse ausgerichtet sein.
- Unternehmensweite Planung basierend auf kurze Iterationszyklen, in denen die Features kontinuierlich integriert und qualifiziert sind und folglich auch schnelles Feedback möglich ist.
- Codebasis ist stabil und clean, so dass immer am Ende der Iteration die Möglichkeit besteht das Produkt auszuliefern.
- Alle Features werden in der Reihenfolge ihrer Priorität bearbeitet, wobei die wertvollsten Features zuerst entwickelt werden.
- Direkte Kommunikation durch selbstorganisierte Teams und unternehmensweite Zusammenarbeit
- Kontinuierliche Verbesserung und Transparenz auf allen Ebenen
Neuer Führungsstil
Durch den Prozess, der auf Kunde und Teams ausgerichtet ist, ändert sich auch die Führungsverantwortung:
Fokus der Führungskräfte sollte auf der Kommunikation der Geschäftsziele und der kontinuierlichen Verbesserung der Umgebung liegen. Es sollte bekannt sein, welche Faktoren die Cycle-Time und Kosten beeinflussen und welche Maßnahmen umgesetzten werden müssen.
Durch Führen mit Zielen kann den Teams so viel gestalterische Flexibilität gegeben werden, wie diese zur Erledigung der Arbeit benötigten.
- Dadurch ändert sich auch die Motivation und sie übernehmen mehr Verantwortung für die Ergebnisse.
- Wenn sich die Situation ändert, werden diejenigen, die die Arbeit verrichten, dies wahrscheinlich auch schneller spüren und anpassen, als es jemals eine Führungskraft tun würde.
Die 5 wichtigsten Schritte zu Beginn
1. Verbessere die Feedbackschleife zum Entwickler (Qualität und Geschwindigkeit)
Entwickler glauben immer das sie einen guten Code geschrieben haben, der die Ziele erfüllt. Bis Sie das Feedback bekommen, dachten Sie auch, dass sie einen guten Job gemacht haben. Wenn jedoch diese Rückmeldung erst Tage oder Wochen später beim Entwickler aufschlägt, hat das keinen Lerneffekt für den Entwickler. Er ist auch zeitaufwendiger, da er aus seiner bestehenden Arbeit herausgerissen wird und er sich mit dem Problem wieder neu beschäftigen muss.
Wenn der Entwickler aber innerhalb von wenigen Stunden oder weniger ein Feedback automatisch vom System bekommen würde, wird er wahrscheinlich eher über den gewählten Codierungsansatz nachdenken und aus den Fehlern lernen.
2. Reduziere die Zeit und Ressourcen, die benötigt werden, um fertige Features/Releases in die produktive Umgebung zu bringen
Um die Codebasis auf Release-Qualität zu bringen, muss Zeit für das Finden und Beseitigen von Fehlern investiert werden. Um diese Zeit zu reduzieren, wird eine vollständig automatisierte Regression Suite benötigt und jede neue Funktion mit einem neuen Test versehen, so dass während der täglichen Entwicklung ein sofortiges Feedback zum Entwickler möglich ist.
Entwickler müssen anfangen Verantwortung für die Qualität des Codes zu übernehmen, indem Sie beispielsweise nur neuen Code hinzufügen, ohne die vorhandene Funktionalität zu unterbrechen, sodass der Main Branch immer releasefähig ist.
Sobald tägliche Regressionstests automatisch durchgeführt werden, kann die Zeit von Fertigstellung des Feature und Bereitstellen auf der produktiven Umgebung drastisch sinken. Im Idealfall ermöglicht dieser Schritt für Organisationen mit hohem Reifegrad, die trunk quality sehr nahe an der Produktionsqualität zu halten, sodass Sie Continuous Deployment für die Bereitstellung mit mehreren täglichen Check-ins in die Produktion verwenden können.
3. Verbessere die Wiederholbarkeit des Build-, Deploy- und Testprozesses
Es ist wichtig, eine Deployment Pipeline für den Build und den Tests zu entwickeln. Es sollte ein strukturierter und wiederholbarer Prozess sein, da ansonsten viel Zeit und Ressourcen verschwendet werden, wenn Sie Probleme nicht auflösen können oder fehlerhaften Code in großen komplexen System nicht mehr lokalisieren können.
4. Entwickle einen automatisierten Deployment Prozess, der dir eine schnelle und effiziente Suche von relevanten Problemen ermöglicht
Es ist wichtig einen Deployment Prozess zu entwickeln, in dem schnell jedwedes Deployment Problem gefunden und isoliert werden kann, bevor der Systemtest startet.
5. Eliminiere doppelte Arbeit (Support von mehreren Branches mit ähnlichem Code)
Ziel ist es, Ihre Grenzkosten für die Herstellung und den Einsatz von Software auf nahezu Null zu reduzieren. Dies beginnt sich aufzulösen, wenn mehr als ein Zweig (Branch) mit ähnlichem Code existiert. Jedes Mal bei einem Fehler im Code, muss sichergestellt werden, dass dies in jedem Branch auch richtig nachgezogen wurde.
Trunk Base Development als Basis für die DevOps Transformation
Eine der wichtigsten kulturellen Veränderungen ist es, das für die Ausrichtung der Arbeit auf die gesamte Organisation, indem alle Teams ihren Code kontinuierlich in einer produktionsähnlichen Umgebung integrieren und testen.
Führungskräfte müssen verstehen, dass zu Beginn das tägliche Arbeiten mit trunk-base development im Unternehmen eine große Herausforderung für das Change Management darstellt. Dieser Schritt ist wahrscheinlich der Wichtigste, um die Arbeit in Teams besser koordinieren zu können und die Effektivität der Organisation zu verbessern,
Führungskräfte müssen dabei helfen, diese kulturelle Transformation zu führen, indem sie mit einer erreichbaren Strategie beginnen, die eine kleine Anzahl von automatisierten Tests beinhaltet und dann das minimale Niveau an Stabilität immer weiter mit der Zeit erhöhen.
Aus technischer Sicht muss das Team Entwicklungspraktiken wie Versioning service, Rearchitecture durch Abstraktion, Feature-Flags und Evolutionary Database erlernen.
- Beim Versioning service ändern Sie keinen Service, wenn der vorhandene Code dadurch beschädigt wird. Stattdessen erstellen Sie eine neue Version dieses Service mit der neuen Fähigkeit. Der Anwendungscode wird dann geschrieben, um sicherzustellen, dass er die Version des Dienstes aufruft, die er erwartet. Mit der Zeit, wenn der gesamte Anwendungscode auf den neuen Dienst aktualisiert wird, kann die alte Version des Dienstes dann veraltet sein. Dieser Ansatz aktiviert immer wieder freigebenden Code und stellt sicher, dass sich die Anwendungsschicht und die Dienstschicht des Codes unabhängig voneinander bewegen können.
- Eine Rearchitecture durch Abstraktion ist eine Technik, die es Ihnen ermöglicht, große Teile des Codes umzuformen, ohne die bestehende Funktionalität zu sprengen. In diesem Fall finden Sie im Code eine Schnittstelle, in der Sie die Refactorung starten können. Diese Schnittstelle sollte eine Reihe von automatisierten Tests enthalten, damit Sie sicherstellen können, dass sich der neue und alte Code genauso verhält wie der Rest des Systems. Sie können sowohl den alten als auch den neuen Codepfad über diese Schnittstelle testen, um sicherzustellen, dass sie funktionieren . Die alte Schnittstelle wird verwendet, um die Codebasis funktionsfähig zu halten, bis der neue refaktorierte Code bereit ist. Sobald das Refactoring abgeschlossen ist, wird der alte Code veraltet und der neue Code übernimmt die Ausführung mit dem breiteren System
- Feature-Flags sind eine weitere Technik, die es Entwicklern ermöglicht, neuen Code direkt auf dem Trunk zu schreiben, ihn jedoch nicht dem Rest des Systems zugänglich zu machen, indem Feature-Flags verwendet werden, um ihn auszuschalten, bis er fertig ist.
- Evolutionary Database ist eine Technik wie Versioning service mit der Sie Datenbankschemaänderungen vornehmen können, ohne bestehende Funktionen zu unterbrechen. Ähnlich wie bei Versionierungsdiensten fügen Sie die vorhandenen Daten nicht um, sondern fügen neue Versionen mit den Schemaänderungen hinzu und verwerfen dann die alten Versionen, wenn alle Anwendungen bereit sind. Dies sind nicht wirklich technisch herausfordernde Veränderungen, aber sie sind unterschiedliche Arbeitsweisen, die Koordination und Prozessänderungen über die Entwicklungsgruppen hinweg erfordern.
Entwickler müssen wissen, dass sie stabilen Code im Trunk entwickeln können und sollten die Verantwortung dafür übernehmen, dass die Codebasis immer nahe an der Release-Qualität ist, indem sie die Builds grün halten. Sie müssen auch verstehen, dass das Ziel der Organisation darin besteht, die Bereitstellung neuer Fähigkeiten für den Kunden nicht nur auf dem Desktop zu optimieren. Daher ist es wichtig, dass jeder Entwickler dafür verantwortlich ist sicherzustellen, dass jeder Chek-in-Prozess in Richtung der Produktions-Umgebung lauffähig ist. Hierzu muss das Management die Ausrichtung der Entwicklung und Betrieb auf das gemeinsame Ziele als kultureller Wandel unterstützen und voranbringen.
Wichtige Fundamente für eine soliden Grundlage für die DevOps Transformation
1. Saubere Architektur
Das erste Fundament ist eine saubere Architektur, die es kleineren Teams ermöglicht, unabhängig in einem Unternehmen zu arbeiten und Fehler mit schnell ablaufenden Unit- oder Sub-Systemtests zu finden.
Eine Software, die auf einer sauberen, klar definierten Architektur basiert, bietet viele Vorteile. Erfolgreiche Unternehmen verfügen über eine Architektur, die es ihnen ermöglicht, Komponenten großer Systeme schnell unabhängig voneinander zu entwickeln, zu testen und bereit zustellen.
2. Build Prozess
Das zweite Fundament ist der Aufbau und die Fähigkeit, verschiedene Artefakte als unabhängige Komponenten zu verwalten.
Somit besteht der nächste Schritt darin, zu überprüfen, ob der Build-Prozess es Ihnen ermöglicht, verschiedene Teile Ihrer Architektur unabhängig zu verwalten.
- Beginnen Sie mit der Erstellung einer Architekturzeichnung, die beschreibt, wie Sie über Ihre Artefakte denken.
- Erstellen Sie nun ein vollständig integriertes System, das diese Komponenten verwendet. Stellen Sie sicher, dass dieser Build “grün” ist, indem Sie einige grundlegende automatisierte Tests durchführen.
- Bestimmen Sie als Nächstes, ob Sie von einer fehlerhaften Komponente Ihrer Architektur wiederherstellen können, um sie in den nächsten Build zu integrieren.
- Wenn Version 2 aller Komponenten in diesem zweiten Build zusammenkommen, aber Component B bewirkt, dass der Build rot wird, müssen Sie in der Lage sein, zur Version 2 von Component B zurückzukehren und Version 2 von allem anderen zu behalten, um zu A zurückzukehren und dies grün zu bauen. Wenn Sie dies mit allen relevanten Komponenten tun können, dann haben Sie diese grundlegende grundlegende Abdeckung. Wenn nicht, dann haben Sie noch etwas Arbeit vor sich, um die Build-Abhängigkeiten zwischen den verschiedenen Komponenten zu brechen
Diese Idee scheint einfach zu sein, aber es ist ein sehr grundlegender Aufbau, da das System stabil gehalten werden muss, um ein großes Softwaresystem in strukturierter Weise mit verschiedenen Testzuständen und einer Artefakt-Promotion zu erstellen und zu testen. Wenn Ihre Software diesen einfachen Test nicht besteht, müssen Sie zunächst Ihren Build-Prozess korrigieren und Ihre Architektur ändern, um sicherzustellen, dass alle Komponenten unabhängig von den anderen in der Testumgebung erstellt und bereitgestellt werden können.
3. Testautomatisierung
Das dritte Fundament ist die Testautomatisierung. Es sind viele automatisierte Tests erforderlich. Es muss mindestens so viel Testcode und Automatisierungsskripte erstellt und verwaltet, wie Produktionscode vorhanden ist. Ein klar strukturierter Testcode führt zu einem klar strukturierten Produktionscode.
Ohne eine solide Grundlage hier werden Ihre Feedback-Schleifen gebrochen und es wird keine effektive Methode geben, um zu bestimmen, wann Code vorwärts in Ihrer Pipeline gepusht werden soll. Eine gute Testautomatisierung ist noch schwieriger, als guten Code zu schreiben, weil es starke Programmierfähigkeiten und einen scharfen Verstand erfordert, um darüber nachzudenken, wie man den Code bricht.
Sie können einfach kein großes Softwaresystem stabil halten, ohne eine große Anzahl von automatisierten Tests, die täglich ausgeführt werden. Dieser Test sollte mit Unit- und Service-Level-Tests beginnen. Im Idealfall könnten Sie diese Tests verwenden, um alle Ihre Fehler zu finden. Dies funktioniert gut für Software mit sauberen Architekturen. Jedoch wird es nicht so gut in eng gekoppelten Systemen mit Geschäftslogik in der Benutzeroberfläche zu funktionieren, da Sie mehr auf systemebene-basierte UI-Tests angewiesen sind. In diesem Fall kann der Umgang mit Tausenden von automatisierten Tests in einen Wartungs-Alptraum fallen, wenn sie nicht korrekt formatiert sind. Wenn die Tests nicht korrekt ausgeführt werden, können Sie außerdem viel Zeit damit verbringen, den Fehlercode zu lokalisieren, um Fehler zu lokalisieren. Daher ist es sehr wichtig, dass Sie mit einem effizienten Testautomatisierungsansatz beginnen, der es ermöglicht Tausende von Tests zu auf täglicher Basis durchzuführen.
Ein guter Plan beinhaltet die richtigen Leute, die richtige Architektur und die besten Mitarbeiter, die den richtigen Fokus behalten können.
Ein großes Problem bei den meisten Organisationen ist, dass sie die Aufgabe der Testautomatisierung an die Qualitätssicherung delegieren und den manuellen Tester bitten, zu automatisieren, was sie seit Jahren manuell tun. Einige Unternehmen kaufen Tools, um automatisch zu protokollieren, was die manuellen Tester tun, und sie nur als automatisch getesteten Test zurückgeben, was noch viel schlimmer ist. Das Problem mit der Aufnahme und Wiedergabe ist, das bei Änderung der GUI der Test fehlschlägt und Sie analysieren müssen, ob es sich um einen Codedefekt oder einen Testdefekt handelt.
Dies ist das Worst-Case-Szenario für automatisiertes Testen: Wenn die Entwickler beginnen, die Testergebnisse zu ignorieren, weil sie davon ausgeht, dass es sich um ein Testproblem anstelle eines Code-Problems handelt.
Der beste Ansatz für das automatisierte Testen besteht darin, einen wirklich guten Entwicklungsarchitekten, der die Grundlagen der objektorientierten Programmierung kennt, mit einem QA-Ingenieur zu verbinden, der weiß, wie Code in der aktuellen Umgebung manuell getestet wird. Sie können dann zusammenarbeiten, um einen Rahmen für automatisches Testen zu erstellen.
Linktip: Agiles Testen mit 3-Amigos bzw. meinen allgemeinen Artikel: Vom Wilden Westen in die agilen Welt: Wie mit 3 Amigos gemeinsam ein Ziel erreicht wird
Continuous Delivery ist ein weiterer wichtiger Bestandteil für die erfolgreiche DevOps Transformation
Continuous Delivery ist ein grundlegend anderer Ansatz für die Entwicklung und den Betrieb, der so viel wie möglich von den Konfigurations-, Bereitstellungs- und Testprozessen automatisiert und im Rahmen einer Revisionskontrolle implementiert wird. Dies geschieht, um die Wiederholbarkeit der Prozesse sicherzustellen und stellt alles unter eine Revisionssteuerung. Dies geschieht, um die Wiederholbarkeit der Prozesse über mehrere Server und Entwicklungsumgebungen sicherzustellen. Die Automatisierung hilft, menschliche Fehler zu eliminieren, verbessert die Konsistenz und unterstützt eine erhöhte Häufigkeit von Bereitstellungen.
Die Kernelemente von Continuous Delivery sind:
- Continuous Integration,
- skriptbasiertes Umfeld
- skriptbasierte Bereitstellungen,
- evolutionäres Datenbankdesign,
- Testautomatisierung,
- Bereitstellung von Pipelines und
- Orchestrierung.
Continuous Integration
Continuous Integration ist ein Prozess, der das Source Code Verwaltungstool auf Änderungen überwacht und anschließend automatisch einen Build und die damit verbundenen automatisierten Build-Akzeptanztests auslöst. Dies ist erforderlich, um sicherzustellen, dass der Code ein gewisses Basisniveau an Stabilität beibehält und alle Änderungen häufig integriert werden, um Konflikte frühzeitig zu finden.
Skript gesteuerte Umgebungen
Skript gesteuerte Umgebungen (Scripted Environments) ist ein Ansatz, der einen Server oder eine virtuelle Maschine erstellt, um alle Einstellungen vom Betriebssystem zum Container zu konfigurieren. Selbst mit genau dem gleichen Anwendungscode wird ein Test in einer Umgebung erfolgreich sein, aber in einer anderen fehlschlagen, weil er auf eine subtile Weise falsch konfiguriert ist. Dies macht den Prozess sehr aufwendig, da das Problem zu reproduzieren, wenn es nur auf mehreren Servern mit einer gemeinsamen Kompetent auftritt, sehr schwierig zu finden ist. In Skript Umgebungen wurde dies dadurch behoben, dass jeder Server mit einem gemeinsamen Skript konfiguriert wurde, das unter Versions-Kontrolle steht. Dies stellt sicher, dass jeder Server im gesamten System dieselbe Konfiguration hat.
Skript basierte Bereitstellung
Skriptbasierte Bereitstellung ist ein Prozess zur Automatisierung der Bereitstellung in allen Umgebungen. Dieser Prozess stellt die Anwendungen bereit und konfiguriert sie. Im Idealfall werden auch die Bereitstellungen getestet, um sicherzustellen, dass sie erfolgreich waren. Diese Automatisierung wird ebenfalls einer Revisionskontrolle unterzogen, so dass sie täglich aktualisiert wird und von Server zu Server läuft.
Evolutionäres Datenbankdesign
Evaluational Database Design (EDD) ist ein Ansatz zur Verwaltung von Datenbankänderungen, um sicherzustellen, dass Schema-Änderungen Ihre Anwendung niemals beschädigen werden. Es enthält auch Tools, die die Datenbankänderungen der Versionskontrolle unterziehen und die Datenbank in jeder Umgebung automatisch auf die gewünschte Version der Konfiguration aktualisieren können.
Deployment Pipeline
Deployment-Pipeline definiert, wie neuer Code in das System integriert, in die jeweilige Umgebung implementiert und durch verschiedene Testphasen gefördert wird. Dies kann mit der statischen Codeanalyse und dem Komponententest auf der Component-Ebene beginnen. Wenn diese Tests bestanden werden, kann der Code zu einem integrierteren Test auf Anwendungsebene mit einem Basis-Build-Akzeptanz-Level-Test getestet werden. Wenn der Build-Akzeptanz-Level-Test erfolgreich war, kann der Code zur nächsten Stufe übergehen, typischerweise erreicht man eine akzeptable Erfolgsquote mit einem vollem Regression und verschiedene Formen von nicht-funktionalen Testergebnissen, damit der Code bereit für die Bereitstellung in der Produktion ist. Die Entwicklungspipeline in CD definiert das Stufen- und Progressionsmodell für Ihre Softwareänderungen.
Orchestrierung
Orchestrierung ist ein Werkzeug, das die gesamte Automatisierung koordiniert. Sie können Skripts aufrufen, um neue Umgebungen auf eine Reihe von virtuellen Maschinen mit Skript Umgebungen zu erstellen, Code mithilfe von Skripterstellung in dieser Umgebung bereitstellen, das Datenbankschema mit EDD aktualisieren und dann diese Version der Anwendungen und Skripts automatisch starten nächste Stufe der Bereitstellungspipeline.
Fazit
Erst wenn man das alles verstanden hat, sollte man anfangen sich Gedanken zu machen, mit welchen Tool dies am besten unterstützt werden kann.
Noch kein Beitrag vorhanden