MSDN Magazin > Home > Ausgaben > 2008 > November >  Team System: Team Build 2008
Team System
Team Build 2008
Brian A. Randell
Codedownload verfügbar unter: MSDN Code Gallery (165 KB)
Code online durchsuchen
Bei Team Foundation Server (TFS) geht es um Teams. TFS kann zwar von einem Team mit nur einem Mitglied verwendet werden, aber es geht dabei im Wesentlichen um die Zusammenarbeit mit anderen Menschen an Ihren Entwicklungsprojekten.
Die Buildautomatisierung lässt sich nicht durch F5 erzielen. Bei der Buildautomatisierung geht es um Sammeln, Zusammenstellen, Überprüfen und Überwachen. Die Idee ist die, dass Sie alle Artefakte sammeln, aus denen Ihre Lösung besteht, und diese auf Grundlage eines klar definierten Integrationsplans zusammenstellen. Die Kompilierung ist eine typische Aufgabe, die in der Zusammenstellungsphase definiert wird. Sie verwenden verschiedene Typen automatisierter Tests, oft auch Buildüberprüfungstests (Build Verification Test, BVT) oder Feuerproben genannt, um dann die gesamte Arbeit Ihres Teams zu überprüfen.
Abschließend führen Sie eine Art von Überwachung durch, um die Gesamtqualität des Builds zu bewerten. In der Überwachungsphase werden Daten bereitgestellt, mit denen sich schwierige Fragen beantworten lassen. Stellt beispielsweise der vorliegende Build jetzt schon ein Produkt dar? Ist das Produkt von hoher Qualität? Liegen Regressionen vor? Wird der Terminplan eingehalten? Durch die Buildüberwachung wird es zu einer alltäglichen Aufgabe, Ihrem Team auf den Puls zu fühlen.
In diesem Artikel erhalten Sie eine Einführung in Visual Studio 2008 Team Foundation Server Build (Team Build) und werden durch den Prozess des Erstellens und Ausführens eines Team Build geleitet. Außerdem wird die jetzt verfügbare, verwaltete API vorgeführt, mit der Sie anhand von Team Build 2008 programmieren können.

Info zu Team Build
Team Build ist ein zentrales Feature von TFS 2008. Team Build wurde von Microsoft als äußerst wirksames Buildautomatisierungstool entworfen. Dadurch erhält Ihr Team sozusagen eine F5-Erfahrung. In einer typischen Umgebung installieren Sie Team Build auf einem eigenen dedizierten Server (doch bei einem sehr kleinen Team oder einem knappen Budget können Sie Team Build auch auf dem TFS-Computer installieren).
Im Unterschied zu anderen Teilen von TFS war die Veröffentlichung von Team Build 2008 eine wichtige Aktualisierung. Mit der 2005 veröffentlichten Version hat Microsoft ein gutes Buildautomatisierungsprodukt bereitgestellt. Unter Verwendung von MS-Build als Modul unterstützte Team Build 2005 erwartungsgemäß viele der zentralen Automatisierungsfeatures: Versionskontrolle, Kompilierung, mehrere Buildtypen, Komponententests, statische Analyse und Codeabdeckung.
Außerdem enthielt das Produkt hervorragende Berichterstattungsfeatures, einschließlich Buildberichte und Datenupdates zum TFS-Data Warehouse, um eine Verlaufstrendanalyse zu unterstützen. Die Veröffentlichung von Team Build in 2005 unterstützte auch mehrere Buildcomputer, Buildbenachrichtigungen sowie die Möglichkeit, einen Build von der Befehlszeile oder durch die Team Explorer-Benutzeroberfläche zu starten.
In Team Build 2008 hat Microsoft nicht nur oberflächliche Änderungen vorgenommen. Zu den wichtigsten Verbesserungen gehören die kontinuierliche Integrationsunterstützung, Buildwarteschlangen, geplante Builds durch Team Explorer und ein verwaltetes Objektmodell. Außerdem wurde die Build-Agent-Definition von der Builddefinition getrennt, eine Benutzeroberfläche zum Bearbeiten der Builddefinition erstellt und bessere Buildverwaltungstools hinzugefügt.
Kombiniert mit dem stabilen Set von Team Build 2005-Features stellt Team Build 2008 eine überzeugende Buildautomatisierungslösung dar. Außerdem können Sie aufgrund der Tatsache, dass Microsoft weiterhin die Abwärtskompatibilität unterstützt, eine bestehende TFS-Installation und vorhandene Team Build-Server aktualisieren, selbst wenn Ihr Entwicklungsteam immer noch Visual Studio 2005 verwendet.

