Um es vorweg direkt zu erwähnen, es ist sicherlich nicht der erste Artikel rund um das Thema Tools und Standards in Softwareprojekten bzw. in der Softwareentwicklung, aber dies muss auch aus gegebenem Anlass niedergeschrieben werden.

Warum braucht man Standards und Unterstützende Werkzeuge in der Softwareentwicklung?

Die Frage ist einfach! Warum nicht?

Konstruktiver: Die Idee dahinter ist eigentlich die, dass der Entwicklungsprozess früher ein rein manueller war. Man hat die Projekte händisch angelegt und gepflegt, Quellcode manuell geprüft (mal gut, mal schlecht), hat viele Dinge in Kleinstarbeit selbst erledigt und noch viel schlimmer, jeder im Team hat es irgendwie anders gemacht.

Früher war dies jedoch kein Problem, als die Anwendungen noch auf eine Diskette passten, dies ist jedoch längst obsolet. Verteilte Anwendungen mit Client-Server Architektur können Heute schon mehrere Gigabyte füllen. Größen von mehr als 500.000 Lines of Code (Zeilen Code) mit komplexen Abhängigkeiten und verteilte Teams in Größen jenseits von 10 Leuten, da ist jeder Minute Geld Wert!

Google ist auch hier ein Pionier, wie Ashish Kumar in seinem Vortrag “Development at the Speed and Scale of Google” auf InfoQ.com beeindruckend präsentiert.

Gerade Google produziert täglich mehrere tausende Zeilen Code, da es deren Kerngeschäft ist. Da zählt jede Minute. Google verfolgt nicht umsonst die Philosophie, dass der Entwickler so wenig Zeit wie möglich auf Tools oder Vorgänge warten muss, da dies verlorene Zeit ist. Dafür investiert Google viel Zeit und Geld, damit dies klappt. Dies schafft Google mit einem raffinierten Zusammenspiel diverser Komponenten (Continuous Integration, Analyse & Reporting, Skalierbarkeit etc.).

Ziel ist es, nach dem Check-In des eigenen Codes binnen weniger Minuten ein Ergebnis zu haben, sprich gebauten Code, der Analysiert wurde und direkten Feedback gibt (Unit-Tests). Dafür gibt es ein Team, das ständig am Prozess und der Hardware und Software arbeitet, damit die Entwickler effektiv arbeiten können. Nichts ist so lästig wie das Warten auf den CI-Server (Continuous Integration Server), der mal wieder eine halbe Stunde für den Bau des gesamten Codestrangs benötigt.

Neben der Standardisierung und Geschwindigkeit, ist auch die Wartbarkeit des Quellcodes ein wichtiger Aspekt. Ein CI-Server ist nichts Wert ohne eine Versionskontrolle wie Subversion oder GiT, in der die Anwendung vom ganzen Team bearbeitet und gepflegt wird.

Ein Ansatz, der Ausbaufähig ist

Für Unternehmen bereits ab kleiner Größe ist bereits die Anschaffung von Hardware für einen CI-Server (Continuous Integration Server) sinnvoll. Mit Build Tools wie Maven oder Ant und einem CI-Server lassen sich Projekte bereits von der Struktur und “From Scratch” standardisieren, in dem man eine einheitliche Konfiguration und Paketierung schnürrt. Mit einer entsprechenden Versionskontrolle (SVN, GiT etc.) lässt sich die Software in einem gemeinsamen “Repository” zusammenlegen, die Teammitglieder arbeiten dann mit der Versionskontrolle. Die Softwareänderungen lassen sich dann nachvollziehen, zurücknehmen oder für Parallelentwicklung auch einzelne Stränge abspalten bzw. auch zusammenführen. Der CI-Server ist dann mit der Versionskontrolle “integriert” und baut darauf auf, in dem er bspw. in so genannten “Nightly Builds” (täglicher CI-Job, der Abends den Quellcode aus der Versionskontrolle “auscheckt und kompiliert). So lässt sich relativ früh erkennen, ob die vorher programmierte Software oder deren Teilbereiche mit dem Rest der Software zusammenarbeitet (Early Integration).

Für einen CI-Server muss man nicht mal viel investieren, die Hardware ist schnell aufgebaut und die meiste CI-Software ist als OpenSource Projekt verfügbar. Hier ein kleiner Auszug:

• Jenkins (früher Hudson)
• CruiseControl
• Anthill
• Continuum

CI-Server Jenkins

