HowTo: Continuous Integration mit TeamCity
In meinem letzten HowToCode ging es um “Continuous Integration” und was es alles bieten könnte. Nun möchte ich ein konkretes Tool vorstellen: TeamCity. TeamCity ist ein kostenloser (Java basierende) Buildmanagement & Continuous Integration Server von JetBrains (welche auch den Resharper machen). Über eine schicke Weboberfläche ist das ganze auch schnell eingerichtet und man kann seine Builds usw. anstoßen.
Was ist TeamCity?
Wie bereits erwähnt, ist TeamCity im Grunde ein Java basierender Build- & CI Server. Man kann TeamCity auf Window-, Linux etc. installieren. Ich stelle hier nur die Windows Variante vor.
Da JetBrain ständig das Produkt erneuert, verlinke ich nur auf die Dokumentationsseite.
JetBrain hat auch eine Seite eingerichet wo man sich das Webfrontent mal anschauen kann: Live Demo
Was sind die Voraussetzungen?
Als Voraussetzung gilt natürlich, dass man einen Server hat (das kann auch derselbe Server sein wie das SVN z.B.) und das man alles was man zum Bauen braucht eingecheckt hat bzw. die Abhängigkeiten auch auf den Build Server installiert/hergestellt hat. Weitere Infos, warum das ein Build Server recht nützlich ist, siehe in meinem anderen Blogpost.
“Bestandteile”
Wenn man den Standard-Windows Installationsassistent folgt, wird der Build-Server und ein Build-Agent gleicht installiert. Beides kann getrennt konfiguriert werden. Dazu später mehr. Der Agent führt am Ende den Buildvorgang auf. Das kann für größere Projekte interessant sein, wenn man viele Projekte hat.
Jeder Agent kann andere Konfigurationen aufweisen, andere CPU Werte (für die Performance) und auf anderen Betriebsystemen etc. laufen.
Diese findet man auch auf der Weboberfläche wieder:
Installation
Hier eine kleine Schritt-für-Schritt Anleitung um den Server auf einer Windows Kiste zu installieren:
Die Screenshots habe ich von diesem Blog – da die Installation allerdings bei mir auch so aussah, habe ich die Bilderchens mal genommen.
Anmerkungen jetzt: Hier ist es sehr empfehlenswert den Server und Build Agent direkt als Windows Service zu installieren (was auch per default ausgewählt ist), ansonsten muss man ihn manuell starten.
Anmerkung: In meinem Fall lief auf Port 80 noch der IIS, daher musste ein anderer Port gewählt werden. Unter dem Punkt “Portänderungen” komm ich dann nochmal darauf zu sprechen.
Nun kann der Rest über das Webfrontend konfiguiert werden:
Bevor es losgeht muss erstmal ein Administatoraccount erstellt werden.
Nun kann auf der Oberfläche ein neues Projekt angelegt werden:
Über den “Create project” Link legt man ein neues Projekt an.
Der Ablauf beinhaltet 8 Schritte:
1. Name & Beschreibung
2. Zugang zum Subversion etc.
TeamCity ist sehr flexibel und unterstützt momentan diese Versionskontrollsystem:
3. Build Runner
TeamCity unterstützt neben .NET auch noch andere Frameworks/Sprachen. So kann man bei den Build Runnern momentan aus diesen auswählen:
Bei der Einstellung “sln2008″ kann man sein normales VS Solutionfile angeben. Dabei muss man beim “Solution file path” den Pfad (ausgehend vom SVN Repository) und die sln Datei angeben.
Die anderen Punkte ermöglichen tiefere Konfigurationen und Einstellungen. So kann man z.B. sagen, wann gebaut werden soll (Nachts) oder nach jedem Checkin etc.
Weitere prima Anleitungen:
-
Setting up a build environment
-
Screencast #46 – Setting up Continuous Integration for your Application with Team City
Run Builds
Über den “Run…” Button kann man neue Builds anstoßen. Dabei wird zuerst geschaut, ob neue Sourcen im Repository liegen und falls ja, wird dies runtergeladen und dann wird der entsprechende Buildrunner angestoßen.
Wenn alles geklappt hat, sollte man sowas sehen:
Live Demo
Ich empfehle euch mal einen Blick auf die Live Demo Page zu werfen und ein wenig drin rumklicken. Auf der Weboberfläche werden mit vielen AJAX Spielerein sinnvolle Informationen nachgeladen, so z.B. Kommentare aus den letzten Checkin:
Oder auch die dazugehörigen Files:
TeamCity – benötigte Windows Services & Portänderungen
TeamCity liefert zwar den Tomcat mit aus, allerdings sollte der Service ausgeschaltet bleiben bzw. ging es nur so bei mir. Es kann aber auch sein, dass der Tomcat durch etwas anderes evtl. installiert wurde. Diesen auf alle Fälle dekativieren.
Windows Services:
- Tomcat: deaktiviert
-TeamCity Build Agent Service: aktiviert
– TeamCity Web Server: aktiviert
Server & Buildagent lassen sich auch für andere Port konfigurieren.
Ich hatte bei mir folgendes Problem, dass auch dem selben Rechner auch noch ein IIS läuft.
Portkonfiguration:
Webserver Config: “C:\TeamCity\conf\server.xml” dort diese Zeile suchen und Wert entsprechend ändern:
<Connector port="8xxx" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
Nun müssen ebenfalls noch alle Build Agents entsprechend geändert werden. Dazu in dieser Datei:
“C:\TeamCity\buildAgent\conf\buildAgent.dist.properties” die serverUrl entsprechend mit den neuen Port anpassen.
Troubleshooting
Bei Fehlern lohnt sich immer ein Blick in den “logs” Ordner beim Server/Build Agent. Dort ist es recht detailiert beschrieben, was passiert und wo es knallt.
Unit Tests, Deployment etc.
Wir sind nun an dem Punkt an dem TeamCity installiert und benutzbar ist und das Projekt baut. Wie man Unit Tests oder gar ein Deployment ausführt werde ich in späteren HowTos behandeln.
Fazit:
TeamCity ist IMHO ein absolut geniales Tool und kann es locker mit dem Build Server vom TFS aufnehmen und die schicke Weboberfläche begeistert mit vielen netten Features und das ganze für Lau.
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Letzte Kommentare