Continuous Delivery und DevOps

Bei der Betrachtung von Softwareentwicklung und den damit verbundenen Prozessen lassen sich Projekte aufdecken, in denen die Erweiterungen oft Monate bis zum produktiven Einsatz benötigen. Im Laufe dieser Zeit kommen viele Anforderungen zusammen. Ist die Software dann fertig und kommt in die vielen Abnahme-Teststufen, erschweren unerwartete Probleme die Installationen. Statt an der nächsten Version zu arbeiten, verbringt das Entwickler-Team viel Zeit mit der Fehleranalyse.

Jedem, der sich mit Softwareprojekten beschäftig, wird dies bekannt vorkommen.
Zeit, sich Gedanken darüber zu machen, wie dieser Zustand verbessert werden kann.
 

Agil von der ersten Codezeile bis zur Auslieferung

Während agile Methoden, wie z.B. Scrum und Kanban, die Softwareentwicklung in den vergangenen Jahren verändert und produktiver gemacht haben, so ist der letzte Schritt, die Produktivsetzung und die kontinuierliche Bereitstellung von Testsystemen für z.B. die Fachabteilungen in diesen Methoden eher ein Randthema. Ein Randthema, an dem so mancher Projektleiter, Auftraggeber, Entwickler und System-Administrator bereits verzweifelt ist. Denn gerade beim letzten Schritt, der Produktivsetzung eines neuen Releases, tauchen immerwieder unerwartete Probleme auf.

 

Statt wie Zahnräder ineinanderzugreifen, arbeiten die Abteilungen nicht mit, sondern gegeneinander.

Die DevOps Initiative - What Is This DevOps Thing?

Verstärkt wird dieses Problem durch die, in den meisten Firmen anzutreffende, klare Trennung von Betrieb und Entwicklern. Meist sind diese in unterschiedlichen Abteilungen, die unterschiedliche Zielsetzungen verfolgen angesiedelt.

Entwickler möchten möglichst schnell neue Anforderungen umsetzen, um dem Auftraggeber eine funktionsfähige Version zum Testen zur Verfügung zu stellen. Sie arbeiten mittels agiler Methoden und entwickeln die vom Kunden gewünschten Features. Dank Test Driven Development und einer Continuous Integration Umgebung wird sichergestellt, dass ein fehlerfreier Code produziert wird.

Hauptziel für den Systembetrieb ist ein stabiler Betrieb, der eine möglichst hohe Verfügbarkeit der Systeme garantiert; denn daran wird er gemessen. Um dies zu erreichen, sind wenige Releases und eine mehrstufige Testphase wünschenswert.

Häufige Releases und stetige Einbindung der Fachabteilungen in Tests scheinen so unmöglich. Wenige Ausbringungen, die viele neue Funktionen und dadurch viele mögliche Fehlerquellen enthalten, sind die häufig anzutreffende Realität. Und wenn es dann kracht, fängt ein "Ping-Pong" der Schuldzuweisungen an.

Dies möchte DevOps ändern. Ziel ist eine engere Verzahnung von Entwicklung und Betrieb, um den Auftraggebern „immer“ ein Test- und ein nutzbares Produkt anbieten zu können.

Der Weg zu „DevOps“

Zurück geht DevOps auf den Namen einer Konferenz, die Patrick Debois erstmalig 2009 organisierte [3]. Es ist ein Kunstwort aus Dev (Developer – Entwickler) und Ops (Operations – Systembetrieb, Administratoren). Ziel ist es, Entwickler und ihre Kollegen aus dem Systembetrieb zusammenzubringen.

Aus dem Namen der Konferenz wurde ein Schlagwort, mit dem sich viele Tools und Anbieter schmücken. Es gibt verschiedene Sichtweisen auf das was DevOps ausmacht. Meiner Meinung nach lassen sich diese auf zwei primäre Anliegen reduzieren:

Wichtigstes Ziel von DevOps ist die Verbesserung der Kultur beim Umgang miteinander. Das eindimensionale Abteilungsdenken muss, zugunsten des gemeinsamen Ziels, das Produkt so schnell und fehlerfrei wie möglich zu veröffentlichen, verlassen werden. Erreichbar ist das u.a. durch abteilungsübergreifende Teams, welche alle an der Wertschöpfungskette Beteiligten mit einbinden. In solchen Teams arbeiten Entwickler, Systemadministratoren und Kollegen der Fachabteilung zusammen. Wenn möglich, über die gesamte Projektdauer.

Das zweite Ziel ist, manuelle Schritte zu minimieren und so viel wie möglich zu automatisieren. Sowohl alle Tests als auch das Deployment auf Test/Produktivsysteme sollte mit so wenigen manuellen Schritten wie möglich durchgeführt werden.
Um das zu erreichen, werden Praktiken und Methoden aus der Softwareentwicklung in den Systembetrieb gebracht. Statt nur alle paar Monate ein neues Release im produktiven Umfeld in Betrieb zu nehmen, wird durch Continuous Delivery/Continuous Deployment quasi das ständige Ausbringen einer neuen Version möglich.

 

