Continuous Integration im Web Development: TeamCity CI Server

In diesem Teil der Serie widmen wir uns dem zentralen Tool in unserem CI-Workflow, nämlich dem Integration Server TeamCity [1], welcher von der Firma JetBrains entwickelt wurde.

Continuous Integration im Web Development - Blog Serie Teil 2

Dieser wird es in unserem Fall ermöglichen, den aktuellen Status des Projekts von einem Github Repository in regelmäßigen Abständen auszuchecken, Unit Tests auszuführen, und nach erfolgreichem Durchlauf der Tests den aktuellen Status zu deployen.


Installation von TeamCity

Die aktuelle Version von TeamCity kann unter [2] heruntergeladen werden. Unter den möglichen Lizenzoptionen gibt es eine Gratis-Variante, welche bereits den vollen Funktionsumfang zur Verfügung stellt. Beschränkungen gelten dabei für die maximale Anzahl der Build-Konfigurationen, sowie für die maximale Anzahl an Build-Agents (zu diesen beiden Begriffen kommen wir später noch).

TeamCity ist für die Betriebssysteme Windows, Mac OS X, und Linux verfügbar. Darüber hinaus stellt JetBrains die Anwendung als .war Archiv zur Verfügung, welches auf einem bereits vorhandenen Anwendungsserver, wie z.B. JBoss deployed werden kann. Wir werden in weiterer Folge die Linux Version verwenden.


Build Agents

Build Agents sind Clients, die mit dem TeamCity Server verbunden sind und von diesem verwaltet werden können. Sie haben die Aufgabe, die Builds auszuführen, sobald sie vom Server den Befehl dafür erhalten. Diese Build Agents können dabei auf verschiedenen Rechnern, bzw. unter verschiedenen Betriebssystemen laufen. Am Server können dann unter anderem Build-Konfigurationen so eingestellt werden, dass diese nur auf Build-Agents, welche auf einem bestimmten Betriebssystem laufen, ausgeführt werden. Dies ist vor allem dann praktisch, wenn eine Anwendung für mehrere Plattformen entwickelt wird und somit auf mehreren Plattformen getestet werden soll.

In unserem Beispiel verwenden wir den default Build Agent, welcher bereits in der Installation von TeamCity enthalten ist.

Nach der Installation kann man sich unter der URL localhost:8111 anmelden. Da nach der Installation noch kein Benutzer vorhanden ist, kann man sich mit einem leeren Benutzernamen und einem Token, welches in der Datei teamcity-server.log zu finden ist, anmelden.

Es wird empfohlen, direkt danach einen Benutzer mit Admin-Rechten einzurichten, bevor man mit dem Einrichten der Build-Konfigurationen loslegt. In diesem Artikel wird darauf nicht eingegangen, aber der Vorgang sollte selbsterklärend sein.


Erstellen von Build-Konfigurationen

Auf der Startseite von TeamCity bekommt man einen Überblick über alle eingerichteten Projekte, sowie deren aktuellen Status (siehe Abbildung 1).

TeamCity Startseite
Abbildung 1: TeamCity Startseite

Durch Auswahl des Menüpunkts „Administration“ kommt man in das Administrationsmenü, in dem unter anderem neue Projekte angelegt werden können (siehe Abbildung 2).

Administrationsoberfläche
Abbildung 2: Administrationsoberfläche

Der Großteil der Einrichtung von neuen Projekten, inklusive dem Einrichten von VCS Roots, wie z.B. von GitHub, sollte selbsterklärend sein, weswegen wir uns hier nur auf das Einrichten von Build-Konfigurationen konzentrieren werden.

Nach Auswahl der Option „Create Build Configuration“ auf der Übersichtsseite des Projekts kommen wir auf eine Seite, auf der die nötigen Einstellungen vorgenommen werden können (Siehe Abbildung 3). Nachdem die allgemeinen Einstellungen, wie der Name der Konfiguration, der ID, sowie dem Build Number Format abgeschlossen wurden, fügen wir einen neuen Build Step hinzu, mit dem wir die aktuelle Version des Projekts in den Web-Ordner kopieren und somit die aktuelle Version veröffentlichen. Weiters werden in diesem Build Step die Tests ausgeführt.

Der Einfachheit halber werden wir dies mit einem einfachen Command Line Script erledigen, aber TeamCity bietet noch weitere Optionen, mit denen zum Beispiel Ant, Maven oder Gradle Scripts ausgeführt werden können, was vor allem für Projekte im Java Umfeld praktisch ist.

In diesem Script wird zunächst der alte Status des Projekts aus dem Web Directory gelöscht, und anschließend der aktuelle Status in das Web Directory kopiert. Im Anschluss daran müssen die Rechte für die kopierten Dateien aktualisiert werden, da der Web-Server die Schreibrechte für die Dateien benötigt. Zuletzt werden die PHPUnit Tests ausgeführt, die auf alle Fälle vorhanden sein sollten ;-)

Build-Konfiguration Einstellungen
Abbildung 3: Build-Konfiguration Einstellungen

Command Line Script

echo "Removing old files"
sudo rm -r /var/www/*

echo "Copying files"
sudo cp -r * /var/www/

echo "Fixing permissions"
sudo chmod -R 775 /var/www/
sudo chown -R www-data /var/www

echo “Running PHPUnit Tests”
#phpunit --configuration /var/www/protected/tests/phpunit.xml /var/www/protected/tests

TeamCity bietet auch die Möglichkeit, mehrere Build Steps zu konfigurieren, welche auch abhängig voneinander sein können. So ist es zum Beispiel möglich, einen Build Step einzurichten, der wieder die letzte funktionierende Version deployed, falls die PHPUnit Tests der aktuellen Version fehlschlagen.

Anschließend daran muss TeamCity noch mitgeteilt werden, wann dieser Build-Step ausgeführt werden soll. Dies kann unter dem Menüpunkt „Build Triggers“ erledigt werden. So kann man zum Beispiel einen neuen Durchlauf starten, sobald eine neue Änderung in den VCS Root eingecheckt wurde, oder aber auch regelmäßig in gewissen Zeitintervallen.


Schlussfolgerung

In diesem Teil der Serie haben wir die Grundlage für unseren Continuous Integration Prozess vorbereitet. Mit Hilfe des TeamCity Integration Server ist es uns nun möglich, automatisiert den aktuellen Status unseres Projektes auszuchecken, zu deployen und auch zu testen.

In zukünftigen Teilen der Serie werden wir uns damit beschäftigen, diesen Workflow noch mit der Hilfe einiger Tools zu erweitern, die es uns erleichtern werden, den aktuellen Status im Hinblick auf die Codequalität zu analysieren.

Außerdem werden wir durch die Einbindung eines Issue Trackers die Kommunikation innerhalb des Entwicklungsteams verbessern.

« Zurück zur Übersicht

« Zurück von Dipl.-Ing. Florian Bacher von Dipl.-Ing. Florian Bacher Weiter »

Zur besten Nutzung dieser Website und zur Bedienerfreundlichkeit werden Cookies verwendet. Diese Website nutzt zusätzlich Google Analytics und Scripte, welche Cookies benutzen. Wenn Sie diese Website weiter nutzen, gehen wir von Ihrem Einverständnis aus. [ Mehr zum Datenschutz ].
OK