Why no Buildserver?

Wenn man in einschlägigen Kreisen unterwegs ist, dann wird über das Thema Buildserver kaum noch gesprochen. Vielleicht kommen seltene Randthemen zur Sprache, das war es dann aber im Grunde schon wieder. Die meisten haben das für sich schon gelöst. Ist ja auch wirklich schon ein alter Hut.

Bei Unterhaltungen mit weniger Community-affinen Entwicklern, oder wenn die Arbeit im Unternehmen Überhand nimmt, sieht das dann mitunter anders aus. Unglaublich viele haben keinen Buildserver im Einsatz, ja sind sich teilweise nicht sicher, wofür diese gut sind oder welchen Nutzen sie daraus ziehen sollten.

In manchen Fällen muss auch der Aufwand der Konfiguration und Pflege für das Fehlen einer entsprechenden Infrastruktur herhalten. Mitunter werden Buildserver schon auch mal als neumodisches Zeug abgehandelt.

Vorteile eines Buildservers

Die Anzahl an Vorteilen eines Buildservers sind nicht enden wollend. Nachfolgend möchte ich die für mich wichtigsten Vorteile aufzählen und näher beschreiben.

• Gegenprüfung der Funktionstüchtigkeit auf einem anderen Rechner
  “It compiles on my machine” kennen wir doch alle. Auf einem anderen Computer geht dann plötzlich gar nichts mehr, weil eine Abhängigkeit nicht installiert ist oder nicht alle Dateien im Source Control hinterlegt bzw. aktuell sind.

• Zeitgesteuertes Erstellen von Builds
  In regelmäßigen Abständen wird ein Build vom aktuellen Stand (oder auch mehreren) erstellt und dabei überprüft, ob er kompilierbar ist.

• Anwenden von definierten Regeln auf jede Änderung
  Überprüfungen durch die Ausführung von Unit-/Integrationstests und weiteren Prüfungen, die die Funktionstüchtigkeit garantieren sollen.
• Erzeugen von Releases
  Alle Releases werden nach einer bestimmten Vorgabe immer gleich erstellt. Durch spezielle Prüfungen (Durchlaufen von Unit Tests etc.) können Grundvoraussetzungen für ein erfolgreiches Release überprüft werden. Es kann nicht passieren, dass essentielle Schritte vergessen werden.
• Automatisches Bespielen von unterschiedlichsten Testsystemen
  Nächtliches Bespielen von Testsystemen, damit diese aktuell gehalten werden, Migrationsszenarien durchgespielt werden können usw.
• Einheitliche Ausführung
  Builds werden immer auf dieselbe Art und Weise ausgeführt, d.h. Eigenheiten bzw. besondere Konfigurationen von Entwickler-Rechnern fallen in der Regel schnell auf.

Sicherlich lassen sich weitere Vorteile finden, ich denke jedoch, dass die genannten durchaus ausreichend sind.

Aufwand und Pflege

Es bedeutet Aufwand, einen Buildserver zu betreiben. Eine Installation ist nicht ausreichend. Zuerst bedarf es eines Plans. Hierzu sollten (mindestens) folgende Fragen gestellt (und beantwortet) werden:

• Welche Builds werden benötigt? (Debug-Build, Release-Build, etc.)
• Wann sollen die Builds ausgeführt werden? (Checkin, Hourly, Nightly, etc.)
• Welche Builds müssen was tun? (Compile, Ausführen der Tests, Cleanup, Setup erstellen, etc.)
• Wie wird mit den Buildartefakten umgegangen? (Retention Policy)

Wenn das alles geklärt ist, muss ein Buildserver inklusive aller notwendigen Software her. Danach kann man an die Erstellung der Builds und der notwendigen Scripts gehen. Das kostet natürlich Zeit und muss auch aktuell gehalten werden.

Dafür ist es ein schönes Gefühl, wenn das alles läuft, man seine erste Änderung ins Source Control überträgt und ein Checkin-Build startet, am Server kompiliert, alle Tests durchläuft und einem zurückmeldet, dass alles in Ordnung ist.

Es gibt viele Buildserver da draußen in der weiten Welt, ich für meinen Teil setze seit Jahren auf Jenkins und bin mit ihm immer gut gefahren. Einmal installiert, können Updates (Jenkins selbst als auch Plugins) sehr schnell eingespielt werden.

Einheitliche Release-Policy

Gerade in kleineren Teams und Unternehmen kommt es gerne einmal vor, dass Releases am Entwicklerrechner gemacht und ausgeliefert werden. Das mag besonders agil oder flexibel erscheinen, ist aber oft die Grundlage für zahlreiche Probleme:

• Änderungen finden den Weg ins Source Control nicht, wurden aber in ein Release gepackt und ausgeliefert. Diese Änderungen gehen bei einem etwaigen Update unweigerlich verloren. Daraus resultierende Probleme können nicht nachvollzogen werden.
• Das Setzen der Versionsnummern erfolgt durch einen Release Build. Dadurch wird dies immer einheitlich durchgeführt und es kann auch nicht passieren, dass zwei Auslieferungen dieselbe Versionsnummer tragen.

Ein Buildserver alleine löst dieses Thema nicht, es muss auch organisatorisch entsprechende Regeln geben. Problemfälle können hierdurch jedoch stark minimiert werden.

Ausgelieferte Versionen rekonstruieren

Wenn die Software in vielen unterschiedlichen Versionen bei vielen Kunden im Einsatz ist, dann muss man jederzeit den dortigen Softwarestand rekonstruieren können. Durch einen Buildserver und dezidierten Release-Builds können versionierte/ausgelieferte Stände mit einem Label/Tag automatisch versehen werden. Damit sind alle Stände/Versionen sehr einfach rekonstruierbar.

Eine gute Idee ist auch das Schreiben und Verpacken einer RevisionInfo-Datei in ein Setup. Dadurch können bei Bedarf entsprechende Informationen vom Kunden eingeholt und so der ausgelieferte Stand einfach wiederhergestellt werden (so beispielsweise das Taggen schief ging). Diese Datei kann eine einfache Datei sein und beispielsweise folgende Informationen enthalten:

• Commit-Hash/-Id
• Build-Name
• Build-Datum

Mit diesen Informationen kann der jeweilige Stand problemlos gefunden werden.

Fazit

Gerade im Enterprise-Umfeld gestalten sich Anwendungen immer komplexer. Mitunter sind viele Schritte notwendig, um ein Release zu erstellen, oder ein Testsystem zu bespielen. Oftmals fehlt überhaupt ein automatisierter Testdurchlauf. All das ist mit einem Buildsystem gut zu automatisieren und hilft Zeit zu sparen und gewährleistet, dass immer dieselben Schritte angewandt werden. Wer in diese Richtung noch nichts investiert hat, sollte spätestens jetzt damit starten.

Solltest du Jenkins einsetzen, findest du hier den einen oder anderen Jenkins-Tipp.