Erstellen eines Team Build
Für die Verwendung von Team Build ist natürlich eine TFS-Installation erforderlich, und zwar entweder eine Einzelserver- oder eine Zwei-Server-Konfiguration. Team Build muss installiert und der Buildserver korrekt konfiguriert sein. Die Details sind im kürzlich aktualisierten Team Foundation-Installationshandbuch enthalten. Abschließend benötigen Sie ein Teamprojekt mit Code, das in das Repository der Versionskontrolle eingecheckt ist.
Öffnen Sie in Visual Studio 2008, auf dem ein Team Foundation Server-Client installiert ist, das Team Explorer-Fenster, in dem Ihr Teamprojekt geladen ist. In diesem Beispiel wird angenommen, dass Sie mit der MSF Agile-Vorlage ein Teamprojekt namens „MSDNMag“ erstellt haben. (Wenn Sie dies nachvollziehen wollen, laden Sie den Code zu diesem Artikel sowie das Abbild für Team System 2008 TFS und Team Suite Virtual PC herunter.) In diesem Beispiel wird ein benutzerdefinierter Arbeitsbereich namens „MSDNMag“ verwendet, wobei im Virtual PC-Abbild der Stamm dem Ordner „C:\Work“ zugeordnet wird.
Nun können Sie den MSDNMag-Teamprojektknoten im Team Explorer-Fenster erweitern und den Ordner „Builds“ suchen. Wenn Sie mit der rechten Maustaste auf den Ordner „Builds“ klicken, werden eine Reihe von Optionen angezeigt. In diesem Kontext ist der Befehl „Neue Builddefinition“ von Interesse. Nach Auswahl des Befehls wird das Dialogfeld „Builddefinition“ angezeigt (siehe Abbildung 1).
Abbildung 1 Das leere Dialogfeld „Builddefinition“ (zum Vergrößern auf das Bild klicken)
Im Unterschied zum Assistenten in Team Build 2005 können Sie zu diesem Dialog zurückkehren, wenn Sie eine Builddefinition bearbeiten müssen. Zuerst stellen Sie einen Buildnamen bereit, z. B. „SimpleBuildExplorer-OnDemand“. Außerdem können Sie den Build offline bearbeiten, indem Sie die Option „Diese Builddefinition deaktivieren“ aktivieren.
Beim Erstellen eines neuen Build müssen Sie einen Builddefinitionsnamen, eine Team Build-Projektdatei, den Build-Agent und den Ablagespeicherort angeben. Die zweite Option, „Arbeitsbereich“, ist meiner Meinung nach äußerst wichtig.
In Team Build 2005 genügte es, wenn Sie wussten, dass es die Arbeitsbereich-Option gibt. Die Implementierungsinformationen haben sich geändert, aber der Zweck ist der gleiche: Die von Team Build beim Buildprozessschritt zum Abrufen von Quellen heruntergeladenen Artefakte sollen eingeschränkt werden. In Team Build 2005 mussten Sie eine Datei namens „WorkspaceMapping.xml“ ändern. In Team Build 2008 verwenden Sie eine grafische Benutzeroberfläche, die derjenigen im Dialogfeld für die Arbeitsbereichzuordnung zur Versionskontrolle ähnelt (siehe Abbildung 2).
Abbildung 2 Arbeitsbereichsseite des Dialogfelds „Builddefinition“ (zum Vergrößern auf das Bild klicken)
Im Arbeitsbereich können Sie definieren, welche Abschnitte des Quellcoderepositorys als Teil des Builds verwendet werden sollen. Standardmäßig ordnet Team Build den Stamm des Teamprojekts dem vom Build verwendeten Quelldownloadpfad zu (dies lässt sich beim Zuordnen des Build-Agents, der den Build mit der Builddefinition ausführt, steuern). Wenn Sie diese Einstellung nicht anpassen, ruft Team Build jedes Mal, wenn Sie einen Build ausführen, die aktuellsten Informationen vom Stamm ab. Das ist kein Problem, wenn Sie Demos oder Tests ausführen, doch nach sechs Monaten Arbeit und mehreren Verzweigungen in Ihrem Teamprojekt ist dies nicht die beste Möglichkeit, einen Build auszuführen.
Obwohl das Demoszenario hier nur eine Visual Studio-Lösung enthält, sollten Sie die Zuordnung nach wie vor anpassen. Wenn Sie auf das erste Element in der Spalte „Quellcodeverwaltungsordner“ klicken, können Sie entweder einen eingeschränkten Pfad eingeben oder das Dialogfeld „Ordner suchen“ verwenden. Für dieses Beispiel wurde der Quellcodeverwaltungsordner „$/MSDNMag/Main/src/TeamSystem/C08“ festgelegt.
Genauso wie im Dialogfeld, das für die Arbeitsbereichzuordnung zur Versionskontrolle verwendet wird, können Sie mehr als eine Ordnerzuordnung definieren. Die Variable „$(SourceDir)“ ist eine Umgebungsvariable, die Team Build auf das Buildverzeichnis erweitert, das für den Build-Agent im Dialogfeld „Eigenschaften von Build-Agent“ angegeben wird. Im Allgemeinen empfiehlt sich die Verwendung von „$(SourceDir)“, damit die Pfade relativ sind. Team Build erzwingt die Verwendung dieser Variablen jedoch nicht. In diesem Beispiel wird die Variable unverändert beibehalten.
Abschließend können Sie bei einem vorhandenen Arbeitsbereich, in dem alle Zuordnungen nach Bedarf konfiguriert sind, die Option „Vorhandenen Arbeitsbereich kopieren“ verwenden, um den Teil der Zuordnung zu kopieren, der den Versionskontrollordner enthält, wodurch Sie Zeit einsparen.
Wenn Sie die Arbeitsbereichseinstellungen definiert haben, müssen Sie eine Buildprojektdatei definieren. Wenn Sie auf die Option „Projektdatei“ klicken, haben Sie die Option, den Pfad für eine vorhandene TFSBuild.proj-Datei bereitzustellen, die sich bereits unter der Versionskontrolle befindet. TFSBuild.proj ist eine XML-Datei, die in der 2005-Version alle Buildkonfigurationsdaten enthielt und die Datei war, die zur Verbesserung des eigentlichen Buildprozesses angepasst wurde. In Team Build 2008 wird diese Datei weiterhin zur Buildanpassung verwendet, doch die meisten Daten zur Builddefinition sind in den TFS-Datenbanken gespeichert. Wenn noch keine Datei vorliegt, klicken Sie auf die Schaltfläche „Erstellen“, und erstellen Sie mithilfe eines einfachen Assistenten eine Datei.
Eine große Änderung in Team Build 2008 ist die, dass Sie jetzt angeben können, wo Sie die TFSBuild.proj-Datei speichern möchten. In Team Build 2005 hatte Microsoft den Pfad zu einem spezifischen Speicherort im Repository für die Versionskontrolle hartcodiert. Standardmäßig gibt das Dialogfeld „Team Build 2008“ einen Team Build 2005-kompatiblen Pfad in Form von „%TeamProjectName%/TeamBuildTypes/%BuildDefinitionName%“ an.
Für das aktuelle Beispiel sehen Sie „$/MSDNMag/TeamBuildTypes/SimpleBuildExplorer-OnDemand“ als den vorgeschlagenen Ordner für die Versionskontrolle. Die Möglichkeit, den Pfad zu ändern, hat den großen Vorteil, dass Sie jetzt die TFSBuild.proj-Datei mit anderen Artefakten verzweigen können. Akzeptieren Sie für dieses Beispiel den Standardpfad, und klicken Sie auf die Schaltfläche „Erstellen“.
Wenn Sie auf die Schaltfläche „Erstellen“ klicken, zeigt Team Build einen Assistenten an. Der Assistent ist einer der wenigen Überreste der Benutzeroberfläche von Team Build 2005. Auf der ersten Seite werden Sie aufgefordert, die zu erstellenden Visual Studio-Lösungen auszuwählen. Der Assistent filtert die Liste, sodass nur die Lösungen angezeigt werden, die in Relation zu Ihrer Arbeitsbereichzuordnung verfügbar sind. Wenn Sie die Standardarbeitsbereichzuordnung nicht ändern, sehen Sie alle Lösungen in Ihrem Teamprojekt. Wählen Sie die angezeigte einzelne Lösung aus, und klicken Sie auf „Weiter“.
Auf der zweiten Seite des Assistenten können Sie auswählen, welche Art von Visual Studio-Konfigurationen Sie erstellen möchten. Der Assistent macht nur Debug- und Releasekonfigurationen verfügbar, Sie können aber benutzerdefinierte Konfigurationen eingeben. Dasselbe gilt für die Plattform. Akzeptieren Sie die Standardeinstellungen, und klicken Sie auf „Weiter“.
Auf der abschließenden Seite des Assistenten können Sie die Ausführung von Tests und statischen Analysen steuern. Auf dem Build-Agent-Computer muss VSTS installiert sein, damit die Testausführung und statische Analyse funktionieren. Wie unter Team Build 2005 können Sie eine Testmetadatendatei auswählen und aus dieser dann beliebige Testlisten auswählen, die eine unbeaufsichtigte Ausführung unterstützen. Sie können jedoch abwechselnd auswählen, dass Team Build die Ausgabeassemblys automatisch auf MSTest-kompatible Tests überprüft und sie ohne Testliste ausführt. Sie können auswählen, dass Team Build statische Analysen ausführt, wenn Sie dies in einem oder mehreren Visual Studio-Projekten aktiviert haben. Die Beispiellösung für diesen Artikel enthält keine Tests oder statische Analyse. Klicken Sie deshalb auf „Fertig stellen“, um den Assistenten abzuschließen und die TFSBuild.proj-Datei zu erstellen.
Jetzt müssen Sie nur noch die Build-Standardwerte eingeben. Sehen Sie sich als Erstes die Datenaufbewahrungsrichtlinie und die Triggereinstellungen an. Es stellt eine große Verbesserung gegenüber Team Build 2005 dar, dass Sie in Team Build 2008 jetzt eine Konfiguration anhand der Datenaufbewahrungsrichtlinie der Builddefinition vornehmen können (siehe Abbildung 3). Basierend auf dem Ergebnis eines bestimmten Builds können Sie steuern, wie viele Buildergebnisse Team Build beibehält.
Abbildung 3 Steuern einer Builddefinitions-Datenaufbewahrungsrichtlinie (zum Vergrößern auf das Bild klicken)
Nachdem ein Build abgeschlossen ist, können Sie ein Buildergebnis markieren, damit es von Team Build unabhängig von der Aufbewahrungsrichtlinie beibehalten wird. Beachten Sie bei diesem Beispiel, dass die Standardeinstellung für die Aufbewahrungsrichtlinie beibehalten werden sollte.
Wenn Sie in Team Build 2008 auf die Option „Trigger“ klicken, werden Builds, genau wie bei Team Build 2005, bei Aufforderung ausgeführt. Sie werden jedoch bemerken, dass Team Build jetzt auch kontinuierliche Integration (Continuous Integration, CI) unterstützt. (Weitere Informationen zu CI finden Sie im Artikel vom März 2008 Neudefinition Ihres Buildprozesses mit kontinuierlicher Integration.) Dies bedeutet, dass ein Build in die Warteschlange eingereiht wird, wenn eine Änderung zu einer Datei eingecheckt wird, deren Zuordnung durch Arbeitsbereichzuordnungen einer Builddefinition erfolgt. Im Dialog wird dies über die Option „Build für jeden Eincheckvorgang (mehr Builds)“ verfügbar gemacht.
Eine zweite Option namens „Eincheckvorgänge sammeln, bis der vorherige Build abgeschlossen ist (weniger Builds)“ bietet eine verzögerte Form von CI. Abschließend ermöglicht die letzte Option das Konfigurieren eines geplanten Build (siehe Abbildung 4).
Abbildung 4 Konfigurieren von Team Build für die Ausführung nach einem Zeitplan (zum Vergrößern auf das Bild klicken)
Sie sollten den Triggersatz auf der Standardeinstellung „Eincheckvorgänge lösen keinen neuen Build aus“ belassen und die Option „Build-Standardwerte“ auswählen. Verwenden Sie die Build-Standardwerte für die Angabe des zu verwendenden Build-Agents und des Ablagespeicherorts für die Buildausgabe. Der Ablagespeicherort wird durch einen UNC-Pfad angegeben. Wenn Sie das von Microsoft bereitgestellte Virtual PC-Abbild verwenden, können Sie „\\localhost\Drops\MSDNMag\SimpleBuildExplorer-OnDemand“ eingeben. Es muss lediglich die Freigabe vorhanden sein. Team Build erstellt bei Bedarf zusätzliche Unterordner. Team Build erstellt unter Verwendung der Buildnummer einen Ordner unter diesem Pfad.
Beim Erstellen der Freigabe müssen Sie sicherstellen, dass die korrekten Berechtigungen zugewiesen werden. Die Mindestanforderungen für Team Build- und TFS-Dienstkonten sind uneingeschränkte Zugriffsberechtigungen für die Freigabe. Außerdem müssen Sie allen Personen, die Testergebnisse für den Build veröffentlichen sollen, Schreibberechtigungen zuweisen. Sie sollten den Personen, die abgeschlossene Builds herunterladen müssen, Leseberechtigungen zuweisen.
Angenommen, Sie haben die Freigabe konfiguriert und müssen als Nächstens einen Build-Agent angeben. Wenn Sie bereits einen Build-Agent definiert haben, können Sie ihn im Kombinationsfeld auswählen. Wenn dies nicht der Fall ist, können Sie durch Klicken auf die Schaltfläche „Neu“ das Dialogfeld „Eigenschaften von Build-Agent“ öffnen. Für dieses Beispiel muss ein neuer Agent definiert werden. Klicken Sie deshalb auf „Neu“.

