Continuos Delivery / Continuos Integration – ポカヨケ (Pokayoke) in der Softwareentwicklung

Erwartete Lesezeit: 4 minuten

Unter dem Begriff Pokayoke versteht man die Einrichtung verschiedener technischer Vorkehrungen zur Fehlererkennung bzw. Fehlervermeidung.
Ein sehr gutes Beispiel auf einem anderen Bereich als die Softwareentwicklung ist der bekannte TAE Telefonstecker. Wer schon mal versucht hat , den Stecker falsch herum hereinzustecken hat schnell gemerkt, dass es nicht geht. Und genau dieses Prinzip ist für die kontinuierliche Softwareentwicklung unumgänglich.
Bei CD möchten wir ja neue Features und Änderungen möglichst schnell in die produktive Umgebung bringen. Aber jedes Deployment – jede Integration ist eine mögliche Fehlerquelle.

Was aber tun ?

Ganz einfach, wir müssen testen , richtig gut testen und möglicht zu einem frühen Stadium der Entwicklung für einen stabilen abgehärteten Deploymentprozess sorgen.
Das ist leichter gesagt, als getan. Vielen Stakeholdern muss man erstmal erklären , warum man in der Startphase höhere Aufwandszahlen hat, ohne dass der Kunde direkt ein Ergebnis sieht. Für die meisten Stakeholder und Kunden zählt leider nur das schnelle kostengünstige Ergebnis.

Das sollte uns aber nicht von der Einrichtung verschiedenster Qualitygates abhalten , da jeder Fehler, der zum frühst möglichen Zeitpunkt entdeckt wird, kostengünstiger ist als nachher in Produktion.

Level 1: Statische Code-Analyse und automatisierte Codereviews

Die statische Codeanalyse wird innerhalb der Pipeline automatisch bei der Compilierung ausgeführt und stellt sicher, dass der Code an sich ausführbar ist.
Im Anschluss sollte man die automatisierten  Codereviews durchführen. Hierbei können verschiedene Tools wie z.B, Sonarcube oder PMD unterstützen. Der Sourcecode wird geben die administrierten Regeln geprüft. Im Falle von schweren Verstößen (Bugs) muss die Pipeline gestoppt werden. Bei leichteren Verstößen (Codesmells) kann die Pipeline gestoppt werden, muss aber nicht. Die Grenze sollte vor Beginn festgelegt werden. Gerade bei Code-Generatoren , können Codesmells entstehen.

Zu Guter letzt prüfe ich in meinen  privaten Projekten an dieser stelle immer alle im Projekt genutzten Abhängigkeiten (Dependencies) mittels dem OWASP Dependency Check Plugin um bekannte Sicherheitsprobleme aufzudecken.

Level 2: Unit Tests

Die Unit Test bzw. Entwicklertests werden neben der lokalen Ausführung auf den Entwicklungsrechnern innerhalb der Build und Deploymentpipeline  ausgeführt.
Das Quality Gate ist erfüllt , wenn alle Tests erfolgreich durchgelaufen sind und die durch das Projektteam bzw. die Organisation festgelegten Abdeckungsgrad erreicht sind.
Wenn diese Kriterien nicht erfüllt sind, stoppt die Pipeline.

Level 3: Fachliche Test / Akzeptanz Tests / Regressionstest

Innerhalb dieser Phase werden mit dem Kunden abgestimmte fachliche Tests ausgeführt ausgeführt. Vorteil der Automatisierung ist , dass diese Test bei jedem Inkrement erneut ausgeführt werden. Somit kann sichergestellt werden, dass eine Änderung bzw. Erweiterung erneut ausgeführt werden.
Hierbei eignet sich das Behavior Driven Development, bei dem der Kunde selber bei der Erstellung der Testfälle mitarbeiten kann. Treten Fehler bei der Ausführung aus , stoppt die Pipeline und es muss geklärt werden, liegt ein Problem in der Software vor oder im Testfall. Erst wenn alle Testfälle erfolgreich ausgeführt worden sind, darf die Pipeline weiterlaufen.

Level 3b: Explorative Tests

Als zusätzliche Testebene sollte kann man den Kunden nochmals explorativ Testen lassen. Hierbei geht es nicht um die Durchführung von hunderten Testreihen. Es geht vielmehr um ein „Spielen“ mit der Anwendung und das an die Grenze bringen. Hat man die Testreihen vorher definiert, führt man diese strikt aus und kommt nicht auf , ich nenne es mal, skurrile Ideen. Genau hierbei werden oft noch nicht bedachte Situation entdeckt, die dann in die Akzeptanz Tests aufnehmen.

Level 4: Last- und Performance Tests

Jede Softwareänderung kann ungewollt zu einer Verschlechterung der Durchsatz- und Verarbeitungszeiten führen. Daher sollte man bereits beim ersten Inkrement die Performance aufzeichnen um dann bei jedem Inkrement die Messdaten vergleichen zu können. Man sollte die Pipeline bei einer Verschlechterung von x Prozent abbrechen lassen. Das schwierige ist allerdings den richtigen Schwellwert zu finden. Auch muss bei diesen Test sichergestellt sein , dass die Datenmenge in den Datenbanken / Dateien ungefähr denen in der produktiven Zielumgebung entsprechen. Eine Testdatenbank mit 100 Datensätze ist in der Verarbeitung schneller als eine produktive Datenbank mit 10 Mio. Datensätze.

Level 5: Smoketest nach der Installation auf den einzelnen Stages

Neben Fehlern in der Softwareentwicklung können auch Fehler bei den automatischen Deployments auftreten. Von falschen Datenbank-Urls, über falsch eingerichtete Benutzer bis hin zu fehlenden Dateien oder fehlenden Dateisystemen / Shares , kann beim Deployment eine Menge fehlschlagen.

Daher sollte man nach jedem Deployment Smoketests, Anlauftests durchführen.
Hier gibt es allerdings einige Probleme. Hat man pro Stage nur eine Seite ist die Aktive Seite bereits gestört, wenn beim Deployment etwas nicht geklappt hat. In diesem Fall sollte man einen automatischen Rollback in betracht ziehen, bevor die Pipeline abbricht. Hier hat man aber ggf. eine Ausfallzeit , welches für die produktive Umgebung nicht optimal ist.

Hier bietet sich ein Blue Green Verfahren an. Eine aktive Seite und eine inaktive Seite. Die neue Version wird auf der Inaktiven Seite bereitgestellt und der Anlauftests durchgeführt. Ist alles Ok wird der Schwenk auf die Inaktive Seite durchgeführt und die Inaktive Seite zur Aktiven.  Nach dem Schwenk findet nochmal ein kurzer Test statt, ob die Anwendung erreichbar ist.
Im Fehlerfall kann man schnell auf die alte Version zurück bzw. den Schwenk nicht durchführen und eventuelle Ausfallzeiten sind minimiert.

Nachbetrachtung:

Zur Nachvollziehbarbeit jedes Deployments sollte man die Ergebnisse der Tests dokumentieren lassen.
Jetzt werden viele sagen , dass schaut sich ja sowieso keiner mehr an. Stimmt nicht so ganz, in manchen Branchen , z.B. in der Finanzwelt, schaut sich der Wirtschaftsprüfer auch solche Dokumente an. So kann man nachweisen dass keine bekannten Fehler in Richtung Produktion gegangen sind da man die Pipeline Pokayoke gebauht hat 😉