Mit dem Team Foundation Server 2010

Automatisierte Builds für SharePoint (Teil 2)
Kommentare

Builds im SharePoint-Kontext
Mit den zuvor beschriebenen, allgemeinen Bestandteilen einer Team-Foundation-Server-Build-Definition kann nahezu jedes .NET-basierte Projekt serverseitig erstellt werden. Bei

Builds im SharePoint-Kontext

Mit den zuvor beschriebenen, allgemeinen Bestandteilen einer Team-Foundation-Server-Build-Definition kann nahezu jedes .NET-basierte Projekt serverseitig erstellt werden. Bei SharePoint-Projekten hingegen müssen zunächst noch einige Vorarbeiten erledigt werden. Genauer gesagt muss der Build Agent so konfiguriert werden, dass er auch SharePoint-Projekte erstellen kann. Als SharePoint-Entwickler muss man immer einen lokalen SharePoint auf der Entwicklungsumgebung installiert haben, damit die SharePoint-spezifischen Elemente referenziert werden können und die Interaktion mit dem SharePoint Root (%CommonProgramFiles%Microsoft SharedWeb Server Extensions14) geschehen kann. In Visual Studio 2010 müssen darüber hinaus die SharePoint Tools for Visual Studio installiert sein, damit SharePoint-eigene MSBuild Targets auf der Maschine installiert werden. Glücklicherweise benötigt der BuildAgent für SharePoint nicht alle Komponenten.

Auf den Seiten des MSDN steht ein guter Leitfaden zur Verfügung, mit dessen Hilfe man einen SharePoint BuildAgent konfigurieren kann [1]. Wer wie ich ein PowerShell-Anhänger ist, kann sich allerdings auch das PowerShell Script des Visual Studio SharePoint Developer Tools Teams unter [2] anschauen und zum automatisierten Vorbereiten des Build Agents nutzen.

Automatisiertes Erstellen von WSPs

Ein manifestiertes Element des LifeCycles von SharePoint-basierten Anwendungen ist die WSP. Die WSP stellt das standardisierte Deployment-Medium eines SharePoint-Projektes dar und kann von jeder SharePoint-Installation verarbeitet werden. Daher ist es wichtig, dass bei einem serverseitigen Build auch die WSP-Datei(en) für die SharePoint-Lösungen erstellt werden. In jeder Build-Definition kann man über den Tab PROCESS eigene MSBuild-Argumente angeben. Diese Option kann man einfach nutzen, um die MSBuild Tools for SharePoint so anzusteuern, dass diese die gewünschten WSP(s) automatisch erstellen. Abbildung 7 zeigt die Verwendung benötigter MSBuild-Parameter IsPackaging in der Build-Definition.

Abb. 7: MSBuild-Parameter
Abb. 7: MSBuild-Parameter „IsPackaging“
Integration von externen Tools

Etwas mehr ins Detail geht dann schon die Integration von externen Tools. Als Beispiel wird der kostenlos verfügbare SPDisposeChecker in einen TFS 2010 Build integriert. Der SPDisposeChecker durchsucht eine angegebene Assembly nach möglichen Memory Leaks, die auf die nicht korrekte Verwendung von SPWeb und SPSite zurückzuführen sind. Um ein Werkzeug wie den SPDisposeChecker in TeamBuild integrieren zu können, muss der Build-Workflow angepasst und das gewünschte Tool auf dem BuildAgent zugreifbar gemacht werden. Der BuildAgent ist relativ schnell durch die Installation des Tools vorbereitet, und es kann sich dem Build-Workflow gewidmet werden. Hierbei empfiehlt es sich, eine Kopie des vorhandenen Build-Workflows zu erstellen und diese Kopie zu bearbeiten. Visual Studio stellt dem Anwender hierzu einen Dialog bereit, der diesen Arbeitsschritt etwas abstrahiert (Abb. 8).

Abb. 8: Erstellung einer Kopie eines vorhandenen Build-Workflows
Abb. 8: Erstellung einer Kopie eines vorhandenen Build-Workflows