Erstellen eines Build-Agents
Im Unterschied zu Team Build 2005 sind die Build-Agents in Team Build 2008 von Builddefinitionen unabhängig. Ein einmal definierter Agent kann problemlos wiederverwendet werden. Im Dialogfeld „Eigenschaften von Build-Agent“ können Sie alle wichtigen Eigenschaften für den Agent definieren. Sie stellen zunächst einen Anzeigenamen und eine optionale Beschreibung bereit. Anschließend geben Sie den Computernamen in Form eines NetBIOS- oder DNS-Namens an. Der Anzeigename und der Computername können völlig verschieden sein. Bei Verwendung von SSL kann diese Option festgelegt werden.
Eine wichtige Einstellung ist das Arbeitsverzeichnis. Standardmäßig wird ein Pfad in Form von „$(Temp)\$(BuildDefinitionPath)“ verwendet. Das funktioniert zwar für viele Builds, kann aber aufgrund des gefürchteten MAX_PATH-Problems Schwierigkeiten bereiten. Der Ordnerpfad für „$Temp“ auf einem Windows Server 2003-Computer lautet „%SystemDrive%\Dokumente und Einstellungen\<Build-Agent-Dienstkonto>\Lokale Einstellungen\Temp“. Das sind zu viele Zeichen. Ich empfehle in der Regel, dass der Pfad etwas abgekürzt wird, vor allem beim Erstellen von Database Professional-Builds. Ändern Sie für dieses Beispiel das Arbeitsverzeichnis zu „C:\Builds\$(BuildDefinitionPath)“.
Abschließend können Sie den Status des Agents kontrollieren. Dies ist vor allem bei der Wartung nützlich. Darüber hinaus ändert TFS den Status eines Agents auf unerreichbar, wenn kein Build-Agent kontaktiert werden kann, und verhindert dadurch die Verwendung des Agents, bis ein Administrator die Einstellung ändert. Lassen Sie die Einstellung auf „Aktiviert“, und klicken Sie auf „OK“, um das abgeschlossene Dialogfeld „Eigenschaften von Build-Agent“ zu schließen (siehe Abbildung 5). Im Dialogfeld „Builddefinition“ sehen Sie nun, dass alle Warnsymbole aufgelöst sind und Sie auf „OK“ klicken können, um die Builddefinition abzuschließen.
Abbildung 5 Abgeschlossenes Dialogfeld „Eigenschaften von Build-Agent“
Im Team Explorer-Fenster wird jetzt unter dem Buildordner Ihre Builddefinition aufgeführt. Wenn Sie mit der rechten Maustaste darauf klicken, wird eine Option namens „Builddefinition bearbeiten“ angezeigt, über die Sie das gleiche Builddefinitionsdialogfeld aufrufen können, das Sie gerade verwendet haben. Außerdem können Sie mit der Option „Neuen Build in Warteschlange“ einen neuen Build einreihen.
Im Unterschied zu Team Build 2005 unterstützt Team Build 2008 jetzt das Einreihen von Builds in die Warteschlange, ein Feature, das für eine angemessene Unterstützung der kontinuierlichen Integration durch Microsoft erforderlich ist. Wenn Sie diese Option auswählen, wird das Dialogfeld „Build zu Warteschlange hinzufügen“ geöffnet (siehe Abbildung 6), und Sie können einige Optionen anpassen. Erstens kann bei Bedarf der Standard-Build-Agent problemlos geändert werden. Zweitens ist es möglich, den Ablagespeicherort anzupassen. Außerdem können Sie dafür sorgen, dass ein bestimmter Build vorrangig behandelt wird, indem Sie die Option „Priorität in Warteschlange“ anpassen. Abschließend können Sie MSBuild-Befehlszeilenargumente übergeben, falls der Benutzer über die Berechtigung zur Verwaltung von Builds verfügt.
Abbildung 6 Dialogfeld „Build zu Warteschlange hinzufügen“

