TFS 2010 Teambuild für SharePoint- und Silverlight Projekte

Ein Teambuild erhöht in hohem Maße die Qualität – ganz besonders, wenn Unterschiedliche Entwickler (z.B. Silverlight und SharePoint) zusammen an einem Projekt arbeiten. Besonders in Verbindung mit dem “Gated Check-In” wird sichergestellt, dass nur Änderungen eingecheckt werden, die sich auch in einer “neutralen” Umgebung bauen lassen. Leider gibt es bei der Konfiguration einige Stolperfallen.

Buildservice pro Project Collection

Um einen Teambuild einzurichten, muss der aktuellen Project Collection ein Buildserver zugewiesen werden. Es gibt zwar die Möglichkeit mehrere Instanzen der Buildservices auf einem Rechner einzurichten. Da dies aber nicht supported ist benötigt mal prinzipiell einen Buildserver pro Project Collection.

Workspace

Workspace für Gated Check-In

Damit der Gate auch nur für den Branch gilt, den er auch betrifft, muss der Workspace entsprechend angepasst werden. In Abbildung 1 wird der Gated Check-In z.B. nur im DEV Branch eingerichtet.


Abbildung 1: Workspace

The specified path, file name, or both are too long

Der Fehler mit dem man sich am häufigsten herumärgert, ist dass die Pfadlängen das Windows Maximum überschreiten. In TFS 2008 hat man sich damit behelfen können, das man bei “Build Agend Folder” einen festen Pfad eingetragen hat (z.B. D:\Build\Kunde\Projekt). In TFS 2010 sollte man das nicht tun, da es ja normal mehrere Agents gibt, die den Build ausführen. Ein Ordner im Dateisystem lässt sich aber nur in einen Workspace mappen – und jeder Agent hat seinen eigenen Workspace. Der Feste Pfad funktioniert also nur so lange, bis der nächste Agent den Build ausführt.

Der bessere Weg ist es den Wert $(SourceDir) anzupasseb. Dies geschieht über die Eigenschaften der Agents.


Als Minimum muss hier eine Variable für den Agent und den Build verwendet werden. Die hier gezeigte Konfiguration würde zum Beispiel für Agent 1 und den Build 5 folgenden Pfad ergeben: D:\Builds\1\5\…

Process Parameters

Dann gibt es noch ein paar Parameter, an denen man drehen muss.

Silverlight

Bei Silverlight Projekten muss man zwingend die MSBuildPlattform auf X86 stellen. Sonst bekommt man Fehlermeldungen, dass Targets nicht gefunden werden können. Bei der Verwendung von Silverlight UnitTests muss man die Tests über “Disable Tests” deaktiviewren, da leider momentan OOB noch keinen Silverlight Tests unterstützt werden.

SharePoint

Soll beim Build eine WSP Datei erstellt werden, so muss dem Build das Argument /p:IsPackaging=True übergeben werden.


Alle anderen Dinge sollten eigentlich selbsterklärend und einfach sein.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s