Build-Automatisierung als DevOps-Einstieg

Die Beschleunigung der Auslieferung von Änderungen an die Anwender ist die erste und präsenteste Stoßrichtung von DevOps. Diese erzeugt einen signifikanten Teil der Wertschöpfung von DevOps, weil Code eben erst dann wertvoll wird, wenn er vom Anwender eingesetzt werden kann.

Die Automatisierung des Builds ist daher oft der Anfang einer DevOps-Reise. Die Einstiegshürden sind niedrig, auch weil die Toolunterstützung in diesem Bereich sehr gut ist. Beispielsweise bringen die Visual Studio Team Services alles mit, was man für die Build-Automatisierung in der Cloud braucht. Zusammen mit der Möglichkeit zur Ausführung des Build auf einem on-Premise Host und der Erweiterbarkeit durch Build-Tasks aus dem Marketplace bleiben hier keine Wünsche offen.

Testing in production

Wer sich etwas genauer mit DevOps beschäftigt, stößt ziemlich schnell auf ein Konzept, das einem beim ersten Blick kalte Schauer über den Rücken laufen lässt: Testing in production. Dies hat jedoch nichts mit der berüchtigten „Bananensoftware“ zu tun, die zuvor unzureichend getestet wurde und daher beim Kunden reift.

Klar ist, dass für Testing in production ein großes Maß an Vertrauen in einen Softwarestand vorhanden sein muss. Der Build-Prozess ist der erste Schritt, um dieses herzustellen.

Neben den grundsätzlichen Prüfungen auf syntaktische Korrektheit, die bei der Kompilierung erfolgen, sollten deshalb auch weitere Prüfungen im Build-Prozess vorgenommen werden. Elementar sind hierbei die statische Code Analyse und die Ausführung der Unit Tests und einfacher Integrationstests, die ohne eine dedizierte Umgebung ablaufen können.

Idealerweise wird der Build-Prozess direkt nach dem Commit eines neuen Codestandes gestartet, so dass der Entwickler ein sehr schnelles Feedback erhält, ob der neue Code den Ansprüchen genügt. Daher ist es wichtig, dass der Build-Prozess schnell vonstattengehen kann. Weitere, tiefergehende Tests können in einer anschließenden Release-Pipeline vorgenommen werden.

Vertrauensbildende Maßnahmen in der Release Pipeline

Bei der sprichwörtlichen Bananensoftware war die Release Pipeline sehr kurz – oft ging die Software vom Entwicklerrechner direkt in den Betrieb. Heutzutage kann man mit dem Aufsetzen einer mehrstufigen Release Pipeline in vielen Fällen so viele Tests ausführen, dass einem anschließenden Release in die Produktionsumgebung nichts mehr im Wege steht.

In einer Release Pipeline ist eine Reihe von Umgebungen definiert, auf denen der neu erzeugte Softwarestand nacheinander oder auch parallel installiert wird. Hierbei werden weitere Tests hauptsächlich automatisiert ausgeführt, also beispielsweise:

• Integrationstests, die eine eingerichtete Umgebung benötigen.

• Servicetests, die den Anwendungsstack ohne Oberfläche prüfen.

• Oberflächentests.

• Last- und Performancetests.

Zusätzlich besteht die Möglichkeit, durch Freigabeschritte das Ok von verschiedenen Stakeholdern abzuholen. Dadurch wird schrittweise sichergestellt, dass der Stand die notwendige Reife hat, um schlussendlich in der letzten Umgebung, der Produktivumgebung, installiert zu werden.

Ein guter Überblick über das Release Management, das die Visual Studio Team Services bieten, ist unter diesem Link zu finden.

Vertrauen muss man sich immer wieder neu erarbeiten

Auch wenn die Automatisierung viele lästige Aufgaben übernimmt und zu einer großen Beschleunigung führt: gerade in Projekten, die nicht cloud-basiert sind und deren Testabdeckung noch überschaubar ist, ist die Arbeit am Build- und Release-Vorgehen eine Aufgabe, die täglich ernst genommen werden muss.

Vor dem Hintergrund von mitunter mehrwöchigen Stabilierungsphasen können gerade diese Projekte von Verbesserungen besonders stark profitieren. Dazu ist es notwendig, etablierte Arbeitsweisen immer wieder zu hinterfragen und die notwendigen Investments in das Build- und Release-Vorgehen zu tätigen – auch wenn im Projekt gerade stürmische Zeiten anstehen.