Die Anpassungen des Build-Workflows werden im Workflow Designer von Visual Studio durchgeführt. Hierbei konzentriert sich die Anpassung auf den Teilprozess Run On Agent. Etwas genauer ausgedrückt, werden der Aufruf und die Verarbeitung des SPDisposeCheckers zwischen dem Kompiliervorgang und der Ausführung der Unit Tests integriert. Damit die Ausführung des SPDisposeCheckers bequem außerhalb des Build-Workflows gesteuert werden kann, empfiehlt es sich jedoch – wie in Abbildung 9 zu sehen ist – ein Workflow-Argument hinzuzufügen. Über die Metadata Collection kann die Einstellung auch benutzerfreundlich beschrieben und zusammen mit anderen Einstellungen gruppiert werden.

Abb. 9: Hinzufügen eines Workflow-Arguments
Abb. 9: Hinzufügen eines Workflow-Arguments

Die Anpassung des Build-Workflows ist in den meisten Fällen die Aneinanderreihung von existierenden Workflow Activities. Die eigentliche Kernaufgabe wird wie in diesem Beispiel von einem externen Programm durchgeführt. Um ein externes Programm zu starten, kann man die InvokeProcess Activity verwenden. Damit das Ergebnis der Prüfung gespeichert werden kann, muss zunächst noch eine Variable vom Typ int32 erstellt werden – hier SPDisposeCheckerOutput.

In Tabelle 1 sind die Konfigurationseinstellungen für die InvokeProcess Activity zu finden. Wie eine sinnvolle Integration der Activity in den gesamten Build-Workflow aussehen könnte, sieht man in Abbildung 10.

Parameter Wert
FileName „C:Program Files (x86)MicrosoftSharePoint Dispose CheckSPDisposeCheck.exe“
Arguments String.Format(„““{0}“““, outputDirectory)
Result SPDisposeCheckerOutput

Neben dem Dateinamen ist der Argumentsparameter der wichtigste. Hier wird dem SPDisposeChecker signalisiert, dass der komplette Output validiert werden soll. Im Output Directory befinden sich die kompilierten Sources, daher ist es auch wichtig, dass der SPDisposeChecker erst nach dem Kompilierungsvorgang läuft. Wie man Abbildung 10 entnehmen kann, wird auch der „Error Output“ – also der mögliche Fehlertext, der auf die Konsole geschrieben wird – direkt in das Buildlog geschrieben. Hierzu wird die von TFS bereitgestellte WriteBuildError Activity genutzt.

Abb. 10:
Abb. 10: „Error Output“ wird ins Buildlog geschrieben

Der SPDisposeChecker gibt als Ergebnis eine 0 zurück, wenn keine Regelverletzungen gefunden wurden, oder den jeweiligen Zahlenwert, der die Anzahl der Regelverletzungen widerspiegelt. Durch die Verwendung einer Standard-If-Activity kann auch dieses Resultat einfach interpretiert und der Build-Vorgang dementsprechend abgebrochen bzw. fortgesetzt werden.

Natürlich gibt es noch viele weitere Tools oder Add-ons, die im SharePoint-Build-Kontext Sinn machen. Zurzeit stellt der Autor unter [3] eine Sammlung von kleinen Webcasts kostenlos zur Verfügung, mit deren Hilfe man sehen kann, wie auch komplexere Build-Szenarien mit Team Foundation Server TeamBuild gehandhabt werden.

Fazit

Serverseitige Builds sind in SharePoint-Projekten, genau wie in allen anderen, eine Pflicht. Durch das konsequente Neukompilieren aller Bestandteile einer Lösung wird unmittelbar die Integrationsfähigkeit der neuesten Codefragmente geprüft. Alle Entwickler haben dadurch auch direkten Zugriff auf die Ergebnisse des hoffentlich erfolgreichen Builds. Aus Sicht des gesamten Teams bieten serverseitige Builds definitiv ein weiteres Quality Gate, durch das die Qualität des gesamten Projekts stabilisiert wird. In der aktuellsten Version bietet der TFS hierbei die perfekte Integration von automatisierten Builds in die ALM-Features.

Thorsten Hans ist Softwareentwickler aus Leidenschaft. Neben der Entwicklung von SharePoint und .NET-basierten Lösungen beschäftigt er sich mit dynamischen Sprachen. Thorsten wurde 2011 als SharePoint MVP für die Dienste in der Community ausgezeichnet und ist mehrfach als MCPD und MCTS zertifiziert. Sie erreichen ihn über E-Mail unter thorsten.hans@gmail.com oder über seinem Blog www.dotnet-rocks.de. Einige seiner Ideen finden sich auch auf seinem öffentlichen GitHub-Profil unter www.github.com/ThorstenHan.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -