Kontinuierliche Integration mit Hudson

Die kontinuierliche Integration ist für Teams zur gängigen Praxis geworden, die sich darauf konzentrieren, die Codequalität während des gesamten Lebenszyklus der Softwareentwicklung sicherzustellen. In diesem Artikel stellt Nicholas Whitehead Hudson vor, einen beliebten Open-Source-CI-Server. Erfahren Sie, wie Sie einen Hudson-Server in Ihrer Anwendungsentwicklungsumgebung einrichten (Beispiele für Windows XP mit Tomcat 6 oder Ubuntu Linux mit JBoss AS), erhalten Sie einen Überblick über die vielen Konfigurationsoptionen, die Hudson bietet, und implementieren Sie anschließend einen automatisierten Build, Test, und Berichtsprozess für ein Beispielprojekt. Level: Anfänger

Continuous Integration (CI) ist eine Reihe von Methoden, die den Prozess der Erstellung von Software-Builds vereinfachen und stabilisieren sollen. CI unterstützt Entwicklungsteams bei folgenden Herausforderungen:

  • Software-Build-Automatisierung : Mit CI können Sie den Build-Prozess eines Software-Artefakts auf Knopfdruck, nach einem vordefinierten Zeitplan oder als Reaktion auf ein bestimmtes Ereignis starten. Wenn Sie ein Software-Artefakt aus dem Quellcode erstellen möchten, ist Ihr Erstellungsprozess nicht an eine bestimmte IDE, einen bestimmten Computer oder eine bestimmte Person gebunden.
  • Kontinuierliche automatisierte Build-Überprüfung : Ein CI-System kann so konfiguriert werden, dass Builds ständig ausgeführt werden, wenn neuer oder geänderter Quellcode eingecheckt wird. Dies bedeutet, dass ein Team von Softwareentwicklern regelmäßig neuen oder geänderten Code eincheckt, das CI-System den Build jedoch kontinuierlich überprüft wird durch den neuen Code nicht beschädigt. Dies reduziert die Notwendigkeit für Entwickler, Änderungen an voneinander abhängigen Komponenten miteinander zu überprüfen.
  • Kontinuierliche automatisierte Build-Tests : Als Erweiterung der Build-Überprüfung stellt dieser Prozess sicher, dass neuer oder geänderter Code nicht dazu führt, dass eine Reihe vordefinierter Tests für die erstellten Artefakte fehlschlägt. Sowohl bei der Build-Überprüfung als auch beim Testen können Fehler Benachrichtigungen an interessierte Parteien auslösen, die darauf hinweisen, dass ein Build oder einige Tests fehlgeschlagen sind.
  • Automatisierung von Prozeduren nach dem Build : Der Build-Lebenszyklus eines Software-Artefakts erfordert möglicherweise auch zusätzliche Aufgaben, die nach Abschluss der Build-Überprüfung und -Tests automatisiert werden können, z. B. das Generieren von Dokumentation, das Packen der Software und das Bereitstellen der Artefakte in einer laufenden Umgebung oder in einem Software-Repository. Auf diese Weise können Artefakte den Benutzern schnell zur Verfügung gestellt werden.

Um einen CI-Server zu implementieren, benötigen Sie mindestens ein zugängliches Quellcode-Repository (und den darin enthaltenen Quellcode), eine Reihe von Build-Skripten und -Prozeduren sowie eine Reihe von Tests, die für die erstellten Artefakte ausgeführt werden sollen. Abbildung 1 zeigt die Grundstruktur eines CI-Systems.

