Definieren eines auf der Standardvorlage basierenden Buildprozesses

Artikel
02/26/2013

Mithilfe der Standardvorlage (DefaultTemplate.11.1.xaml) können Sie schnell einen grundlegenden Build definieren, indem Sie die zu erstellenden Codeprojekte auswählen.Mithilfe dieser Vorlage können Sie auch erweiterte Funktionen (z. B. das Ausführen von automatisierten Tests) einschließen und verschiedene Aspekte des Buildvorgangs an die Anforderungen des Teams anpassen.

Erforderliche Berechtigungen

Zum Ausführen dieses Vorgangs muss für Sie die Berechtigung Builddefinition bearbeiten auf Zulassen festgelegt sein.Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.

So erstellen Sie eine Builddefinition mithilfe der Standardvorlage

In Team Explorer:
1. Wenn Sie nicht bereits über eine Verbindung mit dem Teamprojekt verfügen, in dem Sie arbeiten möchten, stellen Sie eine Verbindung mit dem Teamprojekt her.
2. Wählen Sie Startseite und dann die Option Builds aus.
3. Klicken Sie auf der Seite Builds auf Neue Builddefinition.
Das Fenster "Neue Builddefinition" wird angezeigt.
Auf der Registerkarte Prozess unter Buildprozessvorlage ist standardmäßig die Standardvorlage ausgewählt.Erweitern Sie unter Buildprozessparameter den Knoten Erforderlich, und geben Sie mindestens eine Projektmappe oder ein Projekt an, die bzw. das erstellt werden soll.

Weitere Informationen finden Sie weiter unten in diesem Thema unter Angeben der zu erstellenden Projekte.
Verwenden Sie die Informationen weiter unten in diesem Thema zum Ausfüllen der Felder, die die Funktionen bereitstellen, die in dieser Builddefinition enthalten sein sollen.
Nachdem Sie die Felder auf der Registerkarte Prozess ausgefüllt haben, geben Sie auf den anderen Registerkarten die Optionen für den Buildprozess an.

Weitere Informationen finden Sie unter Erstellen einer Builddefinition.

In diesem Thema

Informationen zu den Buildprozessparametern für die Standardvorlage
Angeben der zu erstellenden Projekte
Angeben der zu erstellenden Plattformen und Konfigurationen
Angeben, von welchen Build-Agents der Build verarbeitet wird
Angeben von Build-Agent-Zeitlimits
Ausführen von automatisierten Tests und Aktivieren der Testauswirkungsanalyse
Angeben von grundlegenden Buildprozessparametern
Angeben von erweiterten Buildprozessparametern

Informationen zu den Buildprozessparametern für die Standardvorlage

In diesem Thema wird erläutert, wie ein Build mithilfe der Buildprozessparameter in Builds definiert wird, die auf der Standardvorlage basieren.Die Informationen in diesem Thema beschreiben die Funktionen, die den Funktionen in Visual Studio entsprechen, sofern die folgenden Bedingungen erfüllt sind:

Sie arbeiten in einem Teamprojekt, das mithilfe einer der Prozessvorlagen erstellt wurde, die in Visual Studio enthalten sind.
Die Datei "DefaultTemplate.11.1.xaml" wurde von keinem Mitglied des Teams entfernt oder angepasst.

Angeben der zu erstellenden Projekte

Im Feld Zu erstellende Projekte können Sie ein oder mehrere zu erstellende Projektmappen oder Codeprojekte angeben.(Um dieses Feld anzuzeigen, erweitern Sie den Knoten Erforderlich, und erweitern Sie dann den Knoten Zu erstellende Elemente.) Sie müssen mindestens eine Projektmappe bzw. mindestens ein Projekt angeben.

Wenn Sie mehrere verwandte Projekte erstellen, sollten Sie sie in der Regel einer einzelnen Projektmappe hinzufügen und diese Projektmappe im Feld Zu erstellende Projekte angeben, statt jedes Projekt einzeln aufzuführen.

Im Feld Zu erstellende Projekte können Sie auf die Schaltfläche mit den Auslassungspunkten (...) klicken, um das Dialogfeld Projektmappen/Projekte zu öffnen und in diesem die zu erstellenden Projektmappen bzw. Projekte anzugeben.

Um das Feld Zu erstellende Projekte manuell auszufüllen, geben Sie den vollständigen Versionskontrollpfad jedes Projekts oder jeder Projektmappe an, das bzw. die Sie erstellen möchten.Trennen Sie die einzelnen Werte durch ein Komma, wie im folgenden Beispiel gezeigt:

