Mit dem Team Foundation Server 2010

Automatisierte Builds für SharePoint
Kommentare

Continuous Integration, das fortlaufende, vollständige Neukompilieren eines gesamten Softwareprojekts, ist wohl eines der besten und wichtigsten Bestandteile im Prozess der Softwareentwicklung. Der Artikel zeigt, was Sie benötigen und wie Sie automatisierte Builds auch in der SharePoint-Entwicklung einsetzen können.

SharePoint wird als Anwendungsplattform immer beliebter, und nahezu jedes Unternehm3+en setzt in verschiedenen Anwendungsbereichen auf die Zusammenarbeitsplattform von Microsoft. Diese Beliebtheit führt auch dazu, dass Entwicklungsprojekte im SharePoint-Umfeld immer größer werden und mehrere Softwareentwickler (oder gar mehrere Entwicklungsteams) in Projekten zusammenarbeiten und interagieren müssen. Kurzum, auch im SharePoint-Kontext werden Application-LifeCycle-Management-Features (ALM) immer wichtiger.

Product Owner müssen einen direkten Überblick über den Entwicklungsstand erhalten können. Burndown-Charts werden benötigt, um die Teamperformance frühzeitig zu prüfen. Der Tester möchte direkten Zugriff auf die aktuellsten Binaries, um neue Features testen zu können. Schlussendlich braucht jeder Entwickler ein zeitnahes Feedback, das ihm signalisiert, ob sein Code nahtlos integriert werden kann. Natürlich ist es möglich, diese nahtlose Integration manuell sicherzustellen. Doch durch die Automatisierung dieses Prozesses kann eine enorme Zeitersparnis erzielt werden, um mögliche menschliche Fehler auszuschließen.

All diese Anforderungen werden von Microsofts Team Foundation Server (TFS) adressiert. Zwar wird der TFS oftmals als Serverkomponente von Visual Studio bezeichnet, doch mittlerweile ist TFS weit mehr. Dank des konsequenten Einsatzes von SharePoint bietet TFS eine Collaboration-Plattform auf Ebene des Projekts. Hier können sich Projektbeteiligte Informationen über den Status des Projekts verschaffen oder Diagramme wie den Burndown-Chart begutachten (Abb. 1).

Abb. 1: Burndown-Chart
Abb. 1: Burndown-Chart

In TFS 2010 steht auch erstmals eine neue Build-Infrastruktur, der TeamBuild 2010, zur Verfügung. Basierend auf Workflows der Workflow Foundation 4.0 können Softwareartefakte serverseitig kompiliert beziehungsweise erstellt werden. Abbildung 2 zeigt, wie sich der TeamBuild in die TFS-Topologie integriert.

Abb. 2: TeamBuild in der TFS-Topologie
Abb. 2: TeamBuild in der TFS-Topologie

Der BuildController übernimmt die Rolle des Dispatchers. Er überwacht die Build-Agents und selektiert entsprechend der Definition den BuildAgent für die Ausführung einer bestimmten Anfrage. Das Konzept der BuildController wurde im Zusammenhang mit den ProjectCollections erstmals in Version 2010 des TFS eingeführt. Ein BuildAgent hat den Anspruch, die vorhandenen Quellen unter Verwendung des minimalsten Toolings zu erstellen. Es dürfen nur die Komponenten auf dem BuildAgent verfügbar sein, die explizit zum Erstellungsprozess benötigt werden. Das Herz eines jeden serverseitigen Builds ist die so genannte Build-Definition. Hierbei handelt es sich um nichts anderes als die Konfiguration des Builds. Hier werden die zentralen Bestandteile des serverseitigen Builds beschrieben, Features aktiviert und deaktiviert und Konfigurationen für die einzelnen Teilschritte festgelegt.

TFS-Build-Definitionen

Im Team-Foundation-Server-Kontext werden Build-Definitionen verwendet, um den Build-Prozess zu skizzieren. Mit jeder Build-Definition werden folgende Fragen beantwortet:

  1. Wann wird ein Build ausgelöst?
  2. Was soll serverseitig kompiliert werden?
  3. Wie soll serverseitig kompiliert werden?
  4. Wo soll das Ergebnis publiziert werden?

Erstens: Wann wird ein Build ausgelöst?

Dank der integrierten Trigger kann man bei der Erstellung einer Build-Definition wählen, wann ein serverseitiger Build gestartet wird. TFS 2010 bietet dem Build-Administrator unterschiedliche Einstellungsmöglichkeiten zur Auswahl (Abb. 3). Auch der zuvor beschriebene Mechanismus der Continuous Integration wird OOB von TFS 2010 unterstützt und kann an dieser Stelle durch Aktivierung des Radiobuttons ausgewählt werden.

Abb. 3: Einstellungen bei der Erstellung einer Build-Definition
Abb. 3: Einstellungen bei der Erstellung einer Build-Definition

Eine im Hinblick auf die Qualitätssicherung noch bessere Alternative als Continuous Integration bietet der so genannte Gated Check-in. Beim Gated Check-in werden alle lokalen Änderungen zunächst in einer Sandbox (Shelveset) persistiert und nur dem Workspace des Build Agents verfügbar gemacht. Erst nach einem erfolgreichen serverseitigen Build werden die Changes in die SourceControl übertragen. Der Prozess des Gated Check-in läuft asynchron, was bedeutet, dass der Entwickler wie gewohnt eincheckt und Visual Studio den Entwickler dann nach dem Kompiliervorgang durch einen modalen Dialog über das Ergebnis des Builds informiert (Abb. 4).

Abb. 4: Dialog nach dem Check-in
Abb. 4: Dialog nach dem Check-in

Zweitens: Was soll serverseitig kompiliert werden?

Die Frage nach dem „Was“ wird in einer Build-Definition durch die Auswahl der zu kompilierenden Solutions und/oder Projekte in Verbindung mit den zu erstellenden Konfigurationen (Debug/Release/…) beantwortet.

Drittens: Wie soll serverseitig kompiliert werden?

Das „Wie“ ist wohl die spannendste Frage im Build. Um auf die individuellen Bedürfnisse einzugehen und den Build-Administratoren eine komfortablere Art des Customizings zu bieten, setzt der Team Foundation Server 2010 erstmals auf einen auf Worfklow Foundation 4 basierenden Build-Prozess. Dieser Prozess kann nach Belieben an die eigenen Bedürfnisse angepasst und erweitert werden. Entsprechend der Standardeinstellung muss lediglich der gewünschte Build-Agent angegeben bzw. durch den Tag-Filter die Menge an verfügbaren Build-Agents definiert werden (Abb. 5).

Abb. 5: Anpassung des Build-Prozesses
Abb. 5: Anpassung des Build-Prozesses

Viertens: Wo soll das Ergebnis publiziert werden?

Bei jedem Build hat man die Möglichkeit, die erstellten Artefakte auf eine Freigabe (Drop) hin veröffentlichen zu können. Die Angabe einer Drop ist zwingend erforderlich, damit die Build-Definition im TFS publiziert werden kann. Bei Bedarf kann der Kopiervorgang der Binaries auf die Drop jedoch auch deaktiviert werden (Abb. 6).

Abb. 6: Deaktivierung des Kopiervorgangs der Binaries
Abb. 6: Deaktivierung des Kopiervorgangs der Binaries
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -