Suche
Der Microsoft-Blick auf DevOps

Der DevOps-Zyklus

Artur Speth

© Microsoft

Bisher betrachtete man beim Application-Lifecycle-Management-Prozess nur die eigentliche Wertschöpfungskette, und zwar die Entwicklung selbst. Fokussiert wurde auf die Verbesserung der Anforderungsmanagement-, Entwicklungs- und Testprozesse. Dabei steigerten agile Praktiken und der Einfluss von Lean-Management-Methoden die Effizienz und verhalfen somit zu kürzeren Releasezyklen von Software.

Durch die skizzierte Veränderung im Application Lifecycle Management (ALM) wurde zwar öfter und schneller an den Product Owner geliefert, jedoch erreichten diese kurzen Releasezyklen meistens nicht den Anwender. Wie kann nun im Entwicklungsteam eine Kultur etabliert werden, durch die agile Prozesse und Methoden auch auf die „letzte Meile“, also den Release-Management-Prozess und die Übergabe der funktionsfähigen Software an den IT-Betrieb, übertragen werden können?

Der Begriff „DevOps“ leitet sich aus „Dev“, dem Softwareentwickler, und „Ops“, dem IT-Betriebsspezialisten (Operations) ab und beschreibt allgemein die Zusammenarbeit und Integration von Softwareentwicklern und IT-Betriebsspezialisten. DevOps sollte als ein umspannender Begriff für die Prozesse, Werkzeuge und natürlich die beteiligten Personen verstanden werden. Auch wenn DevOps viele Ausprägungen und Facetten hat, so beschäftigt es sich nicht nur damit, wie Software besser gebaut, sondern auch bereitgestellt und betrieben wird. Eine DevOps-Kultur ermöglicht es, die Durchlaufzeiten zu minimieren, IT-Ressourcen zu optimieren und die Qualität und Verfügbarkeit der Software zu erhöhen. Dies erfordert, dass die gesamte Organisation in einen vollständigen Application Lifecycle investiert. Ein zentraler Gedanke dabei ist die Automation von Vorgängen, die sonst manuell durchgeführt würden und somit wenig transparent und schlecht nachvollziehbar für die Qualitätskontrolle sind.

Was versteht Microsoft unter dem Begriff DevOps?

Für Microsoft ist das Thema DevOps nicht neu, wenn auch erst jetzt sehr präsent darüber gesprochen wird. Seit Jahren investieren Microsofts Produktgruppen wie Xbox, Bing oder Visual Studio in DevOps sowohl für On-Premise- als auch Cloud-Infrastrukturen (Abb. 1). Im Entwicklerkontext betrachtet hat DevOps zwei Ausprägungen. Um dies etwas zu verdeutlichen, möchte ich folgende Frage stellen: Wann generiert eine neue Funktion auch wirklichen Mehrwert?

Abb. 1: Der DevOps-Zyklus aus Microsoft-Sicht

Abb. 1: Der DevOps-Zyklus aus Microsoft-Sicht

Eine neue Funktion generiert nur dann wirklichen Mehrwert, wenn man es schafft, sie zeitnah (also vor der Konkurrenz) in einer akzeptablen Qualität an den Anwender auszuliefern. Dazu bedarf es einer automatisierten Releasepipeline. Es werden immer noch zu viele Schritte beim Deployment einer Anwendung manuell gemacht, mit dem Nachteil, dass der Deployment-Prozess zu lange dauert und fehleranfällig ist. Ein Schlüssel zu DevOps liegt also in der Automation des Deployment-Prozesses. Dazu benötigt man entsprechende Werkzeugunterstützung. Idealerweise integriert sich das Deployment Tool in eine durchgängige ALM-Lösung, um die Nachvollziehbarkeit von der Anforderung über die Implementierung bis hin zur Bereitstellung sicherzustellen. Hierbei orchestriert das Deployment-Tool den Releaseprozess über einen Workflow. Somit kann man sicherstellen, dass der gleiche Code jederzeit auf die gleiche Art und Weise bereitgestellt werden kann.

Ein neues Feature generiert nur wirklichen Mehrwert, wenn man in der Lage ist zu erfahren, wie und ob ein Anwender das Feature nutzt. Im Automotorsport kann mittels Telemetrie im Fahrzeug jederzeit der Zustand des Rennwagens auf der Strecke vom Team abgefragt werden. Dieses Konzept der Telemetrie überträgt man nun auf die Softwareentwicklung. Zum einen sollte Applikationstelemetrie den Entwickler in die Lage versetzen, ein besseres Verständnis für die Nutzung seiner Anwendung zu bekommen. Treten Fehler in der Anwendung auf, erhält der Entwickler frühzeitig eine Information über die Fehlerursache und im besten Fall gleichzeitig ein Protokoll sowie den Call Stack des Absturzes. Aber auch Performance- und Verfügbarkeitsstatistiken der Anwendung sollten dem Entwickler über ein Portal zugänglich gemacht werden. Somit ist das Team in der Lage, ein besseres Verständnis über die Nutzung der Anwendung zu bekommen, und hat darüber hinaus auch die entsprechenden Daten zur Verfügung, um im Fehlerfall eine entsprechende Ursachenanalyse (Root Cause Analysis – RCA) durchzuführen.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Das DevOps-„Elephant in the room“-Problem