$/Funktionen/FunktionA/Server/Alle Serverprojekte.sln, $/Funktionen/FunktionA/Client/Alle Clientprojekte.sln

Wichtig
Stellen Sie sicher, dass der Pfad jedes Projekts oder jeder Projektmappe ein untergeordnetes Element von einem der Werte für Quellcodeverwaltungsordner auf der Registerkarte Arbeitsbereich der Builddefinition ist.

Angeben der zu erstellenden Plattformen und Konfigurationen

Im Feld Zu erstellende Konfigurationen können Sie die zu erstellenden Plattformen und Konfigurationen angeben.(Um dieses Feld anzuzeigen, erweitern Sie den Knoten Erforderlich, und erweitern Sie dann den Knoten Zu erstellende Elemente.) Sie können z. B. angeben, dass mit dem Build nur die Releasekonfiguration der 32-Bit-Version des C++-Projekts erstellt werden soll, indem Sie in dieses Feld Release|x86 einschließen.

Tipp
Wenn Sie über eine große CodeBase verfügen, können Sie die Verarbeitung des Builds erheblich beschleunigen, indem Sie nur die Konfigurationen und Plattformen erstellen, die Sie benötigen.

Wenn Sie das Feld Zu erstellende Konfigurationen leer lassen, werden die Standardkonfiguration und Standardplattform erstellt, die in den einzelnen Projektmappen oder Projekten definiert sind.

Im Feld Zu erstellende Elemente können Sie auf die Schaltfläche mit den Auslassungspunkten (...) klicken, um das Dialogfeld Konfigurationen zu öffnen und darin die zu erstellenden Elemente anzugeben.Sie können diese auch manuell angeben.

Jede Konfiguration im Feld Zu erstellende Konfigurationen sollte das folgende Format aufweisen:

Konfiguration|Plattform

Sie müssen die folgenden Platzhalter ersetzen:

Konfiguration steht für den Wert Debug, Release oder Alle Konfigurationen.
Plattform steht für den Wert Win32, x86, x64 oder AnyCPU.

Die Konfigurationen in der Liste müssen durch Kommas getrennt sein.

Wenn Sie z. B. die Konfigurationen Debug und Release eines C#-Projekts erstellen möchten, geben Sie im Feld Zu erstellende Konfigurationen Debug|AnyCPU, Release|AnyCPU an.

Die Token, die Sie für die Konfiguration und Plattform verwenden, müssen mit den Token übereinstimmen, die in den Projektmappeneigenschaften oder Codeprojekteigenschaften festgelegt sind.Wenn sie nicht übereinstimmen, treten möglicherweise bei Abschluss des Builds unerwartete Ergebnisse auf.

Angeben, von welchen Build-Agents der Build verarbeitet wird

Um anzugeben, welche Build-Agents zum Verarbeiten des Builds verwendet werden, erweitern Sie den Knoten Erweitert, erweitern Sie den Knoten Agent-Einstellungen, und geben Sie dann Werte für die folgenden Parameter an:

Namensfilter: Sie können die Build-Agents, mit denen die Builddefinition verarbeitet wird, filtern, indem Sie in diesem Feld den Namen des Agents eingeben.Sie können auch mit den Platzhalterzeichen * und ? einen Satz von Namen festlegen.Beispielsweise können Sie mit CI* alle Agents angeben, deren Name mit den Zeichen CI beginnt.Diesem Kriterium entsprechen z. B. die Agents CI, CI1 und CI_Agent2.

Tagfilter: Geben Sie ein oder mehrere Tags an, um sicherzustellen, dass dieser Build nur von Build-Agents mit übereinstimmenden Tags ausgeführt wird.Tags weisen Sie in der Regel bestimmten Build-Agents zu, um diese für besondere Zwecke zu reservieren.Beispiel: Sie richten einen Build-Agent auf einem Buildcomputer ein, der die abgegrenzten Eincheckbuilds verarbeiten soll.Sie wenden auf diesen Build-Agent das Tag Abgegrenzt an.Schließlich wenden Sie das Tag Abgegrenzt auf die Builddefinition an, damit der Build nur von dem Agent verarbeitet wird, der ebenfalls mit dem Tag Abgegrenzt markiert ist.Klicken Sie zum Angeben von Tags auf die Schaltfläche mit den Auslassungspunkten (...).