Ausführen eines Team Build
Klicken Sie auf „Warteschlange“, um den Build zu starten. Wenn Sie darauf klicken, wird das aktualisierte Build Explorer-Fenster geöffnet. Es besteht hauptsächlich aus zwei Registerkarten. Die eine Registerkarte zeigt standardmäßig alle Builds an, die unabhängig vom Agent oder Status in der Warteschlange eingereiht sind. Mit Kombinationsfeldern können Sie anpassen, welche Builds im Build Explorer-Fenster auf Grundlage der Builddefinition, des Buildstatus oder des Build-Agents angezeigt werden.
Die andere Registerkarte zeigt die abgeschlossenen Builds an und unterstützt die gleichen Filtervorgänge. Wenn Sie den Build starten, können Sie darauf doppelklicken, um einen Live-Buildbericht anzuzeigen. Dieser Bericht wird beim Durchlaufen des Buildprozesses von Team Build in Echtzeit aktualisiert.
Beim Ausführen eines Team Build finden eine Reihe von Aktionen statt. Nachdem TFS den Build von der Warteschlange startet, wird der Build-Agent für die Ausführung des Builds vorbereitet. TFS erstellt eine Buildnummer, und der Build-Agent synchronisiert die Quellen mit dem in der Builddefinition angegebenen Speicherort. Der Agent kompiliert dann den Code und führt bei Bedarf eine Codeanalyse aus. Als Nächstes führt der Build-Agent die Tests aus. Anschließend führt der Agent eine Aufgabe aus, bei der alle zugeordneten Arbeitsaufgaben mit der Buildnummer aktualisiert werden.
Zum Beispiel enthält die Task-Arbeitsaufgabe aus der MSF Agile-Vorlage ein Dialogfeld für den Integrationsbuild, das von Team Build aktualisiert wird. Der Agent berechnet die Codeabdeckung (falls Tests konfiguriert wurden und als Teil des Builds ausgeführt werden sollen und die Codeabdeckung aktiviert ist) und legt alle Changesets zwischen dem letzten guten Build (Kompilierung erfolgreich) und dem aktuellen Build fest. Dann lädt der Agent eine Kopie der Dateien in die Ablagefreigabe hoch, veröffentlicht die Buildergebnisse an TFS, und TFS löst ein Buildabschlussereignis aus. Einzelheiten dazu finden Sie im Artikel vom Mai 2008 über TFS-Ereignisse.
Microsoft hat hinsichtlich Tests und Arbeitsaufgaben in Team Build 2008 zwei wichtige Änderungen vorgenommen hat. Die erste Änderung ist die, dass ein Build, der einen oder mehrere fehlgeschlagene Tests enthält, nicht als fehlgeschlagen eingestuft wird. Stattdessen wird ein Build mit einem oder mehreren fehlgeschlagenen Tests als „Teilweise Abgeschlossen“ und nicht wie in Team Build 2005 als „Fehlgeschlagen“ angezeigt. Die zweite Änderung betrifft Folgendes: In Team Build 2005 werden beim ersten Ausführen eines Builds alle Arbeitsaufgaben und Changesets für die Elemente aufgelistet, die im ersten Buildbericht seit Beginn des Teamprojekts erstellt wurden. In Team Build 2008 werden Arbeitsaufgaben erst dann angezeigt und aktualisiert, wenn ein Build zum ersten Mal erfolgreich ausgeführt wurde. Im nächsten Artikel dieser Rubrik wird untersucht, wie Sie diese Verhaltensweisen durch eine Buildanpassung ändern.

