HowToCode: Continuous Integration
Im letzten Post ging es um SVN als Versionskontrolle und Trac als Projektmanagement & Bugtracking Tool, nun gehen wir einen Schritt weiter und die ganze Sache noch um einen Buildserver erweitern. Dies ermöglicht einige nette Sachen wie z.B. Nightly Builds, mehr Kontrolle & Sicherheit über den eingechecken Source Code bis hin zu automatischen Deployments – willkommen “Continuous Integration“.
Voraussetzungen für Continuous Integration
Als wichtigste Voraussetzung ist, dass der komplette Source Code in einem Source Control System, wie z.B. einem Team Foundation Server, ein Subversion, CVS etc. eingecheckt ist. Ich nutze z.B. in meinem Hobbyprojekt SVN.
Dazu benötigt man noch eine extra Maschine, die als Buildserver herhalten kann.
Wofür ein Buildserver?
In einem Team (und je größer das Team, desto komplizierter) kommt es häufig vor, dass Source Code eingecheckt wird, der bei einem Teamkollegen nicht baut. Das kann damit zusammenhängen, dass nur bestimmte Teile eingecheckt wurden sind oder das bestimmte Abhängigkeiten (z.B. DLLs) einfach auf dem anderen Rechner nicht vorhanden sind.
Aus Erfahrung kann ich sagen, dass es nicht schön ist früh morgens den neusten Stand zu laden und nix baut mehr.
Abhilfe kann ein Buildserver schaffen.
Nach jedem Checkin oder nach einer bestimmten Zeit (z.B. jede Nacht – ein “Nightly Build”) wird automatisch auf einem Server der letzte Stand geladen und gebaut. Derjenige der zuletzt eingecheckt hat wird informiert, dass es nicht baut usw.
Weitere Möglichkeiten:
Durch den Einsatz eines Buildserver kann man noch weitere nette Sachen machen – denn was nützt ein funktionierender Build, wenn die Funktionalität nicht hinhaut. Durch den Einsatz eines Buildservers können z.B.:
- … automatisch Unittests ausgeführt werden.
- … Dokumentation (aus den Code Kommentaren) erzeugt werden.
- … Release Notes (aus den letzten Checkin Kommentaren bzw. Tickets die durch den Checkin geschlossen wurden) erstellt werden.
- … ein Deployment Paket erstellt werden.
- … automatisch auf ein Testsystem deployed werden.
- …
Tools
Wie bereits in diesem Blogpost erwähnt gibt es von Microsoft den Team Foundation Server der auch Buildserver sein kann. Wie gesagt: Es ist eine integrierte eierlegende Wollmilchsau. Leider ist dies etwas kostspieliger, daher habe ich in einem Hobbyprojekt eine andere Software für mich entdeckt: TeamCity. Ich werde demnächst ein, zwei HowTos zu TeamCity + .NET + MSTest schreiben.
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.
Peter Bucher
8. July 2009
So, der letzte für Heute.
Finalbuilder kriegst du als MVP auch kostenlos
Ich fahre sehr gut damit, aber TeamCity schaut auch nett aus.
Simon Wolters
9. July 2009
Hi Robert,
kann man den Buildserver nicht auf der gleichen Maschine laufen lassen, auf der auch das SVN-Repository liegt? Ich bin gespannt auf die HowTos!
Robert Mühsig
9. July 2009
Das wäre prinzipell möglich. Da ich bei meinem Projekt einen SVN Hosting in Anspruch nehme, kam das bei mir nicht in Frage. Aber wenn man selber einen Rechner hat, dann kann dieser (denke ich) auch als Buildserver dienen.
Toller ist es aber sicherlich alles fein voneinander zu trennen – aber man kann ja nicht alles haben
Peter Bucher
9. July 2009
Hallo Robert
Die Trennung bringt ja nur bei grösseren Projekten was und wenns sonst zu lahm wird.
Wichtiger finde ich, das SVN und der Buildserver im Internet erreichbar sind.
So können mehrere an einem Projekt arbeiten und von irgendwo her einchecken.
Der Buildserver kann dann schön bspw. die Testwebseite updaten.
Golo und ich machen das so bei einem unserer Projekte. So hat man immer “kontinuierlich” den neusten Entwicklungsstand zum testen online
Alexey
12. July 2009
Hallo, Robert! Ich schreibe per Du, wenn es ok ist.
Ich lese Deinen tollen Blog schon seit einem Jahr, glaub ich und finde Infos, die Du postest Gold wert.
Ich habe jetzt eine kleine Frage. Ich möchte meinen eigenen einfachen Blog-engine programmieren mit vs2008, also ganz einfachen, zu Lernzwecken, Hosting habe ich schon. Ich habe c#/asp.net Grundkenntnisse und habe schon mit VS2008 einige Erfahrung gesammelt.
Womit soll ich am besten anfangen, Deiner Meinung nach?
So eine Art Pflichtenheft habe ich schon erstellt, die Version 0.0 wird nur 3 Möglichkeiten haben – Eintrag verfassen, Eintreg posten, Eintrag Löschen.
Soll ich gleich MVC einsetzen oder nicht? Welchs RDBMS soll ich hier am besten einsetzen?
Danke!
Alexey
Robert Mühsig
13. July 2009
Hallo Alexey,
ich persönlich würde auf MVC setzen – das ist IMHO einfacher. Schau dir dazu einfach mal das Nerddinner PDF und die sample Application an. Als Datenbank würde ich MySQL oder MSSQL nehmen. Wenn du MSSQL nimmst, kannst du als O/R Mapper Linq2Sql nehmen wie bei dem Nerddinner. Ansonsten wäre für dich vielleicht noch SubSonic (oder MVC+Subsonic) oder NHibernate ActiveRecord interessant.
Bei weiteren Fragen schreib mir einfach eine Mail
Kristof
14. July 2009
Eine echte (Open-Source-)Alternative für Continuous Integration ist CruiseControl.NET (http://sourceforge.net/projects/ccnet) im Zusammenspiel mit CCNetConfig, für die Fenster-verwöhnten Admins.
Der CCNet-Server-Dienst läuft bei uns auf der gleichen Maschine wie SVN-Server und verarbeitet alle SVN-Commits direkt in neue Builds und veröffentlicht sie.
Kompilieren, testen, committen, vergessen…