Das DASA DevOps-Prinzip 6: Automate Everything You Can
Automatisieren – oft ein Versprechen für hohe Effizienz in Unternehmensprozessen – wird auch in Zukunft bei den Personen, die tagtäglich an den Motoren der Automatisierung arbeiten, keinen Halt machen. Insbesondere wenn DevOps nach dem sechsten Prinzip der DASA in das Unternehmen integriert wird.
Die Chancen und Möglichkeiten durch Verbesserungen von Prozessen und einhergehende Produktionssteigerungen im Rahmen von Automatisierungen sind keine neuen Erkenntnisse. Die Automatisierung der Prozesse rund um die Entwicklung und den Betrieb der Informationstechnologie jedoch anscheinend schon. Und das, obwohl gerade der Einsatz von Informationstechnologie zu wirtschaftlichen Vorteilen führen kann.
Das DASA DevOps-Prinzip 6: Automate Everything You Can
To adopt a continuous improvement culture with high cycle rates and to create an IT organization that receives instant feedback from end users or customers, many organizations have quite some waste to eliminate. Fortunately, in the past years, enormous gains in IT development and operations can be made in that respect. Think of automation of not only the software development process (continuous delivery, including continuous integration and continuous deployment) but also of the whole infrastructure landscape by building next-gen container-based cloud platforms that allow infrastructure to be versioned and treated as code as well. Automation is synonymous with the drive to renew the way in which the team delivers its services. [1]
DevOps – derzeit ein gern genutzter Begriff für Optimierung von Entwicklungs- und Betriebsprozessen in den IT-Abteilungen – soll dazu beitragen, dass genau diese Potenziale geschöpft werden. Das sechste Prinzip "Automatisiere alles, was du kannst" versucht auf technologischer Sicht eine Steigerung der Wertschöpfung zu erreichen.
Der Ansatz beansprucht jedoch per se nicht alle gängigen und bekannten Modelle sowie Methoden zur Automatisierung für sich selbst. Vielmehr wird versucht, durch DevOps viele dieser in das Unternehmen zu integrieren. Insbesondere Continuous Delivery berücksichtigt die Anstrengungen möglichst aller Prozesse rund um die Veränderungen wie auch Anpassungen von Systemen und Software durch entsprechende Prozesse zu automatisieren.
Was ist Continuous Delivery?
Der Begriff Continuous Delivery wird unter anderem von den Autoren Jez Humble und David Farley beschrieben [2]. Wer bei ihnen eine genaue Begriffsdefinition erwartet, wird lediglich Anti-Patterns finden können. Denn aus Ihrer Sicht ist eine Development-Pipeline zu implementieren, welche einige Aspekte umgeht. Unter anderem zählen dazu die Vermeidung manueller Freigaben eines Software-Deployment, Abschluss der Software-Verteilung durch die Entwicklungsabteilung und manuelles Konfigurationsmanagement von Produktivumgebungen.
Verändert man die Sichtweise von Anti-Patterns hin zu möglichen Schlussfolgerungen, ermöglicht Continuous Delivery nach der Entwicklung oder einer Anpassung der Software eine automatisierte Vorgehensweise. Das sechste DevOps-Prinzip der DASA trifft im Kern diese Development-Pipeline, sodass wiederkehrende manuelle Schritte automatisiert werden, um ein schnelleres Deployment zu ermöglichen.
Die Vorteile von Continuous Delivery sind in mehreren Bereichen zu finden. Zum einen ermöglicht eine automatisierte und somit effizientere Vorgehensweise die Verkürzung der Time-to-Market-Zeiträume. Demnach kann ein Produkt in kurzen Zyklen mit kleinen Verbesserungen ausgeliefert werden. Zum anderen ermöglicht das stetige Feedback und die kontinuierlichen Verbesserungsmaßnahmen, genau dieses Feedback zu erhalten. Das Team kann sich auf die kleinen Releases fokussieren, sodass auch im produktiven Umfeld der Ursprung von Fehlern durch die Release-Zyklen überschaubar ist.
Der Input in die automatisierte Prozesskette wird von den agilen Teams geliefert. Die Organisationseinheit wurde bereits in dem Prinzip "Cross-Functional Autonomous Teams" näher beschrieben, sodass in diesem Artikel nicht näher darauf eingegangen wird.
Automatisierte Softwarepakete werden erstellt und in die Software-Bibliothek aufgenommen. Des Weiteren erhält das Paket eine eindeutige Kennung. Dieser Prozess wird im Wesentlichen als Continuous Integration bezeichnet und fördert die Paketierung.
Aufgrund der Wiederholung dieser Aufgabe durch eine Programmroutine ergeben sich Vorteile in Bezug auf die Verteilung der Tätigkeiten. Die Zeit und der Aufwand können vollständig auf die Development-Pipeline verlagert werden, sodass die agilen Teams sich qualitativ hochwertigeren Aufgaben zuwenden können.
Im nächsten Schritt erfolgen automatisierte Tests, die wiederum in drei Typen unterschieden werden. Zunächst erfolgen statische Tests, die eine Überprüfung des Quellcodes implizieren, um erste Fehler frühzeitig zu ermitteln. Eine Erweiterung dessen erfolgt durch die Komponententests. Hierbei wird die Software in einen initialen Zustand versetzt und der Output des Programms mit dem erwarteten Ergebnis verglichen. Das dritte Testverfahren sind die Functional Tests, die eine Überprüfung des gesamten Systems und dessen Verhalten bedeuten. Im deutschen ist diese Testmethode eher unter dem Begriff der Regressions- bzw. Integrationstests bekannt.
Automatisierte Tests stellen einen hohen Reifegrad im Test-Management einer Organisation dar. Bereits die Definition von Soll-Ergebnissen der Tests sowie die Test-Routine und auch Test-Varianten erfordern eine hohe Weitsicht der Mitarbeiter. Zunächst scheint dieser Schritt zu vermehrten Aufwänden zu führen, allerdings kann gerade durch Massentests eine hohe Skalierung ohne eine qualitative Verschlechterung der Testdurchführung erreicht werden. Nach der erfolgreichen Testdurchführung erhält das Software-Paket nun die Freigabe für das Überleiten an die Produktivsysteme. Hierzu wird durch das automatisierte Deployment ein Prozess durchgeführt, um die Software zu veröffentlichen. In der Praxis werden u. a. folgende Ansätze zum Deployment von Software genutzt, die alle vermehrt den Kunden in die Feedbackschleife einbinden:
- Dark Launches: Ein Dark Launch wird gerne durch Software-Unternehmen verwendet, um Funktionalität zwar zur Verfügung zu stellen, jedoch noch nicht prominent zu nennen. Die Softwarenutzer kennen somit die Funktionalität noch nicht, obwohl im Produktivsystem diese getestet werden kann.
- Canary Releases, Friends and Family: Der Ansatz von Canary Releases, Friends and Family beinhaltet die Veröffentlichung der Änderung an einen kleinen Personenkreis bevor dieser auf alle Benutzer erweitert wird.
- Blue-Green Deployment: Beim Blue-Green Deployment wird die Anpassung in zwei Versionen veröffentlicht. Einerseits in der neuen Version und in der bisherigen. Dadurch kann erreicht werden, dass bei einem Fallback die Änderung durch Zurücksetzen der Version schnell durchgeführt werden kann.
- Feature Switches: Ein Feature Switch impliziert das Ein- oder Ausschalten eines Features in der Produktivumgebung.
Die Testansätze ermöglichen durch ihre jeweiligen Ausprägungen Vorteile in Bezug auf die Vorgehensweise und den Einbezug von Testgruppen. Beim Dark Launch kann in dem Produktivsystem getestet werden, obwohl den Usern die Funktionalität noch nicht bekannt ist. Weiterhin kann durch Canary Releases, Friends and Family ein privilegierter Personenkreis in die Testgruppe aufgenommen werden. Der Feature Switch ermöglicht dem Nutzer die Auswahl, ob er Tester werden möchte oder nicht.
Die ursprünglichen Vorgehensweisen durch Testphasen wie beispielsweise im Rahmen des Wasserfall-Modells werden damit aufgehoben, sodass die Abgrenzung größerer Releases verschwindet und teilweise der Nutzer dynamisch in die Tests einbezogen werden kann. Die Automatisierung dieser Testprozesse und -ansätze ermöglicht eine effiziente Verteilung der Pakete und schnelle Fallback-Szenarien, um den Ausfall von Produktivumgebungen zu vermeiden. Weiterhin können definierte Abnahme- oder auch Fallback-Kriterien zu einer Bewertung der Tests führen und anschließende Prozesse starten.
Provisionierung der Systeme
Die Freigabe zum Deployment mündet in die automatisierte Provisionierung des Systems. Die DASA beschreibt in ihren Ausführungen dazu zwei Ansätze der Systemverwaltung. Es wird zwischen dem Pets-Ansatz (engl. für Haustier) und dem Cattle-Ansatz (engl. für Vieh) unterschieden. Nach dem Pets-Ansatz werden die Systeme inklusive der Software ähnlich wie ein Haustier gepflegt. Die Systeme haben oft eine eindeutige Nummer oder Bezeichnung und müssen in der Architektur weiter erhalten bleiben. Demnach wird im Fehlerfall dieser analysiert und gefixt.
Erkrankt hingegen ein Nutztier, wird das Vieh aus der Herde entnommen, um die anderen Tiere nicht anzustecken, und durch ein neues Vieh ersetzt. Nach dem Cattle-Ansatz erhalten die Systeme zwar ebenfalls eine eindeutige Bezeichnung, die lediglich der Identifikation dient, aber durch eine weitere Instanz ausgetauscht werden kann. Im Fehlerfall wird der Fehler nicht gefixt, sondern ein neues System aufgebaut.
Dieser Ansatz wird durch veränderliche und nicht veränderliche Infrastruktur in der Praxis eingesetzt. Die Container-Technologie ermöglicht die Erstellung von Software-Paketen und eine entsprechende Veröffentlichung. CloudFoundry bietet beispielweise die Möglichkeit, einen Node.js-Server in Form eines Containers aufzusetzen. Tritt ein Fehler auf, wird die Instanz beendet. Dieser Fehler kann durch das Deployment eines neuen Containers behoben werden. Im Gegensatz dazu wird durch eine eigene Instanz das Beheben des Fehlers im Quellcode und das Neustarten des Node.js-Servers ermöglicht. Der Cattle-Ansatz ermöglicht die Automatisierung der Systembereitstellung und vermeidet erhebliche Aufwände für die Pflege von Systemen. Die Administratoren haben in der Vergangenheit ihre "Pets" gepflegt. Durch den Automatisierungsansatz erhalten IT-Abteilungen dadurch wichtige Effizienzsteigerungen, sodass der Cattle-Ansatz zu verfolgen ist.
Integration von Everything as a Service / Everything as Code
In der heutigen System-Umgebung erhält die Cloud einen immer wichtiger werdenden Stellenwert. Die Klassifizierung der Cloud-Anwendung von Infrastructure as a Service, über Platform as a Service bis zu Software as a Service führen dazu, dass die zu betreibenden Komponenten in den Wirkungsbereich von Dienstleistern übergeben wird. Außerdem erfolgt eine höhere Standardisierung der entsprechenden Bestandteile des Cloud-Services.
Die Auswahl und Integration entsprechender Cloud-Umgebungen ist insbesondere für die Development-Pipeline und den Betrieb der Software ein wesentlicher Aspekt. Die Zusammenführung des IT-Betriebs und der IT-Entwicklung erhält demnach eine immer größere Bedeutung. Entscheidet ein Unternehmen sich nach dem Cattle-Ansatz für nicht-veränderliche Umgebungen, müssen bei Maintenance-Aufgaben die Systeme neu veröffentlicht werden, sodass die agilen Teams eine logische Konsequenz sind.
Die Integration der Cloud-Plattformen kann durch Setup as code, Test as code oder auch Front-End as Code in die Automatisierungsprozesse integriert werden. Everything as code spannt einen weitreichenden Schirm über einzelne Automatisierungsmöglichkeiten. Demnach wird eine einheitliche Vorgehensweise zur Automatisierung festgelegt. Die Ingenieure der Delivery-Pipeline erhalten eine durchgängige Verfahrensweise, wie diese Schritte integriert werden und auch Ausprägungen gestaltet werden können.
Feedback-Integration in die Development-Pipeline
Das Thema Feedback ist ein zentraler Aspekt von DevOps [3]. Ziel ist es, Feedback vollumfänglich in das Unternehmen zu integrieren, um eine kontinuierliche Verbesserung als "Tagesgeschäft" zu erreichen.
Die Development-Pipeline ist nach dem sechsten Prinzip ebenfalls um Feedback zu erweitern. Somit ist in dem Prozess der Software-Paketierung Feedback zu integrieren, damit einerseits bei erfolgreicher Paketierung über den aktuellen Stand des Software-Pakets informiert wird und andererseits im Fehlerfall geprüft werden kann, ob die Software fehlerhaft war bzw. der Paketierungs-Prozess verbessert werden muss.
Ergebnisse aus der Test-Phase sollten idealerweise unabhängig von DevOps im Rahmen des Test-Managements in die kontinuierlichen Verbesserungsmaßnahmen integriert werden. Im Rahmen von Continuous Delivery soll das Feedback für die Entwicklung wie auch Testprozesse integriert werden, damit vermieden wird, dass fehlerhafte Software in produktive Systeme verteilt werden. Bei einer hohen Qualität der automatisierten Tests kann demnach die Gefahr von Software-Fehlern reduziert werden, sodass die produktiven Systeme wesentlich stabiler werden.
Das Feedback aus dem automatisierten Deployment kann Testergebnisse aus nachträglichen produktiven Tests zurückmelden. Treten dann Fehler auf, welche auf die neue Software zurückzuführen sind, ermöglicht das Feedback ein schnelles Eingreifen der agilen Teams. Feedback aus der Provisionierung kann ebenfalls zur Verbesserung des Prozesses verwendet werden.
Das Ziel des Feedbacks sollte eine hohe Qualität der Softwarepakete und auch der Prozesse zur Erzeugung dieser Pakete sein. Denn nur durch eine hohe Qualität der Prozesse und Produkte kann eine hohe Effizienz der IT erreicht werden.
Alter Wein im neuen Prozess?
Bei einer Exkursion in die Bücher der IT Infrastructure Library entdeckt man, dass bereits dort sogenannte Standard-Changes verwendet werden können, um Veränderungen des Systems und der Software zu automatisieren. Sicherlich ist das richtig und auch Continuous Delivery ist keine reine Neuentdeckung dessen, wie eine IT-Abteilung die Veröffentlichungen regeln kann. Betrachtet man aber die Prozesse eines Unternehmens, welche den Einsatz von Informationstechnologie betreffen, kommt man schnell über die Sicht von Continuous Delivery hinaus. ITIL versucht durch den Service-Lifecycle die Strategie eines Unternehmens ebenfalls einzubeziehen, jedoch aus der Sicht des IT-Services.
DevOps lenkt den Fokus auf den Kunden, wie im Artikel zum "DevOps-Prinzip 1: Customer-Centric Action" beschrieben. Demnach ist der IT-Service zwar noch Bestandteil der Ausrichtung, allerdings immer mit Sicht auf den Kunden. Die agilen Teams sollen demnach das Business berücksichtigen bzw. im Idealfall einen Vertreter dessen beinhalten. Das Aufgabenfeld des DevOps-Engineer verändert sich somit von der technischen Sicht auf die Development-Pipeline zu einer integrierten Unternehmenssicht.
Die Automatisierung sollte demnach nicht bei der Einrichtung und Steuerung einer Development-Pipeline enden. Denn eine Integration der unternehmerischen Anforderungen führt zu weiteren Automatisierungen.
Automatisierung endet nicht in der Development-Pipeline
Nehmen wir einmal an, ein Unternehmen entwickelt ein neues Produkt. Das Produkt soll im Webshop verkauft werden, welche durch das Unternehmen On-Premise verwaltet wird. Ob es sich um eine Schokolade mit Einhorn-Farben oder Tickets für ein Konzert handelt, ist dabei irrelevant. Die Systeme können den Ansturm von Kunden nicht aushalten und fallen aus.
Nach dem sechsten Prinzip der DASA "automatisiere alles, was du kannst" trifft dies auch auf die Skalierung der Systeme zu. Integriert man nun die Sicht der Unternehmensanforderungen in die Systeme, wird ebenfalls die Geschäftslogik in die Development-Pipeline integriert. Ermittelt nun das Monitoring der Systeme eine zu hohe Auslastung und entscheidet, dass betriebswirtschaftlich eine Skalierung sinnvoll ist, wird eine neue Server-Instanz erstellt. Der Kreativität sind keine Grenzen gesetzt und die Praxis zeigt, dass diese Vorgehensweise keine Utopie ist [4].
"Automatisiere alles, was du kannst" endet nicht bei der Development-Pipeline, sondern sollte auf weitere Bereiche übertragen werden. Beispielsweise sind bereits Werkzeuge verfügbar, die eine automatisierte Dokumentation von Programmen durch das Auslesen des Quellcodes und der Kommentare ermöglicht [5]. Weiterhin gibt es Dienste, die die gesamte Entwicklung von Programmen vereinfachen [6].
Die Transformation von Prozessen außerhalb der IT-Abteilung kann eine weitere Schlussfolgerung darstellen, da der organisatorische Aufbau durch Cross-Functional Teams beeinflusst wird. Demnach stellt auch die Anpassung der gesamten Organisation eine Veränderung dar und die Prinzipien können in weiteren Abteilungen integriert werden.
Fazit
Der philosophische Ansatz – alles, was möglich ist, zu automatisieren – kann hohe Anforderungen an das Unternehmen stellen. Die DASA bezieht sich zunächst auf die Development-Pipeline, da diese einen zentralen Prozess in der Softwareentwicklung darstellt. Weiterhin führt die Integration von Continuous Delivery zu einer Anpassung der angrenzenden Prozesse und Systeme. Die Integration von On-Premise- sowie Cloud-Komponenten erfordert ein hohes Skillset der DevOps-Ingenieure, sodass zwar durch die Automatisierung Tätigkeiten auf die Systeme verlagert werden, aber neue Tätigkeitsgebiete entstehen.
Die Integration von DevOps in das Unternehmen endet hierbei nicht mit der Auslieferung von Softwarepaketen, sondern kann darüber hinaus weitere Relevanz erhalten. Verändert sich die Unternehmenskultur von der klassischen phasenorientierten und manuellen Ausrichtung hin zu hochautomatisierten Unternehmensprozessen mit besonderem Fokus auf Automatisierung, können die freien Ressourcen zur Verbesserung der Marktposition und Unternehmenswahrnehmung genutzt werden. Automatisiere alles, was du kannst – ein Ansatz von insgesamt sechs für den Beginn einer neuen Generation von IT-Abteilungen und ganzer Unternehmen.
- Die DASA DevOps-Prinzipien
- J. Humble, D. Farley, 2010: Continuous Delivery
- G. Kim, P. Debois, J. Willis & J. Humble: DevOps Handbook
- Informatik Aktuell – Kai Weingärtner: Autarke Teams und DevOps: So skaliert Continuous Delivery
- Doxygen – automatische Dokumentation von Quellcode
- Stamplay
Publikationen
- IT-Service Management mit FitSM
- Perspektivwechsel im IT Service Management: Erfolgsgeschichten oder - Dierk Söllner, Peter Bergmann, itSMF