Hinweis
Die Gruppe der zum Verarbeiten des Builds verfügbaren Build-Agents wird vom Buildcontroller bestimmt, den Sie für die Builddefinition angegeben haben.Um den Buildcontroller zu ändern, klicken Sie auf die Registerkarte Build-Standardwerte, öffnen das Menü Buildcontroller und klicken dann auf einen Buildcontroller.

Tagvergleichsoperator: Klicken Sie im Menü auf einen der folgenden Werte:

MatchExactly: Klicken Sie auf diesen Wert, wenn die Builddefinition nur von den Build-Agents verarbeitet werden soll, die genau den Satz von Tags aufweisen, die Sie im Feld Tagfilter angegeben haben.Wenn Sie keine Tags angeben, kann jeder Agent diese Builddefinition verarbeiten.

Tipp
Wenn Sie auf MatchExactly klicken, beschränken Sie die für diese Builddefinition verfügbaren Agents auf die Agents, die den exakten Tag-Satz aufweisen, der im Feld Tagfilter angegeben ist.

MatchAtLeast: Klicken Sie auf diesen Wert, wenn die Builddefinition von jedem Build-Agent verarbeitet werden soll, der mindestens denselben Tag-Satz aufweist, den Sie im Feld Tagfilter angegeben haben.Wenn Sie keine Tags angeben, können nur Agents ohne Tags diese Builddefinition verarbeiten.

Angeben von Build-Agent-Zeitlimits

Um Zeitlimits anzugeben, erweitern Sie den Knoten Erweitert, erweitern Sie den Knoten Agent-Einstellungen, und geben Sie dann die Parameter in der folgenden Tabelle an.

Zweck	Festzulegender Parameter	Anleitung
Angeben der maximal zulässigen Zeitspanne für die Verarbeitung des Builds durch den Build-Agent	Maximale Ausführzeit	Geben Sie einen Zeitspannenwert im Format hh:mm:ss ein.Beispielsweise schlägt der Build mit einem Timeoutfehler fehl, wenn Sie den Wert 04:30:15 angeben und die Verarbeitung durch den Build-Agent nach 4 Stunden, 30 Minuten und 15 Sekunden nicht abgeschlossen ist.Geben Sie den Wert 00:00:00 an, wenn Sie eine unbegrenzte Zeitspanne für die Verarbeitung des Builds durch den Build-Agent festlegen möchten.
Angeben der maximal zulässigen Zeitspanne zum Zuweisen der Buildanforderung an einen Build-Agent	Maximale Wartezeit	Geben Sie einen Zeitspannenwert im Format hh:mm:ss ein.Beispielsweise schlägt der Build mit einem Timeoutfehler fehl, wenn Sie den Wert 01:30:45 angeben und der Build nach 1 Stunde, 30 Minuten und 45 Sekunden noch keinem Build-Agent zugewiesen wurde.Geben Sie den Wert 00:00:00 an, wenn Sie für den Buildcontroller eine unbegrenzte Zeitspanne zum Suchen eines Build-Agents für die Verarbeitung der Builddefinition festlegen möchten.

Ausführen von automatisierten Tests und Analysieren der Testauswirkung

Sie können den Build so entwerfen, dass mindestens ein automatisierter Test ausgeführt wird und die Auswirkungen von Codeänderungen auf die Tests analysiert werden.Weitere Informationen finden Sie unter Ausführen von Testläufen im Buildprozess.

Angeben von grundlegenden Buildprozessparametern

Häufig müssen Sie die Buildprozessparameter im Knoten Standard ändern, um weniger typische Szenarios erfolgreich abzuschließen.

