Jeder, der in mehr als nur einem Projekt gearbeitet hat, kann berichten, dass Build-Management meistens sehr stiefmütterlich behandelt wird. Jeder Entwickler und auch fast alle Architekten wissen um den Sachverhalt, dass solides Build-Management mit Continuous-Integration und -Delivery entscheidend zum Erfolg eines Projekts beitragen kann, aber leider wird dieses Thema dennoch sehr häufig vernachlässigt.
Ursachen
Warum wird Build-Management eigentlich so gerne „niedrig priorisiert“? Fakt ist, dass es Geld kostet. Die Projektleitung möchte aber nicht gern Geld ausgeben. Je niedriger das kalkulierte und verbrauchte Budget ist, desto besser steht die Projektleitung am Ende da. Ein Bonus winkt und alle guten Manieren werden regelrecht über Bord geworfen. Es ist richtig, dass kurzfristig eine Ersparnis erzielt wird, doch entstehen mittel- und langfristig Mehrkosten.
Natürlich ist das nicht immer so und alle Manager über einen Kamm zu scheren, ist auch nicht fair. Die Ursache direkt auf die Projektleitung zu münzen, ist in vielen Fällen sogar falsch, denn viel zu häufig sind die Entwickler und Build-Manager selbst schuld. So empfindet man das Thema Build-Management gern mal als „nervig“, „langweilig“ – manuell ist es das auch – oder – sehr fatal – „überbewertet“. Aber auch das muss nicht stimmen. Es könnte auch schlichtweg an der mangelnden Expertise im gesamten Team oder Unternehmen liegen. Meiner Meinung nach ist letzteres zu einem hohen Anteil der Fall.
Folgen
Was sind potentielle Folgen von falscher oder mangelnder Build-Management-Handhabung? Unterm Strich sind es Mehrkosten – und das ausnahmslos. Wann immer etwas nicht automatisiert ist, muss – Sie ahnen es – manuell nachgeholfen werden. Das ist Handarbeit und echte Handarbeit – made in Germany, USA, UK oder sonstwo – kostet viel Geld. Da das wiederkehrende Vorgänge sind, die immer einem gleichen oder sehr ähnlichen Ablauf folgen, liegt eine Automatisierung nicht nur nahe, sie ist in dem Intervall, in dem Builds fabriziert werden (bzw. werden sollten), schlichtweg notwendig.
Ein Build-Prozess ist empfindlich. Parameter dürfen nicht abweichen und alle Schritte müssen exakt in derselben Art und Weise ausgeführt werden, in der sie schon einmal ausgeführt wurden. Nur so kann sichergestellt werden, dass ein Build bei Verwendung derselben Quellen exakt reproduziert werden kann. So ist z.B. bei Java (aber auch bei anderen Sprachen) dieselbe Compiler-Version ein Muss, denn sonst ist der generierte Byte-Code ein anderer und Checksummen weichen ab (das gilt auch für Wartungs-Releases).
Murphy‘s Law ist im Haus – oder so ähnlich. Wann immer etwas fehleranfällig ist, werden Fehler auftreten. Und meistens steckt der Teufel im Detail. Ein Build „sieht gut“ aus, bis man in Produktion bemerkt, dass eine Einstellung falsch ist und alle Benutzer Daten auf einer Integrationstestdatenbank gespeichert haben. Tagelange Arbeit ist entweder umsonst oder (was wahrscheinlicher ist) man muss die Daten migrieren. Wieder Aufwand, wieder Kosten.
Gegensteuern
Safety comes first. Nach diesem Prinzip wird in vielen Berufen gearbeitet. Der Stahlarbeiter setzt immer seinen Helm auf, der Feuerwehrmann trägt Schutzkleidung. Und wie schützt sich ein Build-Manager, der in manchen Unternehmen oder Projekten nicht einmal existiert, vor potentiellen Risiken und Fehlern? Indem er alles vollautomatisiert. Damit nicht genug, sollte alles regelmäßig getestet werden. Wie regelmäßig? Mindestens bei jedem Nightly-, besser ist aber bei jedem Build. Hier seien unter anderem Staging, Smoke- und Integrationstests genannt. Modultests werden an dieser Stelle ignoriert, da sie als selbstverständlich gelten und auf jedem Entwicklungs-Client ausgeführt werden sollten, bevor etwas in das Versionierungssystem hochgeladen wird.
Und im Fehlerfall?
Wenn doch einmal etwas schief geht – und es wird etwas schief gehen – sollte man nicht ohne Taschenlampe mit einem Stock in der Dunkelheit rumstochern müssen. Protokolle und temporäre Daten sollten im Fall eines defekten Builds immer konsolidiert werden können. Also gilt es diese zu archivieren.
Etwas konkreter, bitte
Wir werden in den kommenden Wochen Tipps und Tricks sowie Erfahrungen zum Thema Software Lifecycle Management veröffentlichen. Das beginnt mit Grundlagen wie z.B. Versionierung von Artefakten und endet bei Continuous Delivery. Damit möchten wir das Entwicklerleben etwas weniger schmerzhaft gestalten und für Geldersparnis in Projekten sorgen – zum Nulltarif.