Die Systemkomponenten kommen in der folgenden Reihenfolge ins Spiel:

  1. Entwickler checken neuen und geänderten Code in das Quellcode-Repository ein.
  2. Der CI-Server erstellt für jedes Projekt einen dedizierten Arbeitsbereich. Wenn ein neuer Build angefordert oder geplant wird, wird die Quelle aus dem Repository in diesen Arbeitsbereich abgerufen, wo der Build dann ausgeführt wird.
  3. Der CI-Server führt den Erstellungsprozess im neu erstellten oder aktualisierten Arbeitsbereich aus.
  4. Nach Abschluss des Builds kann der CI-Server optional die definierte Testsuite für die neuen Artefakte aufrufen. Wenn der Build fehlschlägt, können registrierte Personen per E-Mail, Instant Messaging oder auf andere Weise benachrichtigt werden.
  5. Wenn der Build erfolgreich ist, werden die Artefakte gepackt und an ein Bereitstellungsziel (z. B. einen Anwendungsserver) übertragen und / oder als neues versioniertes Artefakt in einem Software-Repository gespeichert. Dieses Repository kann Teil des CI-Servers sein oder ein externes Repository, z. B. ein Dateiserver oder eine Softwareverteilungssite wie Java.net oder SourceForge. Das Quellcode-Repository und das Artefakt-Repository können getrennt sein, und es ist tatsächlich möglich, einige CI-Server ohne formelles Quellcodeverwaltungssystem zu verwenden.
  6. CI-Server verfügen normalerweise über eine Art Konsole, in der Projekte konfiguriert und debuggt werden können und in der Anforderungen für Vorgänge wie sofortige Ad-hoc-Builds, Berichterstellung oder Abrufen von erstellten Artefakten ausgegeben werden können.

Hudson: Ein Continuous Integration Server

Die kontinuierliche Integration hat in den letzten Jahren an Popularität gewonnen und heute stehen Ihnen zahlreiche CI-Server zur Auswahl, sowohl kommerzielle als auch kostenlose. Ich persönlich hatte vier CI-Server verwendet, bevor ein Kollege mir empfohlen hatte, mir Hudson anzusehen. Ich war sofort davon beeindruckt. Während ich anfänglich davon ausging, dass Hudson nicht bekannt ist, zeigt eine Umfrage auf der Java Power Tools-Website, dass Hudson der am häufigsten verwendete CI-Server unter den Befragten ist und (zum Zeitpunkt dieses Schreibens) 37,8 Prozent aller Stimmen erhielt.

Unterstützte SCMs

Hudson hat die Unterstützung für Subversion sofort integriert, und für die Integration in CVS ist nur eine geringe Menge an Konfiguration erforderlich, vorausgesetzt, der CVS-Client ist auf dem Hudson-Host installiert. Mehrere andere SCM-Lösungen (Source Code Management) werden in Form von Hudson-Plugins unterstützt. Zum Zeitpunkt dieses Schreibens werden die folgenden SCMs unterstützt:

  • Accurev
  • BitKeeper
  • Klarer Fall
  • Git
  • Mercurial
  • Perforce
  • StartTeam
  • Team Foundation Server
  • Visual SourceSafe
  • URL SCM (ein spezielles SCM-Plugin, das die Verwendung von URLs für SCM ermöglicht)

In diesem Artikel verwende ich Subversion und das Quell-Repository von Java.net, sodass Sie keines dieser Plugins installieren müssen. (Nebenbei kenne ich jemanden, der an einem MKS SourceIntegrity Hudson-Plugin arbeitet. Wenn Sie daran interessiert sind, senden Sie mir eine E-Mail.)

Hudson ist ein kostenloses Open-Source-Produkt, das auf Java.net gehostet wird. Es wurde ursprünglich von Kohsuke Kawaguchi, einem Mitarbeiteringenieur bei Sun Microsystems, geschrieben, der seine Veröffentlichung im Februar 2005 in seinem Blog angekündigt hat. Hudson hat seitdem ungefähr 154 Veröffentlichungen.