Zweck	Festzulegender Parameter	Anleitung
Durchführen eines oder mehrerer automatisierter Testläufe	Automatisierte Tests	Ausführen von Testläufen im Buildprozess
Anpassen der Konvention, die für die Namen abgeschlossener Builds verwendet wird	Buildnummernformat	Sie und Ihr Team können in den Namen jedes abgeschlossenen Builds nützliche Informationen einschließen.Weitere Informationen finden Sie unter Arbeiten mit Buildnummern. Um diesen Parameter anzupassen, können Sie Text direkt in dieses Feld eingeben.Es ist jedoch einfacher, den Wert zu ändern und die verfügbaren Token anzuzeigen, wenn Sie auf die Schaltfläche mit den Auslassungspunkten (...) klicken, um das Dialogfeld Buildnummernformat-Editor zu öffnen und zu verwenden.Klicken Sie in diesem Dialogfeld auf Makros, um die Token, die Sie verwenden möchten, anzuzeigen und einzufügen.
Angeben, ob und wie der Arbeitsbereich des Build-Agents vor dem Verarbeiten des Builds bereinigt wird	Arbeitsbereich bereinigen	Klicken Sie in diesem Menü auf einen der folgenden Werte: Wählen Sie Alles aus, um alle vorhandenen Ausgaben und Quellcodedateien zu löschen, bevor der Build verarbeitet wird.Verwenden Sie diese Option, wenn der Kompilierungsvorgang Probleme im Buildprozess mit größtmöglicher Gründlichkeit aufdecken soll. Wählen Sie Ausgaben aus, um alle vorhandenen Ausgaben zu löschen, jedoch Quellcodedateien beizubehalten, die seit dem letzten Build nicht geändert wurden (durch Ausführen von tf get ohne den /all-Schalter). Wählen Sie Keine aus, um vorhandene Ausgaben und Quellcodedateien beizubehalten, die seit dem letzten Build nicht geändert wurden (durch Ausführen von tf get ohne den /all-Schalter). Tipp Wenn der Buildvorgang nicht die zusätzliche Bereinigung erfordert, die über die Option Alle durchgeführt wird, können Sie die Ausführungszeit des Builds erheblich reduzieren, indem Sie Keine (die schnellste Option) oder Ausgaben angeben.Einige Arten von Fehlern (z. B. während der Umgestaltung) werden vom Team jedoch weniger häufig erkannt, wenn der Arbeitsbereich nicht bereinigt wurde.
Angeben der Ausführlichkeit des Buildprotokolls	Protokollierungsausführlichkeit	Buildinformationen sind für das Team wichtig. Allerdings kann ein Buildvorgang, der zu viele Informationen protokolliert, Probleme verursachen.Solche Probleme können Folgendes umfassen: Ausschöpfung des Serverspeichers und der CPU-Ressourcen, Verlangsamung der Serverleistung und schlechtere Benutzerfreundlichkeit im Fenster für Buildergebnisse auf dem Clientcomputer.Sie können steuern, wie viele Informationen in Ihrer Bereitstellung verarbeitet, gespeichert und angezeigt werden sollen.Weitere Informationen finden Sie unter Verwalten der Buildinformationen und des Steuerelement-Ausführlichkeitsgrads.
Analysieren des Codes, um häufige Fehler zu ermitteln	Codeanalyse ausführen	Klicken Sie in diesem Menü auf einen der folgenden Werte: Wählen Sie Wie konfiguriert aus, um jedes Codeprojekt zu analysieren, in dem diese Funktion aktiviert ist. Wählen Sie Immer aus, um jedes Codeprojekt zu analysieren, unabhängig davon, ob diese Funktion in den Codeprojekten aktiviert ist. Wählen Sie Nie aus, um die Codeanalyse zu überspringen. Weitere Informationen finden Sie in einem der folgenden Themen: Gewusst wie: Festlegen von Codeanalyseeigenschaften für C/C++-Projekte Gewusst wie: Konfigurieren der Codeanalyse für ein Projekt mit verwaltetem Code Gewusst wie: Konfigurieren der Codeanalyse für eine ASP.NET-Anwendung
Speichern der Symbole, um Funktionen, z. B. verlaufsbezogenes Debugging, zu ermöglichen	Quellen indizieren und Pfad zum Veröffentlichen von Symbolen	Sie können die Builddefinition für das Veröffentlichen von Symboldaten konfigurieren, um Funktionen, z. B. verlaufsbezogenes Debugging, zu ermöglichen.Weitere Informationen finden Sie unter Veröffentlichen von Symboldaten.

Angeben von erweiterten Buildprozessparametern

Die Buildprozessparameter unter dem Knoten Erweitert sind die Parameter, die Sie ändern müssen, um weniger typische Szenarios erfolgreich abzuschließen.

