Verwenden der Standardvorlage für Ihren Buildprozess

  • Artikel

Mithilfe der Standardvorlage (TFVC icon "TfvcTemplate.12.xaml" oder Git icon "GitTemplate.12.xaml") können Sie schnell einen einfachen Prozess zum Erstellen und Testen Ihres Codes definieren. Wahlweise können Sie steuern, wie Team Foundation Build (TFBuild) den Code erstellt, die Tests durchführt und andere Prozesse wie Skripts ausführt.

Erste Schritte

  1. (Optional) Bevor Sie eine neue Builddefinition erstellen, öffnen Sie auf der Team Explorer-Startseite (Tastatur: STRG+0, H) die zu erstellende Projektmappe, sodass sie automatisch im Feld Projekte angegeben wird.

  2. Vergewissern Sie sich in Team Explorer, dass Sie mit dem Teamprojekt verbunden sind (Tastatur: STRG+0, C), und öffnen Sie anschließend die Seite Builds (Tastatur: STRG+0, B).

  3. Wählen Sie den Link Neue Builddefinition oder einen Build aus, öffnen Sie das entsprechende Kontextmenü, und wählen Sie Builddefinition bearbeiten aus.

    Tipp

    Konfigurieren Sie einen Buildcontroller, wenn die Fehlermeldung "TF225001" angezeigt wird.

  4. In der Standardeinstellung ist auf der Registerkarte Prozess unter Buildprozessvorlage die Standardvorlage ausgewählt.

    Default Template build process

    Warnung

    Sind Sie mit einem Git icon Git-Teamprojekt gehostet auf Visual Studio Online?Fehlen Ihnen die Parameter Auschecküberschreibung und Projekte?

    Parameters from the wrong Git default template

    Weitere Informationen hierzu finden Sie unter Wie vergewissere ich mich, dass ich die richtige Standard-Git-Buildprozessvorlage auf Visual Studio Online verwende?

  5. 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.

  6. 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 oder Bearbeiten einer Builddefinition.

Was möchten Sie als Nächstes tun?

  • Abrufen des Codes

  • Erstellen des Codes

    • Angeben der zu erstellenden Projekte

    • Angeben der zu erstellenden Plattformen und Konfigurationen

    • Angeben von Buildoptionen

  • Testen des Codes und Analysieren der Testauswirkung

  • Ausführen anderer Prozesse während des Builds

  • Steuern der Ausführung des Builds auf den Servern

    • Angeben, von welchen Build-Agents der Build verarbeitet wird

    • Angeben von Build-Agent-Zeitlimits

  • Steuern des Buildergebnisses

    • Angeben des Ausgabespeicherorts für den Build

    • Sinnvolle Benennung abgeschlossener Builds für das Team

    • Veröffentlichen von Symbolen aus dem Build

    • Zuordnen und Erstellen von Arbeitsaufgaben

    • Erstellen einer Arbeitsaufgabe bei Fehler

    • Kennzeichnen des Quellcodes

  • Antworten auf häufige Fragen erhalten

Abrufen des Codes

Auf der Registerkarte Quelleinstellungen können Sie einige Optionen für das Abrufen des angegeben Quellcodes durch den Build-Agent festlegen.

Zweck

Festzulegender Parameter

Anleitung

Angeben, ob der Arbeitsbereich oder das Git-Repository des Build-Agents vor dem Verarbeiten des Builds bereinigt wird

TFVC icon TFVC: Arbeitsbereich bereinigen

Git icon Git: Bereinigtes Repository

Wählen Sie True 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.

Tipp

Wenn für den Buildprozess kein bereinigter Arbeitsbereich bzw. bereinigtes Repository erforderlich ist, können Sie durch Festlegen dieses Parameterwerts auf False die Ausführungszeit des Builds wesentlich verringern.

Diese Einstellung hat keine Auswirkungen, wenn Sie mithilfe von Gehostete Buildcontroller verwenden. In diesem Fall wird für jeden Build ein neues Arbeitsverzeichnis erstellt.

Erstellen einer bestimmten Version des Quellcodes

TFVC icon TFVC: Version abrufen

Git icon Git: Auschecküberschreibung

TFVC: Geben Sie die versionspec der zu erstellenden Version an.

Git: Geben Sie die auszucheckende Verzweigung oder Commit-ID an.

Erstellen des Codes

Sie können mit MSBuild den Code kompilieren.

