Softwareentwicklung im Team – Teil 2 – Unabhängiger Buildprozess

Kommen wir nach der Einleitung zum Ersten von mir angesprochenen Problem:

1. Problem / Beispiel
Unabhängiger Buildprozess
Zur Zeit verlassen wir uns darauf, dass Netbeans für uns die Projekte buildet. Häufig ist es mit einer einmaligen Konfiguration getan, allerdings ist es in der Vergangenheit mehr als einmal aufgetreten, dass sich bei einer signifikanten Änderung (z.B. Umstellung auf den JAXB-Wizard (und zurück)) Probleme auftraten und einige Entwickler etwas mehr Zeit benötigten, das Projekt wieder zum Laufen zu bekommen.
Konsequenz daraus: neben der verlorenen Arbeitszeit, wird ein Checkout aus dem SVN zur unfreiwilligen Gebetspause, die gerne mal um einen Tag verschoben wird.
Einhergehend mit diesem Problem, müsste sich auch mit einem automatischen Dependency Management beschäftig werden (siehe das nächste Problem).

Lösungsvorschlag
Ein von der IDE unabhängiger Buildprozess. Anbieten würden sich Ant (http://ant.apache.org/) oder Maven (http://maven.apache.org/). Netbeans selber verwendet intern ja Ant, allerdings gibt es auch ein sehr brauchbares Maven-Plugin.

Vorteile
– Keine Aversionen mehr, sich den neuesten Stand aus dem SVN zu holen
– Weniger Frustration, weil “mal wieder” nach einem Checkout nichts funktioniert
– Möglichkeit den Build auf einen Continious Integration Server ausführen zu lassen

Nachteile / Probleme
– Umstellung benötigt kurzfristig ein wenig Zeit / Einarbeitung
– Jeder Entwickler muss sich in das verwendete Tool einarbeiten und es auch nutzen!

Aufwand
– siehe Aufwand beim Dependency-Management

Rückblickend gesehen…

Jeder von uns hatte damals die gleiche IDE zu verwenden (in unserem Falle Netbeans). Ein builden des Projektes außerhalb der IDE war damals fast ein Ding der Unmöglichkeit. Sprich: wurde eine Änderung an der Konfiguration nötig, musste jeder Entwickler, diese lokal bei sich innerhalb der IDE vornehmen. Eine andere IDE zu verwenden, den Arbeitsplatzrechner wechseln oder gar das Projekt von einem CI-Server builden zu lassen, bestanden de facto nicht. Und wäre ein neuer Mitarbeiter hinzugestoßen, so wäre er sicherlich erst einmal mit einer Woche Frust beschäftigt gewesen.

Kurz gesagt: wir haben uns damals für Maven entschieden. Zwar war ich der einzige Entwickler, der ein wenig Erfahrung mit Maven hatte (und das auch nur erst seit einer Woche oder so), aber zum damaligen Zeitpunkt schien Maven uns mehr Probleme abzunehmen als Ant. Was sich im Nachhinein auch bewahrheitet hat. Mittlerweile muss der Maven-Support in Netbeans auch nicht mehr nachträglich als Plugin installiert werden, sondern kommt out-of-the-box daher.

Ich weiß ehrlich gesagt nicht mehr genau, was es mit dem erwähnten JAXB-Wizard auf sich hatte, nur soviel, dass wir Versionskonflikte hatten, da JAXB seit dem JDK 6 mitgeliefert wird und in JDK 6 Update 4 aktualisiert wurde. Allerdings gab es bei einer der Versionen bei uns Probleme und außerdem hatten nicht alle Entwickler die gleiche JDK Version installiert. Auf jeden Fall war es ein Problem, was uns mehr als einen Tag beschäftigte.

Heute würde ich bei den Vorteilen noch auflisten, dass man die freie Wahl der IDE hat. Denn Geschmäcker unterteilen sich ja eben doch in gut und schlecht ;-)

Zusammenfassung

Ich habe ehrlich gesagt keine Ahnung, ob es tatsächlich noch Teams geben sollte, die auf eine bestimmte IDE angewiesen sind. Aber selbst als “Einzelgänger” sollte man sich um einen unabhängigen Buildprozess bemühen. Entsprechende Build-Tools gibt es zu Genüge (siehe z.B: http://java-sources.org/open-source/build-systems), wobei Maven wohl immer noch die Nummer eins hier sein dürfte. Mittlerweile erwarte(!) ich von Projekten sogar, dass sich diese mit einem simplen Befehl von der Konsole (z.B. “mvn install”) aus builden lassen.

Also: wer noch keinen von der IDE unabhängigen Buildprozess hat, sollte alles stehen und liegen lassen und diesen SOFORT einführen!

Ausblick
Coming up next: “Dependency-Management

3 Gedanken zu „Softwareentwicklung im Team – Teil 2 – Unabhängiger Buildprozess“

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>