Eine Buildchain muß jeden Tag laufen

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.

Bei Änderung ein Build

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.

Trügerische Sicherheit

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.

Jeden Tag ein Build

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.

Oliver B. Fischer, 23. März 2016

Norman Doors oder Human Centered Design

Heute bin ich via @TandyQ auf dieses kleine Video gestoßen, das wunderbar erklärt, was eine Norman Door ist und was sie mit Human Centered Design zu tun hat.

Oliver B. Fischer, 27. Februar 2016

heise Developer Podcast zum Thema Softwareanalyse mit Graphendatenbanken

Seit einiger Zeit wirke ich am Software-Analysetool jQAssistant mit und beschäftige mich daher mit dem Einsatz von Graphendatenbanken für die Analyse eines Softwareprojekts. Ende letzten Jahres hatten mein Partner Dirk Mahler und ich die Möglichkeit im Rahmen des SoftwareArchitekTOUR-Podcasts zusammen mit Michael Stal vom SoftwareArchitekTOUR-Podcast über die Möglichkeiten und Vorteile der Software-Analyse mit Graphdatenbanken zu reden.

Der Podcast ist seit der letzten Woche als Episode 51: Softwareanalyse mit Graphendatenbanken online. Er kann direkt auf der Homepage gehört oder über diesen Link als MP3 heruntergeladen werden.

Oliver B. Fischer, 3. Februar 2016

Tags in einem Git-Repository samt Zeitpunkt ausgeben

Gestern fragte ein Kollege, wann wir das letzte Release einer bestimmten Komponente erzeugt haben. Da wir jedes Release auch in dem zugehörigen Git-Repository taggen, habe ich nach einer Möglichkeit gesucht, mir zu den Tags auch den Zeitpunkt ausgeben zu lassen, an dem das Tag gesetzt wurde. Dank stackoverflow war schnell eine gute Lösung gefunden worden, die ich nur noch um eine Option und etwas Formatierung erweitert habe. git log --no-walk --tags --simplify-by-decoration --pretty="format:%<(25)%d%<(20)%cr(%ai)" gibt jetzt den Tagnamen, das relative Datum und das Datum des Taggens selber in einem festen Spaltenlayout aus.

Alle Tags für jQAssistant ausgeben
$ git log --no-walk --tags --simplify-by-decoration --pretty="format:%<(25)%d%<(35)%cr(%ai)"
 (tag: 1.1.2)            vor 10 Tagen                       (2016-01-24 19:44:55 +0100)
 (tag: 1.1.1)            vor 7 Wochen                       (2015-12-15 08:24:44 +0100)
 (tag: 1.1.0)            vor 2 Monaten                      (2015-11-25 19:26:10 +0100)
 (tag: 1.1.0-RC2)        vor 3 Monaten                      (2015-11-06 18:37:00 +0100)
 (tag: 1.1.0-RC1)        vor 4 Monaten                      (2015-10-10 23:32:19 +0200)
 (tag: 1.0.0)            vor 10 Monaten                     (2015-04-17 14:29:57 +0200)
 (tag: 1.0.0-RC1)        vor 11 Monaten                     (2015-02-28 13:35:14 +0100)
 (tag: 1.0.0-M4)         vor 1 Jahr, und 3 Monaten          (2014-10-27 22:43:59 +0100)
 (tag: 1.0.0-M3)         vor 1 Jahr, und 7 Monaten          (2014-06-24 00:34:20 +0200)
 (tag: 1.0.0-M2)         vor 2 Jahren                       (2014-01-24 08:08:25 +0100)
 (tag: 1.0.0-M1)         vor 2 Jahren, und 5 Monaten        (2013-08-28 22:37:42 +0200)

Oliver B. Fischer, 3. Februar 2016


Frühere Artikel sind im Blogarchiv verfügbar.