Programmieren von Team Build
Eine der hervorragenden Verbesserungen in Team Build 2008 ist die Erweiterung um eine verwaltete API. Die Assembly „Microsoft.TeamFoundation.Build.Client.dll“ ist die primär verwendete Assembly. Die Beispielanwendung für diesen Artikel verweist auf diese Assembly sowie die Assemblys „Microsoft.TeamFoundation.Client.dll“ und „Microsoft.TeamFoundation.VersionControl.Client.dll“.
Bei der Beispielanwendung handelt es sich um eine einfache Windows Forms-Anwendung, in der ein Teil der neuen API zum Einsatz kommt. Die Anwendung stellt eine Verbindung zu TFS her, zählt die Liste aller Teamprojekte auf und lädt sie in ein Struktursteuerelement. Unter jedem Teamprojekt werden Build-Agents und Builddefinitionsknoten hinzugefügt (siehe Abbildung 7).
Abbildung 7 Beispielanwendung (zum Vergrößern auf das Bild klicken)
Wenn Sie einen Knoten erweitern, wird Code im BeforeExpand-Ereignis von TreeNode ausgeführt. Die verfügbaren Build-Agents, Builddefinitionen oder abgeschlossenen Builds werden aufgezählt, je nachdem, welchen Knoten Sie erweitert haben. Außerdem hostet das Hauptformular ein Eigenschaftenrastersteuerelement. Wenn Sie einen Knoten mit einem Tagwert auswählen, der nicht null ist, lädt die Anwendung das Verweisobjekt in die SelectedObject-Eigenschaft des Eigenschaftenrasters. Abbildung 7 zeigt die Anwendung mit dem erweiterten MSDNMag-Teamprojekt und dem ausgewählten Haupt-Build-Agent.
Die Anwendung besteht hauptsächlich aus einfachem Enumerationscode. Es ist aber ein Feature vorhanden, das Microsoft in Team Explorer nicht aufgenommen hat. Wenn Sie einen Build-Agent definieren, passt TFS den Build-Agent an das entsprechende Teamprojekt an. Ich habe aber festgestellt, dass viele Organisationen nur über einen oder zwei Build-Agents verfügen. Diese Organisationen müssen also den Build-Agent mehrfach neu erstellen. Wenn Sie in der Beispielanwendung mit der rechten Maustaste auf eine Build-Agent-Instanz klicken, wird ein Kontextmenü und ein Befehl für den Kopiervorgang angezeigt (siehe Abbildung 8).
Abbildung 8 Befehl für den Kopiervorgang
Durch die Auswahl dieser Option wird ein Dialogfeld geöffnet, in dem Sie das gewünschte Teamprojekt auswählen können, in das die Build-Agent-Definition kopiert werden soll. Der wirklich interessante Code ist im Ereignishandler „CopyAgentToToolStripMenuItem_Click“ enthalten, den Sie in Abbildung 9 sehen.
Private Sub CopyAgentToToolStripMenuItem_Click( _
  ByVal sender As System.Object, _
  ByVal e As System.EventArgs) _
  Handles CopyAgentToToolStripMenuItem.Click

  Dim current As TreeNode = tv.SelectedNode
  Dim ba As IBuildAgent = _
    TryCast(current.Tag, IBuildAgent)

  If ba Is Nothing Then Exit Sub

  Dim parentProject As String = ba.TeamProject

  Using frm As New frmPickProject
    frm.cboProjects.DataSource = _
      (From item In teamProjectNames _
       Where item <> parentProject _
       Select item).ToArray()

    If frm.ShowDialog(Me) = Windows.Forms.DialogResult.OK Then
      Dim teamProjectName As String = _
        frm.cboProjects.SelectedItem.ToString()

      Dim existingAgent = _
        (From item As IBuildAgent In _
         m_bs.QueryBuildAgents(teamProjectName) _
         Where item.Name = ba.Name).SingleOrDefault

      If existingAgent Is Nothing Then
        Dim newBuildAgent As IBuildAgent = _
        ba.CopyTo(teamProjectName)
        newBuildAgent.Save()

        MessageBox.Show(newBuildAgent.Name & " copied.")
      Else
        MessageBox.Show(existingAgent.Name & " already exists.")
      End If
    End If
  End Using