Angeben der zu erstellenden Projekte

In der Tabelle Buildprozessparameter können Sie unter Build im Feld Projekte die zu erstellenden Projektmappen oder Codeprojekte angeben. 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 in der Zelle Projekte angeben, anstatt jedes Projekt einzeln aufzuführen.

Im Feld Projekte können Sie die Schaltfläche mit den Auslassungspunkten (...) auswählen, um das Dialogfeld Projektmappen/Projekte zu öffnen und die zu erstellenden Projektmappen bzw. Projekte anzugeben.

Um das Feld Projekte für ein TFVC-Teamprojekt 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 beim Verwenden von TFVC sicher, dass der Pfad jedes Projekts oder jeder Projektmappe ein untergeordnetes Element von einem der Quellcodeverwaltungsordner-Werte auf der Registerkarte Quelleinstellungen der Builddefinition ist.Stellen Sie beim Verwenden von Git sicher, dass sich das Projekt oder die Projektmappe innerhalb des Git-Repositorys in einer Verzweigung befindet, die erstellt wird.

Angeben der zu erstellenden Plattformen und Konfigurationen

Im Feld Konfigurationen können Sie die zu erstellenden Plattformen und Konfigurationen angeben. 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 Konfigurationen leer lassen, werden die Standardkonfiguration und Standardplattform erstellt, die in den einzelnen Projektmappen oder Projekten definiert sind.

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

Jede Konfiguration im Feld Konfigurationen sollte das folgende Format aufweisen:

Konfiguration|Plattform

Sie müssen die folgenden Platzhalter ersetzen:

  • Konfiguration steht für einen Wert wie "Debug", "Release" oder "Alle Konfigurationen".

  • Plattform steht für einen Wert wie "Win32", "x86", "x64" oder "Any CPU".

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

Wenn Sie z. B. sowohl die Debug-Konfiguration als auch die Release-Konfiguration eines C#-Projekts erstellen möchten, geben Sie im Feld Konfigurationen die Zeichenfolge "Debug|Any CPU, Release|Any CPU" 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, könnten bei Abschluss des Builds unerwartete Ergebnisse auftreten.

Hinweis

Wenn Sie anstelle einer Projektmappendatei einzelne Codeprojekte erstellen und als Plattform "Any CPU" angeben möchten, sollten Sie dafür "AnyCPU" anstelle von "Any CPU" eingeben.

Angeben von Buildoptionen

Sie können verschiedene Buildoptionen steuern.

Zweck

Festzulegender Parameter

Anleitung

Steuert, ob neu erstellt werden soll

Build, Bereinigter Build

Legen Sie diesen Parameter auf True fest, wenn der gesamte Code in den Codeprojekten neu erstellt werden soll. Dies entspricht MSBuild /target:clean. Diese Option hat nur praktische Auswirkungen, wenn Bereinigtes Repository gleichzeitig auf False festgelegt wird.

Tipp

Durch Festlegen dieser Option auf False können Sie die zum Erstellen großer CodeBases erforderliche Zeit wesentlich reduzieren.

Überprüfen von Code anhand von Ebenendiagrammen

Build, Erweitert, 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

Build, Erweitert, 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

Build, Erweitert, 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, könnten Probleme auftreten, 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.

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.

Ausführen anderer Prozesse

Sie können während des Builds andere Prozesse ausführen.

Ausführen einer Codeanalyse

Sie können den Code während des Builds analysieren, um häufige Fehler zu finden. Legen Sie in den erweiterten Buildparametern den Codeanalyse ausführen-Parameter fest.

  • 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:

Steuern der Ausführung des Builds auf den Servern

Sie können steuern, wie der Build vom Buildserver ausgeführt werden soll.

Angeben, von welchen Build-Agents der Build verarbeitet wird

Zum Angeben der Build-Agents zum Verarbeiten des Builds erweitern Sie den Erweitert-Knoten und den Agent-Einstellungen-Knoten, 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.

Steuern des Buildergebnisses

Angeben des Ausgabespeicherorts für den Build