Zweck	Festzulegender Parameter	Anleitung
Angeben von Build-Agent-Einstellungen	Agent-Einstellungen	Angeben, von welchen Build-Agents der Build verarbeitet wird, Angeben von Build-Agent-Zeitlimits
Analysieren der Testauswirkung	Analysieren der Testauswirkung	Ausführen von Testläufen im Buildprozess
Verknüpfen jedes abgeschlossenen Builds mit allen Changesets, die in den Code und die zugeordneten Arbeitsaufgaben aufgenommen wurden	Changesets und Arbeitsaufgaben zuordnen	In den meisten Fällen empfiehlt es sich, diesen Parameter auf True (den Standardwert) festzulegen.Dies gilt insbesondere für geplante Builds (z. B. ein nächtlicher Build), da Sie häufig geplante Builds, die erfolgreich abgeschlossen wurden, zum Bestätigen von Patches oder zum Ausführen von zusätzlichen Tests verwenden. Für jede Builddefinition wird ein eigener Datensatz verwaltet, der die Changesets und Arbeitsaufgaben enthält, die dem nächsten abgeschlossenen Build zugeordnet werden sollen.Beispiel: Changeset 382 wird sowohl von Build A als auch von Build B erstellt.Build A wird in die Warteschlange gestellt und erfolgreich abgeschlossen.Build B wird in die Warteschlange gestellt und schlägt fehl.Changeset 382 wird jetzt mit dem erfolgreich abgeschlossenen Build von Build A und dem mit einem Fehler abgeschlossenen Build von Build B verknüpft. Changeset 382 wird nicht mit dem nächsten abgeschlossenen Build von Build A, sondern mit dem nächsten abgeschlossenen Build von Build B verknüpft.
Erstellen einer Arbeitsaufgabe, wenn der Build fehlschlägt	Bei Fehler Arbeitsaufgabe erstellen	Legen Sie diesen Parameter auf True fest, wenn das System bei Fehlschlagen des Builds eine Arbeitsaufgabe erstellen soll.
Deaktivieren von Tests	Deaktivieren von Tests	Ausführen von Testläufen im Buildprozess
Erstellen einer bestimmten Version des Quellcodes	Version abrufen	Geben Sie die Versionsspezifikation an, die die zu erstellende Version identifiziert. Weitere Informationen zu Versionsspezifikationen finden Sie unter Befehlszeilensyntax.
Bezeichnen der Version jeder Datei, die in jedem abgeschlossenen Build kompiliert wurde	Quellen mit Bezeichnungen versehen	Legen Sie diesen Parameter auf True fest, wenn das System jede Quellcodedatei mit einer Bezeichnung kennzeichnen soll.Hierdurch kann das Team leicht bestimmen, welche Version der einzelnen Dateien im abgeschlossenen Build enthalten ist.
Überprüfen von Code anhand von Ebenendiagrammen	MSBuild-Argumente	Schließen Sie in diesen Parameterwert die folgende Zeichenfolge ein: "/p:ValidateArchitecture=true". Weitere Informationen finden Sie unter Überprüfen von Code mit Ebenendiagrammen.
Angeben von Befehlszeilenargumenten, die an MSBuild übergeben werden sollen	MSBuild-Argumente	Wenn der Buildprozess es erfordert, dass Sie Argumente an MSBuild weiterleiten, geben Sie diese im Parameter MSBuild-Argumente ein.Weitere Informationen finden Sie unter MSBuild-Befehlszeilenreferenz.
Angeben der Bitanzahl der zum Verarbeiten des Builds verwendeten Version von MSBuild	MSBuild-Plattform	Geben Sie einen der folgenden Werte an: Geben Sie Auto an, wenn MSBuild mit der CPU-Bitanzahl der auf dem Build-Agent installierten Instanz von Team Foundation-Builddienst ausgeführt werden soll. Geben Sie X86 an, wenn der Build immer mit der 32-Bit-Version von MSBuild verarbeitet werden soll. Da Visual Studio als 32-Bit-Anwendung ausgeführt wird, treten möglicherweise Probleme auf, wenn der Build von einem Build-Agent verarbeitet wird, auf dem die 64-Bit-Version von Team Foundation-Builddienst ausgeführt wird.Durch Angeben von X86 können Sie Probleme dieser Art eventuell vermeiden. Geben Sie X64 an, wenn der Build immer mit der 64-Bit-Version von MSBuild verarbeitet werden soll. Wenn Sie diesen Wert angeben, stellen Sie sicher (z. B. mit einem Tag, wie weiter oben in diesem Thema erläutert), dass der Build von einem Build-Agent verarbeitet wird, dessen Host ein 64-Bit-Buildcomputer ist.Andernfalls schlägt der Build fehl.
Hinzufügen eines privaten Builds zur Warteschlange	Privater Ablagespeicherort	Normalerweise geben Sie in der Builddefinition keinen Wert für diesen Parameter an.Weitere Informationen zum Stellen eines privaten Builds in die Warteschlange finden Sie unter Stellen eines Builds in die Warteschlange.
Organisieren von Ausgabedateien nach Projektmappe	Projektmappenspezifische Buildausgaben	Legen Sie diesen Parameter auf True fest, wenn Sie die Ausgabedateien nach Projektmappe organisieren möchten.