Eine sehr starke Community und viel Bewegung ist nach wie vor bei Jenkins zu sehen, das eine sehr lebendige Community hat. Dementsprechend ist auch die Plugin Dichte sehr hoch. In der Vergangenheit sind mir vor allem Hudson bzw. Jenkins CI-Server untergekommen, die sehr flexibel zu konfigurieren sind. Hier lassen sich auch viel mit Pre- bzw. Post-Processing arbeiten, bspw. das ausführen bestimmter Dienste oder Shell-Skripte vor bzw. nach dem kompilieren des Quellcodes.

Für kleine Unternehmen empfehle ich die Diplomarbeit von Martin Rödig: Erhöhung der Softwarequalität in kleinenUnternehmen durch einen Continuous Integration-Prozess.

Dieser hat in der Diplomarbeit CI-Software evaluiert und diese im konkreten Einsatz in einem kleineren Unternehmen beschrieben und geht hier auch auf die Ergänzung um weitere Plugins ein.

Weitere Schritte – Der Ausbau des CI-Servers

Nach der Wahl der Versionskontrolle (bspw. SVN oder GiT) und des CI-Servers (Jenkins, Bamboo etc.) ist ein Frühwarnsystem nötig. Damit der Entwickler nicht jedes mal langwierig seinen Quellcode manuell prüfen muss, sollte dieser Prozess auch automatisiert durch den CI-Server übernommen werden. Arbeitet man intern mit Unit-Tests (Bspw. JUnit Klassen), so kann man auch dies automatisiert in einem CI-Job abbilden.

Für die gängigsten CI-Server wie Jenkins, Bamboo oder CruiseControl gibt es Plugins die das für einen erledigen. Die Integration ist relativ einfach.

Für den Anfang reichen da schon Plugins für

• FindBugs Analyse
• PMD Analyse
• JUnit Durchführung
• eventuell auch Dependency Analyzer

Gerade FindBugs und PMD sind schon unschlagbar für die Qualität des Codes und noch besser, für die Sensibilisierung der Entwickler für das Thema.  Man sollte die Plugins als Jobs konfigurieren und diese in das Post-Processing des CI-Buildjobs einbinden, so dass diese dann automatisch den Quellcode analysieren (bei jedem kompilieren).

In ausführlichen Statistiken weisen diese dann auf Fehler oder Probleme hin und geben direkt Auskunft über das Paket, Methode und Codestelle.

FindBugs Statistik

Findbugs mit Angabe der Codezeile und des Problems

Das JUnit-Plugin führt alle Testmethoden automatisch aus und weist diese in einem Report separat aus. Die Entwickler bekommen direkt mit, ob alle Unit-Tests durchgelaufen sind oder ob es irgendwo noch Probleme gibt. Die Codequalität erhöht sich dadurch fast im Alleingang. Gut, Fehler beheben muss man dann doch alleine ;).

Überhaupt ist es zu empfehlen, sich genauer mit den Standards, die in statischen Metriken in FindBugs und PMD hinterlegt sind, auseinanderzusetzen. Die Metriken basieren auf “Best Practice” Ansätzen aus langjähriger Entwicklungserfahrung und sollte in einem Unternehmensweitem Standard für die Entwicklung genutzt werden, dabei empfehle ich mit dem Gesamten Team ein Ganzheitliches Bild zu schaffen, da die Philosophien bei der Entwicklung von Software doch recht unterschiedlich sind und auch FindBugs und PMD nur ein Rahmenwerk darstellen.

Wie geht es weiter?

Nun, Grundsätzlich hat man schon viel gewonnen, wenn man in seinem Unternehmen einen einheitlichen Rahmen für Softwareprojekte schafft, in dem man standardisiert die Projekte mittels Versionskontrolle, Continuous Integration sowie unterstützenden Plugins unterstützt. Die Automatisierung und Frühwarnsystem durch Plugins spart viel Zeit und Nerven und somit auch bares Geld.

Automatisierter Entwicklungsprozess mittels Repository, Jenkins und Plugins

In einem weiteren Artikel werde ich auch noch auf weiterreichende Ideen eingehen, die sich nicht nur auf die Entwicklungsumgebung bezieht.

Quellen:

• Ashish Kumar: Development at the Speed and Scale of Google
• Kontinuierliche Integration auf Wiki
• Diplomarbeit: Erhöhung der Softwarequalität in kleinenUnternehmen durch einen Continuous Integration-Prozess