Kennen Sie Go?
Go ist ein 3000 bis 4000 jähriges chinesisches Brettspiel, welches in den möglichen Spielausgängen um ein milliardenfaches komplexer als Schach ist. Aus diesem einfachen Grund wurde bis vor kurzem angenommen, dass es nie eine Software geben wird, welche es mit einem menschlichen Opponenten aufnehmen könnte. Diese Einschätzung wurde im Jahre 2016 korrigiert, als AlphaGo nicht nur irgendeinen menschlichen Go-Spieler, sondern den bis dahin unangefochtenen Go-Champion Lee Sedol in vier von fünf Spielen schlug.
Dies war ohne Zweifel eine grossartige Ingenieursleistung, die ihresgleichen sucht. Doch trotz dieser Leistung hat AlphaGo nicht etwa perfekt gespielt und hatte sogar ein paar kleine Macken. Was einigen Software Entwicklern wohl im Kopf blieb, ist die Aussage von Kommentator Andrew Jackson «Wenn DeepMind (Firma hinter AlphaGo) einen Weg gefunden hat, eine absolut fehlerfreie Software zu schreiben, ist dies die grössere News Story als der Erfolg von AlphaGo». Dem ist nichts weiter hinzuzufügen.
Computer-Programme sind hochkomplexe Gebilde, bestehend aus abertausenden, wenn nicht Millionen Zeilen Code. Ein solches Gebilde komplett fehlerfrei zu gestalten, scheint schier unmöglich. Doch wenn dies so ist, wie misst sich dann Qualität? Was unterscheidet eine qualitativ hochstehende Software von einer eher schlechteren Software? Zwei Aspekte stechen sicherlich heraus: Einerseits die sog. Mean Time To Repair (MTTR), also die durchschnittliche Zeit, welche zwischen einem Fehlerfund und dem Zeitpunkt, an dem der Kunde eine korrigierte Version einsetzt, vergeht. Der andere Aspekt ist die Fehlerwiederholrate: Wir alle machen mal einen Fehler, aber wir sollten unsere Fehler nicht wiederholen.
Continuous Integration und Continuous Delivery
Eine neue Version einer Software auszuliefern, ist keine triviale Aufgabe. Oftmals sind bis zu 100 Arbeitsschritte notwendig, um eine neue Software-Version bereitzustellen, ganz zu schweigen von der Quality-Control, welche die Software vor dem Rollout auch noch testen sollte.
Dieser Umstand erklärt, wieso viele Software-Anbieter auch im Jahre 2020 nur quartalsweise ein Update ausrollen. Wie schafft es das TimeRocket-Team also mehrere neue Features pro Woche und oftmals mehrere kleine Updates pro Tag zu releasen und dies ohne Wartungsfenster, also ohne Unterbruch für die Benutzer?
Wir haben uns zuerst einmal darauf konzentriert, all die kleinen Arbeitsschritte, die zum Ausrollen einer neuen Version notwendig sind, zu automatisieren. Das Ergebnis ist eine sog. Release-Pipeline, welche zuerst neue Server-Instanzen automatisch herauffährt, die neue Software einspielt und danach Service für Service eine Umleitung auf die neue Version macht und die alten Server Instanzen herunterfährt. Da es sich bei TimeRocket um eine Zeiterfassung in der Cloud handelt, es also eine Cloud-Applikation ist, merken die Benutzer in der Regel nicht einmal, dass sie gerade während der Benutzung einen Versionswechsel mitgemacht haben. Die Benutzer sehen einfach plötzlich eine Option oder einen Menüpunkt mehr als zuvor.
Testing
Aber was ist mit der zuvor angesprochenen Qualitätskontrolle? Einfach einen Knopf zu drücken und eine neue Version auf den Endbenutzer loszulassen ist doch etwas gar fahrlässig, nicht? Genau! Aus diesem Grund wird vor der Release-Pipeline auch noch eine automatisierte Build-and-Test-Pipeline durchlaufen. Hier wird nicht nur aus den hunderttausenden Zeilen Code eine ausführbare Software gebaut, sondern auch tausende Tests automatisch ausgeführt (Stand Januar 2020: über 19’000 Tests). Darin werden alle erdenklichen Testfälle durchlaufen, sowie auch geschaut, dass durch Veränderungen im Quellcode nicht plötzlich Fehlkalkulationen auftreten. Wenn nur ein einziger dieser Tests fehlschlägt, wird ein Einspielen der neuen Version verunmöglicht.
Sollte einmal ein Fehlverhalten im produktiven Betrieb festgestellt werden, so bildet unser Entwicklungsteam dieses Fehlverhalten als weiteren Testfall nach. Dadurch wird verifiziert, dass das Problem existiert und dass das Entwickler-Team den Problemfall korrekt vertanden hat. Danach wird der Programmcode so verändert, dass das Fehlverhalten nicht mehr auftritt, aber auch keine der anderen 19’000 Testfälle fehlschlägt.
Nachdem der Fehler korrigiert wurde, wird der Fix in die zentrale Sourcecode-Verwaltung von TimeRocket geladen, was einen automatischen Durchlauf der zuvor vorgestellten Build-and-Test-Pipeline zur Folge hat. (Continuous Integration). Wenn in der Pipeline verifiziert wurde, dass alle Testfälle fehlerfrei durchlaufen wurden, wird die Release-Pipeline angestossen, welche ein manuelles OK (der zuvor angesprochene Knopfdruck) benötigt, um die neue Version automatisch in das Produktivsystem einzuspielen.
Der Durchlauf beider Pipelines zusammen, dauert um die 40 Minuten und benötigt bis auf den einen Knopfdruck keine menschlichen Resourcen.
Dies alles erlaubt es, auch einem vergleichsweise sehr kleinen Team aus Luzerner Software Entwicklern Woche für Woche Mehrwert für die Endbenutzer von TimeRocket zu schaffen. Darauf sind wir stolz! Für uns ist Software Qualität kein Schlagwort, sondern Daily Business.