Oliver B. Fischer, 23. March 2016
Ein Projekt nur nach einer Änderungen am Projekt selber zu bauen führt zu einer trügerischen Sicherheit, denn jedes Software-Projekt sollte einmal täglich einen vollständigen Build durchlaufen. Dennn ob ein Projekt baut, hängt von mehr als dem Projekt selber ab.
Seine Software-Projekte über eine selbst gehostete Continuous Integration-Lösung wie TeamCity oder Jenkins eine SaaS-Lösung à la Travis zu bauen, gehört heute zum guten Ton, sprich sollte Standard sein. Bei jeder Änderung im Projekt wird so geprüft, ob der Code kompiliert und alle Tests erfolgreich ausgeführt werden können. So stellen wir sicher, daß unsere Software sich in einen einwandfreien Zustand befindet. So weit so gut.
Leider führt dies zu einer trügerischen Sicherheit, denn ob ein Projekt baut oder nicht, hängt nicht nur vom Projekt selber ab, sondern auch von seinen externen Abhängigkeiten und dem System auf dem es gebaut wird. Diese Abhängigkeiten können wir nie vollständig kontrollieren. Zwar bieten die heute sich im Einsatz befindenden Build-Systeme die Möglichkeit Abhängkeiten zu Projekt-externen Librarys in Hinsicht auf Version und Quelle genau festzulegen, jedoch garantiert das nicht, daß diese Abhängikeit in dieser Version für immer an genau dieser Stelle zu finden sein wird.
Beispielsweise wurden vor einiger Zeit alle Dienste von Codehaus, inklusive dessen Maven Repositorys, abgeschaltet. Und GitHub-Accounts bestehen manchmal auch nicht für immer.
Häufiger als das jedoch sind Veränderungen auf dem Host, auf dem der Continuous Integration-Server läuft beziehungsweise auf dem der eigentliche Build erfolgt. Abgelaufene Zertifikate, aktualisierte Versionen von genutzten Tools wie Maven oder eine andere Ruby-Version und schon ist der Build kaputt, ohne das sich am Projekt selber etwas geändert hat.
In einem aktiv entwickelten Projekt fallen solche Probleme sofort auf, da es häufig Commits gibt, die einen neuen Build auslösen. Doch sobald die Aktivität abnimmt oder lange Zeit gar nicht mehr an dem Projekt gearbeitet wird, befinden wir uns in einer trügerischen Sicherheit. Jedes Projekt kann potentiell kaputt sein und wir damit nicht in der Lage Fehler zu beheben oder neue Features schnell einzubauen. Wer ein paar wirklich alte und inaktive Projekte hat, kann dies gerne selber überprüfen.
Aus diesem Grunde sind wir in meinem Team dazu übergegangen unsere Projekte jede Nacht zwischen drei und sechs Uhr morgens vollständig zu bauen. Sofern es Probleme dabei gibt, was ab und zu doch schon vorkommt, finden wir diese schnell und können Fehler beheben oder Anpassungen vornehmen. Für uns im Team ist eine wichtige Voraussetzung, um jeder Zeit lieferfähig zu sein.
Daher sollte jedes Projekt einmal pro Tag vollständig gebaut werden, unabhängig davon, ob es Änderungen daran gab oder nicht. Nur so kann sichergestellt werden, jeder Zeit daran weiter arbeiten zu können.
Für uns war dies nur der erste Schritt. Inzwischen sind wir dazu übergegangen unsere Buildchains zu generieren, doch dies ist ein anderes Thema.