Die DevOps-Kultur

DevOps ist einer der Begriffe, die momentan in aller Munde sind. DevOps klingt nach großer Organisation, Vollautomatisierung, einer Menge neuer Technologie. Also nach etwas, was für kleine Projekte oder Organisationen mit wenigen Beteiligten weniger relevant ist.
Im Kern geht es jedoch um einen kulturellen Wandel, von dem Softwareprojekte egal welcher Größe profitieren können. Die DevOps-Kultur ist ein wesentlicher Baustein dabei, Software in Zukunft produktiver entwickeln zu können.

Der Ausgangspunkt für DevOps ist die wesentliche Erkenntnis, dass die ganze Arbeit, die in der Softwareentwicklung geleistet wird, solange wertlos ist, bis die Software vom Anwender eingesetzt werden kann. Um diesen Wert möglichst schnell realisieren zu können, ist es essentiell, die erzeugte Anwendung möglichst reibungslos und zügig ausliefern zu können. Im agilen Umfeld wird darauf abgezielt, nach jeder Iteration ein auslieferbares Inkrement der Software zu erzeugen. Dass diese Auslieferung auch tatsächlich - und noch wesentlich häufiger - erfolgen kann, wird durch die Prinzipien und Vorgehensweisen von DevOps angestrebt.

Neben der schnelleren Auslieferung spielt in der DevOps-Kultur auch das unmittelbare Feedback von der Anwendung an die Entwickler eine Rolle, das dazu genutzt wird, frühzeitig Vorkehrungen gegen Systemausfälle treffen zu können. Die Freiheit zum Testen und Experimentieren ist ein weiterer Baustein der DevOps-Kultur. Zum Einstieg werden wir uns in diesem Artikel jedoch auf das schnellere Ausliefern von Software konzentrieren.

Vorausplanen

Damit die schnellere Auslieferung gelingen kann, ist es essentiell, dass Fragen zum Deployment, zur Fehlervorbeugung und zur Sicherheit, die früher oft kurz vor dem Deployment oder während des Betriebs aufgekommen sind, frühzeitig im Entwicklungszyklus beantwortet werden. Das klappt selbstverständlich wesentlich besser, wenn die in größeren Projekten oft getrennten Disziplinen der Softwareentwicklung und des IT-Betriebs Hand in Hand arbeiten.

Das Ziel muss hierbei sein, den Weg eines Features nach dem Abschluss der Entwicklungsarbeit bis in die Produktionsumgebung möglichst vollständig zu automatisieren. Neben dem Zusammenstellen der Installationsdateien zu einem Paket und dem Ausrollen desselben geht es hier vor allem um die Automatisierung von Tests, so dass man bei einem Deployment auch sicher sein kann, dass dieses den gewünschten Nutzen erreicht.

Tools sind zum Einstieg zweitrangig

Wie eingangs erwähnt, stehen die Prinzipien im Vordergrund, so dass der Einstieg auch ohne einen Zoo an neuen Tools gelingen kann. Den positiven Effekt, den auch einfache Mittel haben können, kann ich aus eigener Erfahrung bestätigen.

Vor einigen Jahren war ich Teil eines Projektteams, das größere Anpassungen an einer SharePoint-Plattform vorgenommen hat. Zu Anfang waren die Deployments jedes Mal aufwändig und fehleranfällig. Bald haben wir jedoch begonnen, die Deployment-Skripts jede Nacht auf einer virtuellen Maschine zu testen, die mit dem letzten ausgelieferten Stand der Produktioinsumgebung initialisiert wurde. Das Deployment musste so also vollständig automatisiert werden und auch die Tests konnten am nächsten Tag direkt auf einer Umgebung stattfinden, die der Produktionsumgebung sehr ähnlich war. Der Begriff DevOps war zu dieser Zeit (2009) gerade erst am entstehen und auch die Toollandschaft hat sich seitdem deutlich weiterentwickelt. Die Ziele und positiven Effekte waren jedoch die gleichen. Die Deployments auf der SharePoint-Umgebung waren danach jedenfalls deutlich einfacher.

Einstieg in DevOps

Wie können also die ersten Schritte im DevOps-Bereich aus Entwicklersicht aussehen? Nicht jedes Projekt startet hierbei von null; der Vollständigkeit halber enthält die folgende Liste auch Punkte, die ohnehin selbstverständlich sein sollten:

