Mar
02
2012

Continuous Integration – Realisierung des CI-Prozesses zur Qualitätssicherung

Nach dem im letzten Artikel „Mit Continuous Integration zur besseren Softwarequalität“ das CI-Verfahren und seine Vorteile zur Steigerung unserer Software-Qualität erläutert wurden, möchte ich in diesem zweiten Teil die technische Realisierung des CI-Prozesses bei der SAPERION AG beschreiben.

Am Anfang stand der CI-Server Hudson

Der Hudson CI-Server  ist ein auf dem Markt frei verfügbarer CI-Server, mit dem wir begonnen haben, den CI-Prozess für den Entwicklungs-Branch zu realisieren. Hudson hat eine Vielzahl von Funktionen und Plugins, mit denen man seine automatisierten Build- und Testprozesse individuell anpassen kann. Unsere ersten Erfahrungen mit Hudson waren sehr positiv.

Goodbye Hudson, Welcome Jenkins

Nach dem der Hudson CI-Server immer weiter ausgebaut wurde und ein CI-Cluster mit einem Master auf Linux und mehreren Slaves (Windows und Linux) entstanden ist, stiegen auch die Anforderung an den Hudson Server. Damit wuchsen leider auch die Probleme mit Hudson, die durch mehrere Bugs geprägt waren, die unseren Build-Prozess betrafen. Neu eingespielte Updates konnten keine Abhilfe schaffen.

Mit Jenkins gibt es ein paralleles Open-Source-Projekt zu Hudson, was durch den gleichen Ursprung sehr ähnlich zu Hudson ist. Die Jenkins Community hat sich durch einen Konflikt von Oracles Hudson vor einiger Zeit abgesplittet. Nach kurzer Validierung unsererseits wurde ein Umstieg auf Jenkins beschlossen. Es war zu beobachten, dass das Jenkins Projekt im Vergleich zum Hudson deutlich aktiver ist und viele Entwickler auf seiner Seite weiß, so dass der Umstieg auch in Zukunft weitere Vorteile erwarten lässt. Nach der Umstellung lief der CI-Prozess deutlich verbessert und die unter Hudson aufgetretenen Probleme gehörten der Vergangenheit an. Einem weiteren Ausbau der CI-Prozesse steht nun nichts mehr im Wege. Seit dem heißt es bei uns Jenkins und nicht mehr Hudson.

Die laufenden CI-Prozesse

Momentan werden alle Source für den Entwicklungs-Branch nach einem Check-In in Subversion automatisch kompiliert und auf sogenannte „Build-Breaker“ überprüft. Außerdem laufen nach jedem Build automatisierte Unit, Integration und sogenannte Smoke Tests. Im Fehlerfall werden die verursachenden Entwickler per E-Mail informiert. Über die Jenkins Webseite oder kleine Gadgets kann sich jeder im Haus über den aktuellen Zustand des Systems informieren.  Im Fehlerfall kann über die Weboberfläche die Konsolen-Ausgabe eingesehen werden und die Fehler analysiert und anschließend behoben werden. Aus den verifizierten Builds wird ein Patch Image erstellt, mit dem die Entwicklung und QA ein ausführbares SAPERION System auf den neusten Entwicklungsstand updaten kann.

Außerdem ist mit Sonar ein Metriksystem im CI-Prozess integriert worden, was weitgehende Auskünfte über Qualitätsmerkmale, wie z.B. Anzahl der Zeilen Codes und ihre prozentuale Kommentierung, gibt. Also Motivation für die Entwickler diesen Wert zu verbessern, indem mehr kommentiert wird. In Zukunft ist zudem ein Info-Screen geplant, der auf den aktuellen Zustand der Entwicklung durch die Darstellung von Test- und Buildergebnisse aufzeigen soll.

Die aktuelle Konfiguration des CI-Servers Jenkins

Aktuell läuft der Jenkins in einer Konfiguration von einem Master und 8 Slaves jeweils in einer VMWare. Die Build- und Testprozesse sind in ca. 50 Jobs organisiert, die zum Teil Abhängigkeiten untereinander haben. Über 1300 Tests werden kontinuierlich ausgeführt und die Ergebnisse grafisch dargestellt. Einmal täglich werden von den 10 Hauptmodulen mit dem Sonar-Plugin Software-Metriken erfasst und über den verlinkten Sonar-Server zur Verfügung gestellt.

Fazit und Ausblick

Die Einführung von CI-Verfahren wird durch den Einsatz von CI-Servern  wie Hudson und Jenkins extrem vereinfacht. Durch eine immer stärker wachsende Community um Jenkins stehen immer mehr Plugins und Funktionen für die verschiedensten Prozesse und Auswertungen zur Verfügung. Durch ein Intelligentes Master-Slave Konzept ist es möglich, Zielsystem mit unterschiedlichen Konfigurationen anzusprechen und Integrationen zu testen. Insgesamt sind mit Jenkins kaum Grenzen gesetzt und der Einsatz zahlt sich schnell aus. In Zukunft wollen wir die CI-Funktionen bei SAPERION weiter ausbauen und verschiedene weitere Integrationen in die Testprozesse aufnehmen. Außerdem soll  mit der Installation eines Status-Screens für mehr Transparenz gesorgt werden und so die Qualität schrittweise verbessert werden.

Im nächsten Artikel werde ich verschiedene, bei SAPERION eingesetzte Testverfahren (Integration – und GUI-Tests) und deren Einsatz im CI-Umfeld und die Visualisierung der Testergebnisse vorstellen.

Post to Twitter Post to Delicious Post to Digg Post to Facebook Post to MySpace

Download PDF
Written by Burkhard Weber in: deutsch,general,language | Tags: , , ,

No Comments »

RSS feed for comments on this post. TrackBack URL

Leave a comment


+ four = 5

Theme: TheBuckmaker.com Web Templates | Bankwechsel Umschuldung, Iplexx IT Solutions