News

Update der .NET Build Projekt Vorlagen für Visual Studio 2008

16.05. 2008

Die Projektvorlagen für die .NET Buildumgebung wurden für Visual Studio 2008 ergänzt. Ausserdem wurde ein Checkout Problem in der Vorlage für Visual Studio 2005 mit SourceSafe behoben.

Weiterlesen …

Neuer Artikel über das Debuggen des .NET Frameworks

04.05. 2008

Ein neuer Artikel über das Debuggen der .NET Framework Basisklassen ist verfügbar.

Weiterlesen …

Newsfeed

Die News sind auch als RSS Feed verfügbar und können mit einem entsprechenden Programm abonniert werden. Wie geht das? Lesen sie mehr dazu auf Wikipedia.

Wissen > Aufbau einer Continuous Integration Build Umgebung für .NET

Aufbau einer Build Umgebung für .NET

Diese Artikelserie beschreibt den Aufbau einer Projekt und Build Vorlage für die .NET basierte Entwicklung mit Visual Studio.

Inhaltsverzeichnis


Wie im Artikel Best Practices für Continous Integration Systeme erläutert wird, sollte jeder Entwickler den Build Prozess des Servers auch lokal durchführen können, um Änderungen vor dem Überführen ins Repository auf ihre Funktion überprüfen zu können. Auf dem Build Server sind unter Umständen einige zusätzliche Aktionen für das Deployment einer Lösung nötig, aber der Ablauf des Builds ist grundsätzlich derselbe.

Der nun vorgestellte Prozess beschreibt eine einfache Lösung, welche die rudimentären Schritte in einem Build abbildet. Die Lösung ist als Vorlage für einen einfachen Build Prozess gedacht und beinhaltet auch eine wiederverwendbare Visual Studio Projektstruktur.
Es ist gut möglich, dass sie oder ihr Team weitere oder andere Anforderungen haben. Dies stellt jedoch kein Problem dar, die Lösung ist modular aufgebaut, jeder Schritt lässt sich beliebig anpassen und durch weitere Elemente ausbauen.

Der Build Prozess soll folgende grundlegende Aufgaben durchführen. Die einzelnen Schritte werden nachfolgend im Detail erklärt.

Build Prozessablauf


Nicht alle diese Schritte werden bei jedem Build Vorgang durchgeführt. Ebenso soll unterschieden werden, ob ein Build lokal oder auf dem Build Server ausgeführt wird. Deshalb werden 2 verschiedene Build Typen unterschieden:
  1. ContinuousBuild
    Der ContinuousBuild wird abhängig von den eigenen Präferenzen in einem Intervall durchgeführt. Er sollte mindestens einmal pro Tag/Nacht laufen, kann aber auch nach jedem Commit ins Repository (Checkin) durchgeführt werden.
    Der ContinuousBuild versioniert die Assemblies, kompiliert den Source Code, führt die Tests durch und publiziert diese Resultate auf dem Portal.

  2. ReleaseBuild
    Der ReleaseBuild wird bei Bedarf manuell ausgeführt. Er wird dann benötigt, wenn eine neue Version des Projektes veröffentlicht werden soll, oder eine Iteration oder Projektphase abgeschlossen ist.
    Der ReleaseBuild erstellt zusätzlich zum ContinuousBuild einen optionalen Installer, verteilt diesen, versioniert den Source Code im Repository mit der Version des Builds.

Folgende Technologien und Tools werden verwendet:
  • Visual Studio 2005/2008 Standard oder höher
  • Microsoft .NET 2.0 oder 3.5 SDK
  • MSBuild 2.0 / 3.5 mit den MSBuild Community Tasks
  • CruiseControl.Net 1.3 als CI System
  • NUnit 2.4 für die Unit Tests

Die Projekt Vorlage ist unter Download in zwei Varianten verfügbar:
  • Mit Subversion als Source Code Repository
  • Mit Visual SourceSafe als Source Code Repository
Nebst Visual Studio 2005 oder 2008 und ggf. Visual SourceSafe sind alle anderen benötigten Tools frei verfügbar.
Wenn sie oder ihr Team zum Teil andere Technologien verwenden, können sie die entsprechenden Tools durch ihre Lösung ersetzen. Beispielsweise können sie anstelle von MSBuild auch NAnt, anstelle von NUnit auch MbUnit einsetzen.
Selbst wenn sie anstelle von CruiseControl.NET eine Lösung wie TFS (Microsoft Team Foundation Server) und damit verbunden wahrscheinlich MS Test als Unit Test Framework einsetzen, können sie die Projektvorlage und Teile der Build Konfiguration nutzen.

Dies sind wie gesagt jedoch nur die Grundelemente für einen einfacheren Build Prozess. Weitere Elemente wie die Auswertung der Code Abdeckung durch die Tests (Code Coverage), eine statische Code Analyse, die Erstellung der Entwickler Dokumentation aus XML Code Kommentaren lassen sich beliebig in die Lösung integrieren.

Der Start mit einem umfangreichen und gegebenenfalls zu komplexen Build Prozess kann kontraproduktiv sein.
Wenn mit einer CI Lösung neu begonnen oder die ganzen CI Grundsätze in einer Organisation oder einem Team neu eingeführt werden sollen, kann eine zu umfangreiche und gegebenenfalls zu komplexe Lösung unter Umständen zu Ablehnung bei den Mitarbeitern führen. Die Erfahrung zeigt, dass die Akzeptanz unter den Entwicklern höher ist, wenn eine anfänglich einfachere Lösung in späteren Schritten erweitert wird.