Hier sind einige der Gründe, warum ich Hudson mag und warum ich es Ihnen empfehlen würde, sofern keine ungewöhnlichen Anforderungen bestehen:

  • Von allen CI-Produkten, die ich verwendet habe, ist es bei weitem am einfachsten zu installieren und zu konfigurieren.
  • Die webbasierten Benutzeroberflächen sind sehr benutzerfreundlich, intuitiv und reaktionsschnell und bieten in vielen Fällen sofortiges Ajax-fähiges Feedback zu einzelnen Konfigurationsfeldern.
  • Hudson basiert auf Java (was nützlich ist, wenn Sie ein Java-Entwickler sind), ist jedoch nicht auf das Erstellen von Java-basierter Software beschränkt.
  • Hudson ist sauber komponiert und bietet eine gut definierte und dokumentierte Erweiterbarkeits-API in Form von Hudson-Plugins. Dies hat wiederum zu einer großen Bibliothek von Hudson-Plugins geführt, die die Funktionalität des Servers erweitern. Diese sind frei verfügbar und können über die Hudson-Konsole installiert werden.

Installation von Hudson: Windows XP oder Ubuntu Linux

Um Hudson verwenden zu können, benötigen Sie ein zugängliches und unterstütztes Versionsverwaltungssystem (eine Liste finden Sie in der Seitenleiste "Unterstützte SCMs"), eine Quelle, die in ein Artefakt integriert werden kann, und ein funktionierendes Erstellungsskript. Darüber hinaus benötigen Sie zur Installation und Konfiguration eines funktionierenden Hudson-Servers lediglich eine Installation von Java, Version 1.5 oder höher, und die Hudson-Installationsdatei, die in Form eines Java EE-Webarchivs (WAR) vorliegt. Sie können den Server ganz einfach über die folgende Befehlszeile starten:

C:\hudson> java -jar hudson.war

Es ist jedoch wahrscheinlich üblicher, Hudson auf einem Java-Servlet-Container bereitzustellen, der auf den Servlet 2.4- und JSP 2.0-Spezifikationen wie GlassFish, Tomcat, JBoss oder Jetty basiert. In den nächsten Abschnitten werde ich Sie durch zwei Hudson-Installationsszenarien führen: eines mit Tomcat 6 unter Windows XP und eines mit JBoss 4.2.3 unter Ubuntu Linux. (JBoss AS 5.0 wurde nach dem Einreichungsdatum dieses Artikels veröffentlicht.)

Installation von Hudson: Tomcat 6 und Windows XP

Ich gehe davon aus, dass auf Ihrem Windows XP-Computer bereits Version 1.5 oder höher von Java installiert ist. Wenn Sie die folgenden Schritte ausführen, wird Tomcat 6.0.18 mit dem Windows Service Installer installiert, sodass Hudson sofort nach dem Start von Windows XP gestartet wird und im Hintergrund ausgeführt wird, auch wenn kein Benutzer angemeldet ist. Die Download-Datei für Tomcat lautet apache-tomcat-. 6.0.18.exe, die Sie ausführen sollten, um die Tomcat-Installation zu starten.

Bei der Tomcat-Installation werden Sie aufgefordert, die Installationsoptionen auszuwählen. Stellen Sie sicher, dass Sie Benutzerdefinierte Optionen und dann Dienst auswählen (siehe Abbildung 2), damit Tomcat als Dienst ausgeführt wird.

Wählen Sie als Nächstes ein Verzeichnis aus, in dem Sie Tomcat installieren möchten (siehe Abbildung 3). Ich empfehle dringend, ein Verzeichnis ohne Leerzeichen auszuwählen. Du kannst mir später danken.

Jetzt werden Sie vom Installationsprogramm gefragt, welchen Port Sie abhören möchten. Der Standardwert ist Port 8080, was wahrscheinlich in Ordnung ist. Stellen Sie einfach sicher, dass Sie keine andere Anwendung haben, die diesen Port verwendet. In diesem Fall wird Tomcat nicht ordnungsgemäß gestartet. Sie werden außerdem aufgefordert, einen Benutzernamen und ein Kennwort für den Tomcat-Administrator anzugeben. All dies ist in Abbildung 4 dargestellt.

Das Installationsprogramm fordert Sie dann auf, den Speicherort der von Ihnen installierten Java JRE anzugeben. Wie Sie in Abbildung 5 sehen können, habe ich Sun Java 1.6.0_07 verwendet.