1. Frühzeitige Integration der Code-Stände von verschiedenen Entwicklern in einem Quelltextverwaltungssystem. Hierfür gibt es natürlich viele weitere gute Gründe; aus DevOps-Sicht sollte die Frage, wie die Dateisysteminhalte von verschiedenen Rechnern denn zu dem gerade gültigen Code-Stand zusammengefasst werden sollen, jedoch niemals aufkommen. Es gibt nur einen gültigen Codestand und das ist der in der Quelltextverwaltung.
2. Automatisierung des Build-Prozesses, so dass ein vollständiges Installationspaket erzeugt wird. Auch das Zusammensuchen von Dlls kurz vor dem Installationsdatum ist ein Zeitfresser erster Güte und immens fehlerträchtig. Es muss also möglich sein, einen Build nach immer gleichen Regeln in nur einem Schritt durchführen zu können.
3. Erstellen von Unit Tests, die möglichst häufig ausgeführt werden. Die Tests sollten auf alle Fälle im Zuge des Builds prüfen, ob Abweichungen im Programmverhalten vorliegen. So werden diese frühzeitig entdeckt und können schnell behoben werden.
4. Automatisierung der Installation der Anwendung sowohl auf Testumgebungen als auch für die Produktivumgebung. Dadurch kann diese häufig ausgeführt werden, wovon zum einen die Tests profitieren und zum anderen letztendlich auch der Anwender, der schneller in den Genuss neuer Features kommt.
5. Hinzufügen von automatisierten Integrationstests, die das Verhalten der Anwendung auf den Testsystemen ohne Benutzerinteraktion prüfen. Zusätzlich zu den Unit Tests verifizieren diese Tests, dass die Anwendung als Ganzes den gewünschten Funktionsumfang bietet.

Selbstverständlich kann man diese Liste weiter ausführen; zumindest für den Teil des Deployments, der in DevOps wesentlich ist, werden durch diese Schritte schon bedeutende Verbesserungen erreicht. Chaos-Tage beim Deployment sollten dann auf alle Fälle der Vergangenheit angehören.

DevOps im Microsoft-Ökosystem

Microsoft bietet mit den Visual Studio Team Services und deren On-Premise-Variante Team Foundation Server ein Toolset, das viele DevOps-Operationen unterstützt. Dazu zählen die Quelltextverwaltung und die Build-Automatisierung. Außerdem ist das Release Management enthalten, mit dem das Deployment von Anwendungen automatisiert werden kann.

Je nach Anzahl der Benutzer können diese Tools auch kostenfrei genutzt werden, so dass dem Einsatz in kleineren Projekten nichts im Wege steht.

DevOps für kleine Projekte

Zu Anfang dieses Blogeintrags haben wir bereits darauf hingewiesen, dass DevOps keine Frage der Projektgröße ist. Auch wenn die Umsetzungstiefe und die Anzahl der einbezogenen Personen variiert, so ist die Beachtung der DevOps-Prinzipien auch in kleineren Projekten sinnvoll. Hier sollte man genau betrachten, welche Schritte bei der Auslieferung manuell zu erledigen sind oder Probleme verursachen. Diese sollte man anschließend automatisieren.

Die Anforderungen, dass mit einem Build ein gesamtes Paket erzeugt werden sollte und dass das Deployment mit möglichst wenig Benutzerinteraktion vonstatten gehen soll, gilt natürlich auch hier. Das Visual Studio bietet hierfür schon viele Möglichkeiten, indem auch auf dieser Ebene der Build-Prozess automatisiert werden kann. Auch kleine Batch- oder PowerShell-Skripte können bereits eine deutliche Verbesserung im Deployment-Prozess bewirken. So kann am Anfang auch auf ein umfangreiches Toolset verzichtet werden.

Buchtipp

DevOps ist natürlich ein weites Feld, das wir im Rahmen dieses Artikels nur anreißen konnten. Es gibt zu diesem Thema ein sehr lesenswertes Buch, das einen guten Einstieg in die Thematik bietet: The Phoenix Project von Gene Kim, Kevin Behr und John Spafford. Ähnlich wie Tom DeMarcos’ Der Termin ist es in Form eines Romans gehalten, in dem sich das gesamte Dev- & Ops-Drama in einer größeren Organisation entfaltet. Wer also noch eine gute Lektüre für die Ostertage sucht, ist mit diesem Buch gut beraten.