End Sub
Unter der Voraussetzung, dass der ausgewählte Knoten einen Tag für einen IBuildAgent-Verweis enthält, zeigt der Code das frmPickProject-Formular an. Dieses Formular enthält ein Kombinationsfeld, in dem alle verfügbaren Teamprojekte außer dem Teamprojekt des aktuellen Build-Agents anzeigt werden.
Der Code füllt die Datenquelle des Kombinationsfelds durch Ausführen einer LINQ-Abfrage anhand des Zeichenfolgenarrays aller Teamprojektnamen auf, die gesammelt werden, wenn der Stamm der Strukturansicht zum ersten Mal erweitert wird. Wenn Sie ein Teamprojekt auswählen und im Projektauswahlformular auf „OK“ klicken, führt der Code eine LINQ-Abfrage aus, um zu überprüfen, ob das Zielteamprojekt nicht bereits einen Build-Agent mit dem gleichen Namen enthält. Wenn ein Build-Agent gefunden wird, wird eine Nachricht angezeigt. Wenn keiner gefunden wird, wird die Build-Agent-Definition kopiert.
Interessant ist insbesondere, dass Microsoft eine CopyTo-Methode bietet. Als ich diesen Code zum ersten Mal ausarbeitete, hatte ich eine Pro-Eigenschaft-Kopie anhand einer neuen IBuildAgent-Instanz geplant. Es sieht so aus, als ob Microsoft die API integriert hat, ohne die Benutzeroberfläche entsprechend zu erweitern.
Aus diesem Artikel wird deutlich, dass es sich bei Team Build 2008 um ein äußerst wirksames Buildprodukt handelt. Wenn Sie bereits Team Build 2005 verwenden, erhalten Sie durch das Aktualisieren auf Team Build 2008 unzählige Vorteile. Im nächsten Artikel wird die Buildanpassung ausführlich erörtert und aufgezeigt, wie Sie mit Ihren Builds nicht nur eine Lösung kompilieren, sondern auch an Testumgebungen bereitstellen können und vieles mehr.
Ich möchte Ken Getz und Martin Woodward für ihre Beiträge zu diesem Artikel danken.

Senden Sie Fragen und Kommentare für Brian Randell in englischer Sprache an mmvsts@microsoft.com.

Brian A. Randell ist leitender Berater bei MCW Technologies LLC. Er hält Vorträge, unterrichtet und schreibt über Microsoft-Technologien. Außerdem ist er Autor des Pluralsight-Kurses „Applied Team System“ und Microsoft MVP. Sie erreichen Brian Randell über seinen Blog unter mcwtech.com/cs/blogs/brianr.

Page view tracker