Abbildung 1: Agil vs Traditionell (Quelle: [2])

Einführung einer Deployment Pipeline

Um die Ziele zu erreichen, sind organisatorische, kulturelle und technische Veränderungen notwendig. Diese lassen sich sicher nicht über Nacht umsetzen. Die möglichen Vorteile von DevOps belohnen jedoch das Durchhaltevermögen.

Organisatorische und kulturelle Änderungen können nur auf das eigene Unternehmen abgestimmt angegangen werden und auch der Zeitrahmen für einzelne Ausbringungen muss für jedes Projekt individuell geprüft werden.

Für die technischen Veränderungen lassen sich allgemeinere Ansätze wählen.

Einer davon ist die Einführung einer Deployment Pipeline, wie sie im Buch „Continuous Delivery“ [CD] beschrieben ist.

Damit ist sowohl der Quellcode, als auch alles was für die Inbetriebnahme notwendig ist, unter Versionskontrolle. In allen Stufen finden automatische Tests wie Unittests, Smoketest, Lasttest und z.B. User Acceptance Tests statt. Durch häufiges Ausführen von Abläufen ist gewährleistet, das Fehler früh und sehr schnell gefunden werden -> fail fast, fail early, fail often.

 


Abbildung 2 - Deployment Pipeline (Quelle: [1])

Einfache Shell Skripte haben damit an vielen Stellen des Prozesses ausgedient. Sie werden durch Tools ersetzt, die es dem Administrator ermöglichen, das Zielsystem zusammen mit den Entwicklern genau nach deren Vorgabe einzurichten.

Die dafür benötigten Beschreibungen erfolgen in einer domainenspezifischen Sprache (Domain Specific Language - DSL) und sind z.B. in SVN oder GIT versionierbar. Was entsteht, ist eine Beschreibung der Infrastruktur im Quellcode Format.

Tools den Systembetrieb - “Infrastructure as Code“

In der Literatur und im Internet findet man Tools die dies unter dem Schlagwort “Infrastructure as Code“ ermöglichen.

So gibt es mit z.B. Chef und Puppet Tools, um Systeme zu beschreiben und mit dieser Beschreibung gleichartige Entwickler, Test, Produktionssysteme aufzusetzen.

Um die automatisierte Verteilung der (Web-)Anwendung auf die Zielsysteme kümmern sich z.B. Capistrano oder Fabric,  und ergänzen damit die erstgenannten Tools. Auch hier werden die auszuführenden Schritte mit einer DSL beschrieben. Dem Dilemma, das ein Entwickler meistens keine Kenntnisse über Pfade etc. des Zielsystems hat und der Administrator die Installationsdetails der Anwendung nicht kennt, kann damit begegnet werden.

Bleibt noch die Installation von (Virtuellen-) Maschinen und die Versorgung mit weiterer Software. Auch dafür gibt es Tools, die diese Schritte automatisieren können. Vertreter sind hier z.B. Cobbler und Vagrant. Beständig alternde Installationsimages können damit durch eine immer aktuelle Softwarebasis abgelöst werden.

Zusammenfassung

Abschließend lässt sich sagen, dass weit mehr hinter dem DevOps Begriff steht, als manche Produktbeschreibung erahnen lässt. Nicht nur durch den Einsatz neuer Tools kann es einen Wandel geben. Insbesondere die tief greifenden Änderungen in der Organisationsstruktur und der Kultur im Unternehmen sind wichtig, benötigen jedoch Zeit.

Nur durch eine Änderung im Denken aller Beteiligten kann DevOps funktionieren.

Auf der technischen Seite gibt es mit den oben genannten Tools gute Möglichkeiten, die agile Bewegung auch in den Systembetrieb zu bringen und Schritt für Schritt eine Deployment Pipeline aufzubauen. Kurze Release Zyklen werden damit zur gelebten Realität und durch hohe Testautomatisierung wird auch eine qualitativ hochwertige Auslieferung gewährleistet.

Offensichtlich ist, dass DevOps sich nicht über Nacht und überall einführen lässt. Doch es lohnt sich für alle Beteiligten den DevOps Weg zu beschreiten. Damit es allen wieder möglich wird, sich auf das wesentliche in der Softwareentwicklung zu konzentrieren: das Schaffen eines Produktes, das gerne vom Kunden eingesetzt wird.
 

Quellen und weitere Informationen:
[1]    „Continuous Delivery“, Jez Humble, David Farley, Addison-Wesley 2010
[2]    „Entwicklung und Betrieb verzahnen mit DevOps“, O.Wolf, iX Developer 1/2013
[3]    DevOps Days 2009,  http://www.devopsdays.org/events/2009-ghent/

-> The WordPress Story
-> „State of DevOps Report 2013
-> Devs care more about Devops than Ops
-> Blog von Patrick Debois