Zum Steuern des Speicherorts der Buildausgaben von TFBuild wählen Sie folgende Optionen aus:

  • SingleFolder: Alle Buildausgabedateien werden zusammen im Ablageordner gespeichert.

  • PerProject: Die Buildausgaben werden im Ablageordner in Unterordnern für jede Projektmappe und jedes Codeprojekt gruppiert, die Sie im Feld Projekte angegeben haben.

  • AsConfigured: Die Binärdateien werden im Build-Agent-Quellordner belassen, organisiert in der gleichen Unterordnerstruktur wie beim Erstellen des Codes in Visual Studio auf dem Entwicklercomputer. Diese Struktur wird in den Codeprojekten definiert.

    Wenn Sie diese Option verwenden, wird die die Ausgabe von TFBuild nicht in den Ablageordner kopiert. Stattdessen können Sie Skripts zum Kopieren der Ausgaben an den Speicherort durch Angabe von TF_BUILD_BINARIESDIRECTORY programmieren, sodass die Ausgaben am Stagingspeicherort abgelegt werden. Weitere Informationen finden Sie unter Postbuild- oder Posttestskripts.

Sinnvolle Benennung abgeschlossener Builds für das Team

Mithilfe von Erweitert und Buildnummernformat können Sie und Ihr Team nützliche Daten in den Namen jedes abgeschlossenen Builds laden. Die gültigen Werte für diesen Parameter finden Sie unter Verwenden von Buildnummern, um abgeschlossene Builds mit aussagekräftigen Namen zu versehen.

Veröffentlichen von Symbolen aus dem Build

Geben Sie zum Indizieren und Veröffentlichen von Symboldaten den Parameter Pfad zum Veröffentlichen von Symbolen an, um Funktionen wie verlaufsbezogenes Debugging zu aktivieren. Siehe Indizieren und Veröffentlichen von Symboldaten.

Zuordnen von Changesets, Commits und Arbeitsaufgaben

Der Buildprozess verknüpft automatisch jeden abgeschlossenen Build mit allen Changesets oder Commits, die in den Code und die zugeordneten Arbeitsaufgaben aufgenommen wurden. Sie können dieses Verhalten nicht deaktivieren. Sie können jedoch unter Erweitert entscheiden, ob Sie Arbeitsaufgaben mit Buildnummer aktualisieren möchten, indem Sie True oder False auswählen.

Wie bestimmt der Buildprozess, wann Changesets, Commits und Arbeitsaufgaben zugeordnet werden?

Erstellen einer Arbeitsaufgabe bei Fehler

Wählen Sie für Erweitert, Bei Fehler Arbeitsaufgabe erstellen die Option True aus, wenn im Fall eines fehlgeschlagenen Builds der Buildprozess einen Fehler erstellen und ihn der Person zuweisen soll, von der TFVC icon das TFVC-Changeset eingecheckt bzw. Git icon der Git-Commit per Push abgelegt wurde.

Kennzeichnen des Quellcodes

Wählen Sie für TFVC icon TF-Versionskontrolle, Quellen mit Bezeichnungen versehen die Option True aus, wenn Sie jede Quellcodedatei mit einer Bezeichnung automatisch kennzeichnen möchten, damit Ihr Team leichter bestimmen kann, welche Version der einzelnen Dateien im abgeschlossenen Build enthalten ist. Diese Einstellung gilt nicht für Git icon Git-Teamprojekte.

Informationen darüber, wie TFBuild festlegt, welche Version etikettiert werden soll, finden Sie unter Wie gut war dieser Build?

Fragen und Antworten

Wie vergewissere ich mich, dass ich die richtige Standard-Git-Buildprozessvorlage auf Visual Studio Online verwende?

Sind Sie mit einem Git icon Git-Teamprojekt gehostet auf Visual Studio Online? Fehlen Ihnen die Parameter Auschecküberschreibung und Projekte?

Werden beim Anzeigen der Standardvorlage (GitTemplate.xaml) Details eingeblendet?

The wrong Git default template

Wenn dies der Fall ist, wählen Sie GitTemplate.12.xaml aus. Danach werden der Parameter Auschecküberschreibung und die Schaltfläche "Durchsuchen" im Parameter Projekte angezeigt.

The correct Git default template

F: Wie bestimmt der Buildprozess, wann Changesets, Commits und Arbeitsaufgaben zugeordnet werden?

A: Für jede Builddefinition wird ein eigener Datensatz verwaltet, der die Changesets (TFVC), Commits (Git) 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.

Informationen darüber, wie TFBuild festlegt, welche Version zugehörig ist, finden Sie unter Wie gut war dieser Build?

F: F: Ich benötige meinen Buildprozess für andere Aktionen.Wie kann ich ihn anpassen?

A: Anpassen der Prozesses