Bereitstellen und Konfigurieren eines Build-Agents
Um Team Foundation Build verwenden zu können, muss das Team über mindestens einen Build-Agent verfügen, mit dem die prozessorintensiven Arbeiten des Buildprozesses ausgeführt werden können.
Jeder Build-Agent ist einem einzelnen Buildcontroller fest zugeordnet und wird von diesem gesteuert.Build-Agents können auf dem gleichen Buildserver gehostet werden, auf dem der Buildcontroller gehostet wird. Das ist jedoch nicht unbedingt erforderlich, und in einigen Fällen können die Anforderungen des Teams sehr effizient mit einem einzelnen Buildserver erfüllt werden, auf dem ein Buildcontroller gehostet wird, der Build-Agents auf mehreren Buildservern steuert.
Der Build-Agent führt die in der AgentScope-Aktivität enthaltenen Schritte des Buildprozesses aus.Normalerweise umfassen diese Schritte das Abrufen von Dateien aus der Versionskontrolle, das Bereitstellen des Arbeitsbereichs, das Kompilieren des Codes, das Ausführen von Tests sowie das Zurückführen von Dateien in die Versionskontrolle.
Achten Sie darauf, dass der Buildserver, der die Build-Agents hostet, über genügend Speicher- und Verarbeitungskapazitäten verfügt, die der Größe und Komplexität der CodeBases sowie der Tests auf der Teamprojektauflistung entsprechen.In der Regel sollten Sie nicht mehr als einen Build-Agent pro Prozessorkern auf dem Buildserver hosten.Sie können die Leistung auch verbessern, indem Sie dem Arbeitsverzeichnis jedes Build-Agents eine einzelne physische Festplatte zuordnen.
Tipp |
---|
Wenn die Teamprojektauflistung auf dem Team Foundation-Dienst gehostet wird und die Anforderungen des Teams durch einen einzelnen Standardbuild-Agent gedeckt werden können, können Sie den Gehosteten Buildcontroller verwenden, anstatt einen eigenen Build-Agent bereitzustellen. |
Erforderliche Berechtigungen
Sie müssen auf dem Buildserver Mitglied der Windows-Administratorgruppe und auf der Teamprojektauflistung Mitglied der Gruppe "Projektauflistungs-Buildadministratoren" sein.Siehe Team Foundation Server-Berechtigungen.
Was möchten Sie tun?
Erstellen oder ändern eines Build-Agents
Installieren von Visual Studio und anderer Software zum Aktivieren der Kompilierung und weiterer Funktionen
Angeben des Arbeitsverzeichnisses
Aktivieren des Build-Agents zum Ausführen von Tests
Zuweisen von Tags zum Darstellen von Build-Agent-Funktionen oder -Zwecken
Erstellen eines Build-Agents, der eine Windows Store-App kompilieren und testen kann
Entfernen eines Build-Agents
Erstellen oder ändern eines Build-Agents
So erstellen oder ändern Sie einen Build-Agent auf dem Buildserver
Melden Sie sich an dem Buildserver an, den Sie konfigurieren möchten.
Führen Sie aus dem Windows-Startmenü heraus die Team Foundation Server-Verwaltungskonsole aus.
Die Team Foundation-Verwaltungskonsole wird angezeigt.
Erweitern Sie im Strukturbereich der Team Foundation-Verwaltungskonsole den Namen des Servers, und wählen Sie dann den Knoten Buildkonfiguration aus.
Im Inhaltsbereich werden Informationen zum Buildserver angezeigt.
Wenn die Meldung Installierte Funktionen konfigurieren angezeigt wird, siehe Bereitstellen eines Buildservers.
Führen Sie auf der Buildkonfigurationsseite folgende Schritte durch:
Um einen neuen Build-Agent zu erstellen, wählen Sie Neuer Agent aus.
So ändern Sie einen vorhandenen Build-Agent
Wählen Sie Eigenschaften aus.
Das Dialogfeld Eigenschaften von Build-Agent wird angezeigt.
So ändern Sie einen Build-Agent aus Visual Studio
Im Team Explorer von Visual Studio:
Wenn Sie nicht bereits über eine Verbindung mit einem Teamprojekt in der Teamprojektauflistung verfügen, dann stellen Sie eine Verbindung zu dem Teamprojekt her.
Wählen Sie Startseite und dann die Option Builds aus.
Wählen Sie auf der Buildsseite die Option Aktionen und dann Buildcontroller verwalten aus.
Das Dialogfeld Buildcontroller verwalten wird angezeigt.
Wählen Sie den zu ändernden Build-Agent aus, und wählen Sie anschließend Eigenschaften aus.
Das Dialogfeld Eigenschaften von Build-Agent wird angezeigt.
Anzeigename, Beschreibung: Geben Sie einen Namen und eine Beschreibung ein, damit Teammitglieder den Build-Agent leichter identifizieren können.
Controller: Wählen Sie den Buildcontroller aus, von dem dieser Build-Agent gesteuert werden soll.Der Buildcontroller kann auf dem gleichen Buildserver ausgeführt werden wie der Build-Agent. Er kann aber auch auf einem anderen Buildserver ausgeführt werden.
Weitere Informationen zum Konfigurieren des Build-Agents finden Sie in den Abschnitten weiter unten.
Installieren von Visual Studio und anderer Software zum Aktivieren der Kompilierung und weiterer Funktionen
Es hat sich bewährt, auf dem Build-Agent die Version von Visual Studio zu installieren, die das Team auf den Entwicklercomputern verwendet.Siehe Installieren von Visual Studio.Sie sollten zudem sämtliche andere Software und alle Komponenten installieren, die auf Ihren Entwicklercomputern installiert und zum Erstellen der App erforderlich sind.Andernfalls können Probleme auftreten, beispielsweise, dass einige der Codeprojekte nicht kompiliert werden können.
Angeben des Arbeitsverzeichnisses
Sie können das Arbeitsverzeichnis angeben, das vom Build-Agent zum Lesen aus und zum Schreiben in Dateien verwendet wird.Beispiel: Quelldateien werden in Unterverzeichnisse dieses Ordners kopiert, und Binärdateien werden erstellt und in anderen Unterverzeichnissen des Ordners gespeichert.
Tipp |
---|
Sie können die Leistung verbessern, indem Sie dem Arbeitsverzeichnis jedes Build-Agents eine einzelne physische Festplatte zuordnen. |
Verwenden von Arbeitsverzeichnistokens
Zwar kann für die Eigenschaft Arbeitsverzeichnis auch ein exakter Pfad (beispielsweise "c:\temp\build\") angeben werden, ein einfacherer und dauerhafter Ansatz ist jedoch die Verwendung von Tokens in der Pfadangabe.Zwei Arten von Tokens stehen zur Verfügung:
Umgebungsvariablen
Umgebungsvariablen enthalten Informationen zur Umgebung für das System sowie zum angemeldeten Benutzer.Die von Ihnen möglicherweise am häufigsten verwendete Variable ist SYSTEMDRIVE, aber für einige Situationen können Sie auch Variablen wie USERNAME oder HOMEPATH verwenden.Tipp Öffnen Sie zum Aufführen der Umgebungsvariablen auf dem Buildserver eine Eingabeaufforderung, und geben Sie set ein.
Team Foundation Build-Variablen
Sie können die folgenden Variablen im Arbeitsverzeichnis eines Build-Agents verwenden:$(BuildAgentId): Eine automatisch generierte ganze Zahl, durch die ein Build-Agent innerhalb einer Teamprojektsammlung eindeutig identifiziert wird.
$(BuildAgentName): Der Anzeigename des Build-Agents.
$(BuildDefinitionId): Eine automatisch generierte ganze Zahl, durch die eine Builddefinition innerhalb einer Teamprojektsammlung eindeutig identifiziert wird.
$(BuildDefinitionPath): Der Teamprojektname und der Builddefinitionsname, getrennt durch einen umgekehrten Schrägstrich.
Beispiel eines Arbeitsverzeichnisses
Angenommen, Sie verfügen über einen Build-Agent mit der Bezeichnung "BuildBot3".Sie haben im Teamprojekt "CoolApp" zwei Builds mit der Bezeichnung "NightlyBuild" bzw. "WeeklyBuild" definiert.Im Feld Arbeitsverzeichnis geben Sie den folgenden Wert an: $(SystemDrive)\TeamBuilds\$(BuildAgentName)\$(BuildDefinitionPath).Dadurch werden vom Build-Agent "BuildBot3" die beiden folgenden Arbeitsverzeichnisse erstellt und verwendet:
C:\TeamBuilds\BuildBot3\CoolApp\NightlyBuild
C:\ TeamBuilds\BuildBot3\CoolApp\WeeklyBuild
Achten Sie darauf, dass das der Pfad zum Arbeitsverzeichnis nicht zu lang ist.
Die Angabe des Arbeitsverzeichnisses darf nicht zur Erstellung eines physischen Pfads mit einer Länge von mehr als 259 Zeichen führen.Andernfalls könnten die Builds einen Fehler verursachen und diesen Fehler protokollieren: TF10128: The pathPhysicalPath contains more than the allowed 259 characters. Type or select a shorter path.
Geben Sie zum Beheben dieses Problems ein Arbeitsverzeichnis an, durch das sich ein kürzerer physischer Pfad ergibt.Sie können beispielsweise $(HOMEDRIVE)\bld\$(BuildAgentID)\$(BuildDefinitionID) angeben, um ein Arbeitsverzeichnis wie: c:\bld\3\2\ zu erstellen.
Im Arbeitsverzeichnis erstellte Unterverzeichnisse
Vom Build-Agent werden unter diesem Pfad die folgenden Unterverzeichnisse erstellt und verwendet:
Unterverzeichnis |
Gespeicherte Dateien |
---|---|
Sources |
Vom Build-Agent gelesene Dateien (beispielsweise Quelldateien).Die Dateien, die heruntergeladen werden, werden in den Arbeitsbereichseinstellungen für jede Builddefinition angegeben.Siehe Arbeiten mit Buildarbeitsbereichen. |
Binaries |
Vom Build-Agent kompilierte Dateien (beispielsweise kompilierte Anwendungsdateien). |
TestResults |
Dateien, die von beliebigen, durch den Build-Agent ausgeführten Tests erstellt wurden. |
Aktivieren des Build-Agents zum Ausführen von Tests
Sie können einen Buildprozess definieren, der einen oder mehrere automatisierte Tests ausführt.
Wichtig |
---|
Viele Arten von Tests und Testvorgängen erfordern die Installation derselben Version von Visual Studio auf dem Build-Agent, die das Team auf dem Entwickler Computer verwendet.Siehe Installieren von Visual Studio. |
Der Build-Agent kann Folgendes ausführen:
Codeabdeckung
Tests der codierten UI (erfordert einen im interaktiven Modus ausgeführten Buildserver.Siehe Führen Sie den Buildserver im interaktiven Modus aus und Testen der Benutzeroberfläche mit automatisierten Tests der codierten UI.)
Generierung von Datenbanktestdaten
Datenbankkomponententests
Generische Tests
Auslastungstests
Komponententests
Testreihen
Testauswirkungsanalyse
Webtests
Zuweisen von Tags zum Darstellen von Build-Agent-Funktionen oder -Zwecken
Mit zunehmender Saklierung des Buildsystems müssen unter Umständen spezialisierte Build-Agents definiert werden.Weisen Sie Build-Agents, die mit speziellen Funktionen ausgestattet oder für einen bestimmten Verwendungszweck vorgesehen sind, mindestens ein Tag zu.Auf diese Weise kann ein Teammitglied beim Erstellen einer Builddefinition, die eine bestimmte Art von Build-Agent erfordert, das Tag in der Builddefinition angeben.
Sie können Tags aus dem oben beschrieben Eigenschaftdialogfeld Build-Agent zuweisen.Sie können dann die Tags auf die Builddefinitionen anwenden.
Die folgende Tabelle enthält Beispiele für Tagnamen sowie Build-Agent-Funktionen, für die diese stehen können:
Sie können das folgende Tag anwenden... |
Um einen Build-Agent zu identifizieren, der... |
---|---|
x86 |
Kompilieren von 32-Bit-Anwendungen |
x64 |
Kompilieren von 64-Bit-Anwendungen |
bvt |
Führen Sie die BVT-Tests aus, die vom nächtlichen BVT-Build ausgeführt werden. |
WindowsStore |
|
IIS |
Kompilieren einer ASP.NET-Webanwendung und anschließendes Bereitstellen und Hosten der Anwendung auf dem Computer, auf dem der Build-Agent ausgeführt wird. |
interaktiv |
Führen Sie Aufgaben aus, die einen Agent auf einem Buildserver erfordern, der im interaktiven Modus ausgeführt wird. |
Ein Build-Agent kann mit mehreren Tags versehen werden.So können Sie beispielsweise einen Build-Agent mit den Tags "x86" und "Release" erstellen, um anzugeben, dass der Agent zum Kompilieren der Releasekonfiguration einer 32-Bit-Anwendung konfiguriert ist.
Wenn Sie auf einem Buildserver mehrere Build-Agents ausführen, verfügen vermutlich alle über die gleichen Funktionen.Daher empfiehlt es sich in der Regel auch, alle Build-Agents auf diesem Buildserver mit den gleichen Tags zu versehen.
Entfernen eines Build-Agents
Öffnen Sie in Visual Studio das Dialogfeld Buildcontroller verwalten, wie zuvor in Erstellen oder Ändern eines Build-Agent erläutert.
Wählen Sie den zu entfernenden Build-Agent aus, und wählen Sie anschließend Entfernen aus.
Tipp |
---|
Sie können auch die Team Foundation-Verwaltungskonsole zum Entfernen des Build-Agents verwenden, während Sie am Buildserver angemeldet sind. |
Nächste Schritte
Horizontale Skalierung des Team Foundation Buildsystems
In dem Maße, in dem das Team und die CodeBase wächst, können Sie das Buildsystem relativ einfach schrittweise erweitern.Ein Buildsystem verwalten
Gelegentlich müssen Sie das Buildsystem überwachen und verwalten.Verwenden Sie das Buildsystem zum Kompilieren, Testen und Bereitstellen der Anwendung
Nachdem das Buildsystem eingerichtet wurde, ist das Team bereit zum Erstellen eines einfachen Buildprozesses (beispielsweise ein fortlaufender Integrations-Build) und kann den Vorteil nutzen, dass die App automatisch erstellt und getestet wird.