Continious integration mit Hudson und Integrity
Continious Integration ist ein wichtiger Bestandteil von Software, vor allem wenn mehrere Beteiligte am Projekt Teilnehmen. Nach jedem Push wird dann der aktuelle Code vom CI-System ausgecheckt und die gewünschten rake-Tasks ausgeführt. Neben dem schon bekannten CrusieControll.rb gibt es noch zwei andere interesannte Cnotinious Integration Tools die ich kurz vorstellen möchte: Integrity und Hudson.
Integrity
Integrity ist sehr einfach gestrickt. Nach der relativ simplen installation kann man verschiedene Projekte hinzufügen. Der einzige “overhead” der noch ensteht, ist das zusammenstellen eines rake-tasks den Integrity nach jedem pull ausführt. Dieser einfacher rake-Task kann als Einstieg dienen:
Nach jedem Build können die Entwickler auch über die zu verfügung stehenden Notifier (Email, Campfire, IRC, …) über den Stand informiert werden. Weiterhin gibt es auch ein Growl-Plugin und Dashboard-Widget. Der Build der Applikation wird über Github via einem POST-Webhook zu Integrity angetriggert.
Der einzige Nachteil ist, dass bei lang-andauernden Builds der entsprechende Webserver einen Timeout erreicht. Der kann natürlich hochgesetzt werden.
Hudson
Hudson ist eine weitere Alternative. Es ist ein Java-Basiertes CI-System und wird out-of-the-box mit einem Webserver ausgeliefert. Entsprechende Debian-Packages gibt es hier. Hudson bietet gegenüber Integrity mehr Konfigurationsmöglichkeiten, daher dauert es ein bisschen länger bis man sein neues CI-System am laufen hat. Meet-Hudson bietet eine gute Übersicht über Hudson.
Der oben schon vorgestellte Rake-Task kann ebenfalls für Hudson verwendet werden. Allerdings müssen Plugins für eine Rake- und Githubunterstützung installiert werden (Git-Plugin und Rake-Plugin).
Bei Hudson ist der initiale Konfigurationsaufwand zwar geringer als bei Integrity, dafür müssen viele Plugins installiert und konfiguriert werden um seine “perfekte” CI-Umgebung ans laufen zu bekommen. Unschön an Hudson ist die fehlende unterstützung des triggern eines Builds über einen POST-Webhook. Stattdessen kann dies nur über ein GET getriggert, was aber seitens Github nicht unterstützt wird. Eine Alternative ist das periodische abprüfen von Änderungen in der Repository.
Comments
Leave a Reply