Once you click Install, the installation should run to completion and the service will start running. You can make sure that Tomcat is operating correctly by pointing your Web browser to //localhost:8080 (substituting the appropriate name or IP address for localhost if you aren't using a Web browser running on the computer where Tomcat is installed). The Web page displayed should look something like the screenshot in Figure 6.

Now, to install Hudson, copy the hudson.war file to the webapps subdirectory of your Tomcat installation directory. If you used the same install directory shown in Figure 3, this would be C:\Tomcat6\webapps. Tomcat will hot-deploy WAR files, but the easiest thing to do now is restart Tomcat. There are two ways to do this. The first is to open a DOS shell and enter the following commands:

 C:\Tomcat6>net stop Tomcat6 C:\Tomcat6>net start Tomcat6

The second option is to open the Services applet. This applet can be found in the Administrative Tools group in the Control Panel, which can be located by clicking the Start button on the Windows toolbar, then selecting Settings and then Control Panel. In the Services applet, locate the service named Apache Tomcat and then click the Restart button. This is illustrated in Figure 7.

Hudson should now be installed. You can verify this by pointing your Web browser to //localhost:8080/hudson. The main Hudson screen is shown in Figure 8.

That's all there is to it! If you're comfortable with an application development environment based on Windows XP and Tomcat, you're all set. If you prefer a system running JBoss and Ubuntu Linux, read on.

Installing Hudson: JBoss 4.2.3 on Ubuntu Linux 8.04 (Hardy Heron)

To install Sun Java 1.6 on Ubuntu, open a shell and execute the following command:

 sudo apt-get install sun-java6-jdk

When issuing a sudo command, you will be prompted to enter your password.

Note that there are several ways to install JBoss; in the technique outlined here, you'll create a dedicated jboss user. This is considered a best practice, and is preferable to installing JBoss in your own home directory. The procedure outlined here has been condensed from a useful description at the Ubuntu forums.

First, you need to download the JBoss 4.2.3.GA package. Look for the file named jboss-4.2.3.GA.zip.

Next, you will need to create a user, a home directory, and a group, all named jboss. The group is a convenience not explored in this article; it will allow you to extend JBoss privileges to other users on your Ubuntu server.

Listing 1 shows the commented commands to create the jboss home directory, user, and group, and then install the JBoss server. Some commands are prefixed with sudo because they are root-privileged commands.

Listing 1. Creating the jboss account and installing the server

echo Create the jboss group sudo groupadd jboss echo Create the jboss user, define bash as the user's default shell and /home/jboss as the home directory echo and make the user jboss part of the group jboss sudo useradd -s /bin/bash -d /home/jboss -m -g jboss jboss echo Copy the jboss-4.2.3.GA file to /home/jboss or download directly into that directory sudo mv jboss-4.2.3.GA /home/jboss echo Change the owner of the file to jboss sudo chown jboss:jboss /home/jboss/jboss-4.2.3.GA echo Log into the jboss account sudo su jboss echo Go to the jboss home directory cd ~ echo Unzip the file jboss-4.2.3.GA unzip jboss-4.2.3.GA echo Create a symbolic link "jboss" for "jboss-4.2.3.GA". echo This allows you to change JBoss versions with minimal changes ln -s jboss-4.2.3.GA jboss

If the unzip command is not already installed, enter the following command (while logged in as a sudo-enabled user) to install it:

Sudo apt-get install unzip

The JBoss server is now basically installed. You could start the server using the following command:

/home/jboss/jboss/bin/run.sh

In diesem Beispiel installieren Sie jedoch stattdessen ein automatisches Startskript, damit der Dienst beim Start des Hosts automatisch gestartet wird. Der JBoss-Download enthält drei verschiedene int.d-Skripte, die jedoch jeweils angepasst werden müssen. Sie können das Skript jboss-init.sh herunterladen, das das automatische Starten und Stoppen des Servers ermöglicht. Führen Sie dann die in Listing 2 gezeigten Befehle aus.