Der englische Spruch „Elephant in the room“ beschreibt ein großes Problem, das im Raum steht, aber nicht erkannt wird. Ähnlich ergeht es einem auch, wenn man sich mit dem Begriff „DevOps“ auseinandersetzt. Es gibt unterschiedliche Interpretationen des Begriffs, und sicherlich hat jedes Entwicklungsteam seine speziellen Herausforderunge, um eine gute DevOps-Kultur etablieren zu können. Um dies zu verdeutlichen, möchte ich auf einige der Punkte eingehen:

Kollaboration zwischen Entwicklern und Administratoren: Idealerweise überwindet man künftig die meist organisatorisch geschaffenen Grenzen zwischen IT-Betrieb und Entwicklungsabteilung. Dazu bedarf es ganz neuer Ansätze in der Teamstruktur. Ähnlich wie man in agilen Entwicklungsprozessen gesehen hat, dass die Tester viel näher an den Entwicklungsprozess rücken, überträgt man das Konzept auf die Administratoren. Das Team übernimmt nun die Gesamtverantwortung für das Feature bzw. die Anwendung. Vom Konzept über die Entwicklung, Test, bis hin zum Betrieb. Dies bedeutet nicht, dass wir künftig keine Administratoren mehr benötigen. Vielmehr helfen sie dabei, das System- und Netzwerk-Know-how in das Entwicklerteam einzubringen, um dieses in die Lage zu versetzen, Automationscode für die Infrastruktur zu schreiben.

Infrastruktur als Code und Automation: Infrastruktur als Code ist eines der Schlüsselelemente im Kontext von Continuous Delivery. Mittels PowerShell-Desired-State-Configuration-(DSC-)-Skripten können alle Abhängigkeiten der Anwendung, wie z. B. SQL Server, IIS etc., beschrieben und auf den Systemen in der Releasepipeline angewendet werden. Die notwendigen Einstellungen, wie Netzwerkeinstellungen, CPU und Arbeitsspeicher werden in Konfigurationsskripten beschrieben und zusammen mit dem Quellcode der Anwendung in die Versionsverwaltung eingecheckt. Idealerweise arbeitet hierbei der Entwickler mit dem IT-Betriebsspezialisten zusammen. Somit ist man in der Lage, ähnlich wie die Anwendung auch die zugrunde liegende Infrastruktur auf einen bestimmten Releasestand auszurollen. Müssen weitere Server zur Skalierung der Anwendung hinzugefügt werden, kann man mit den getesteten Konfigurationsskripten sicherstellen das keine Unterschiede in der Konfiguration (Configuration Drift) auftreten.

Kleine Bereitstellungen und Feature-Switches: Große Big-Bang-Releases sind in den seltensten Fällen gut gelaufen. Auch wenn man die Anwendung und das Deployment vielfach getestet hat, treten Fehler, mit denen man nicht gerechnet hat, meistens erst im Produktionsbetrieb auf. Idealerweise ist die Anwendung so modular aufgebaut, dass man über viele kleine Bereitstellungen den vollen Funktionsumfang ausliefern kann. Dabei spielt auch die Anwendungsarchitektur eine wesentliche Rolle. Mit Feature-Switches können z. B. bestimmte Funktionen inkrementell ausgerollt werden, obwohl sie noch nicht vollständig implementiert sind. Auch hat man durch die Verwendung von Feature-Switches die Möglichkeit, Features mit einem abgeschirmten Personenkreis zu testen, bevor die Änderungen auf alle Anwender ausgerollt werden

DevOps ist also nicht nur die Betrachtung notwendiger Werkzeuge für den Release-Management-Prozess. Vielmehr ist DevOps als ein umfassender Schirm für alle Praktiken, Prozesse und die Werkzeuge zu sehen. Auch kann DevOps als agile Version 2 angesehen werden. Es erweitert den agilen Prozess um den Release-Management-Prozess und bindet das IT-Betriebsteam stärker in den Softwareentwicklungsprozess ein. Im Rahmen von ALM bietet Microsoft mit Release-Management sowie Application Insights zwei Produkte an, um den DevOps-Zyklus zu schließen. Zur Build-Konferenz im April wird die nächste Generation von Release-Management vorgestellt. In einem der nächsten Artikel wird es hierzu mehr Details geben.

Verwandte Themen:

Geschrieben von
Artur Speth
Artur Speth
Artur Speth arbeitet als Senior ALM Architect in der Developer Platform & Strategy Group bei Microsoft und ist Spezialist für Visual Studio und Team Foundation Server. Er berät Kunden bei der Verbesserung ihrer Softwareentwicklungsprozesse und beim effizienten Einsatz der Microsoft-Entwicklungs- und Testwerkzeuge.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: