Stellen eines Builds in die Warteschlange

  • Artikel

Nachdem Sie eine oder mehrere Builddefinitionen erstellt und somit die Buildprozesse definiert haben, können Sie die Vorteile des Buildsystems nutzen. Die meisten Buildprozesse werden mit automatischen Triggern definiert. Weitere Informationen finden Sie unter Angeben der Buildtrigger und Gründe.

Unabhängig davon, ob die Builddefinition einen manuellen oder einen automatischen Trigger aufweist, können Sie einen Build bei Bedarf jederzeit manuell in die Warteschlange stellen.

Allgemeine Aufgaben

Unterstützender Inhalt

Fügen Sie einen öffentlichen Build zur Warteschlange hinzu, wenn Sie die neueste Version des Quellcodes auf dem Versionskontrollserver erstellen möchten.

Verwenden Sie den Befehl TFSBuild start, um einen öffentlichen Build an der Eingabeaufforderung in die Warteschlange zu stellen.

Fügen Sie einen privaten Build zur Warteschlange hinzu, wenn Sie Änderungen erstellen möchten, die Sie in ein Shelveset eingefügt haben. Sie können private Builds (auch bekannt als "Buddybuilds") verwenden, um vor dem Einchecken Änderungen am Code zu überprüfen.

Um einen privaten Build an der Eingabeaufforderung in die Warteschlange zu stellen, verwenden Sie den Befehl TFSBuild start mit der /shelveset-Option.

Öffentliche Builds

Unabhängig davon, ob in einer Builddefinition ein automatischer Trigger angegeben ist, können Sie den Build manuell zur Warteschlange hinzufügen.

Erforderliche Berechtigungen

Zum Ausführen dieser Schritte muss für Sie die Berechtigung Builds zur Warteschlange hinzufügen auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.

So stellen Sie einen öffentlichen Build in Visual Studio in die Warteschlange

  1. Klicken Sie in Team Explorer auf das entsprechende Teamprojekt.

  2. Klicken Sie im Menü Build auf Neuen Build in Warteschlange.

    Das Dialogfeld Build "Teamprojektname" zur Warteschlange hinzufügen wird angezeigt.

  3. Wählen Sie in der Liste Builddefinition eine Builddefinition aus.

    Wenn für die ausgewählte Builddefinition eine Beschreibung vorhanden ist, wird diese unter der Liste Builddefinition angezeigt.

  4. Lassen Sie in der Liste Was möchten Sie erstellen? den Eintrag Neueste Quellen ausgewählt.

  5. (Optional) Wählen Sie in der Liste Buildcontroller einen anderen Buildcontroller als den Standardbuildcontroller aus.

  6. (Optional) Wählen Sie in der Liste Priorität in Warteschlange einen der folgenden Werte aus: Hoch, Höher als normal, Normal, Niedriger als normal oder Niedrig.

    Im Feld Position wird die geschätzte Position des Builds in der Warteschlange angezeigt.

  7. (Optional) Im Feld Ablageordner für diesen Build wird der Ordner angezeigt, in dem bei Abschluss des Builds Ausgaben wie Binärdateien gespeichert werden. Wenn Sie die Ausgaben an einem anderen Speicherort speichern möchten, geben Sie in diesem Feld den entsprechenden UNC (Universal Naming Convention)-Pfad ein.

    Wichtig

    Wenn Sie diesen Wert ändern, müssen Sie einen Ordner angeben, der für die Verwendung als Ablageordner vorbereitet wurde. Weitere Informationen finden Sie unter Einrichten von Ablageordnern.

  8. (Optional) Auf der Registerkarte Parameter können Sie ausschließlich für diese Ausführung weitere Einstellungen der Builddefinition anzeigen und überschreiben.

    Wenn die Builddefinition auf der Standardvorlage oder der Upgradevorlage basiert, finden Sie unter Define Workflow Builds Using the Default Template bzw. Verwenden von älteren MSBuild-Builds mithilfe der Upgradevorlage weitere Informationen zu diesen Parametern.

  9. Klicken Sie auf Warteschlange.

    Build Explorer wird mit der Registerkarte In Warteschlange gestellt angezeigt. Weitere Informationen finden Sie unter Verwalten und Anzeigen von abgeschlossenen Builds.

Private Builds

Fügen Sie einen privaten Build zur Warteschlange hinzu, wenn Sie die Änderungen erstellen möchten, die Sie in ein Shelveset eingefügt haben. Sie können private Builds (auch bekannt als "Buddybuilds") verwenden, um vor dem Einchecken Änderungen am Code zu überprüfen. Wenn Sie für Ihre Änderungen vor dem Einchecken einen privaten Build ausführen, können Sie das Risiko verringern, dass diese zu Beschädigungen bei den Builds führen, die das Team regelmäßig ausführt (z. B. ein nächtlicher Build).

Unterschiede zwischen privaten Builds und öffentlichen Builds

Die Ergebnisse eines abgeschlossenen privaten Builds unterscheiden sich von denen eines abgeschlossenen öffentlichen Builds wie folgt:

  • Ein privater Build ähnelt einem abgegrenzten Eincheckbuild insofern, dass Sie Code erstellen, der Änderungen in einem Shelveset enthält. Nach einem privaten Build werden die Änderungen allerdings nicht automatisch eingecheckt, wie es nach einem abgegrenzten Eincheckbuild der Fall ist.

  • Bei den folgenden Buildprozessparametern wird angenommen, dass sie unabhängig von der in der Builddefinition angegebenen Einstellung den Wert False und somit keine Auswirkungen haben:

    • Quellen mit Bezeichnungen versehen

    • Bei Fehler Arbeitsaufgabe erstellen

    • Changesets und Arbeitsaufgaben zuordnen

  • In Build Explorer wird der abgeschlossene Build neben dem folgenden Symbol angezeigt: ms181722.Icon_BldPrivateBuild(de-de,VS.100).gif

  • Der abgeschlossene Build wird unter Verwendung des Formats Build N benannt, wobei N ein eindeutiger ganzzahliger Wert ist. Dieses Format unterscheidet sich vom Format öffentlicher Builds, das Sie mit dem Parameter Buildnummernformat angeben.

  • Für jede Builddefinition geben Sie eine separate (und optional jeweils unterschiedliche) Beibehaltungsrichtlinie an, um die Anzahl der abgeschlossenen privaten Builds einzuschränken, die im System gespeichert werden.

Hinzufügen eines privaten Builds zur Warteschlange

Erforderliche Berechtigungen

Zum Ausführen dieser Schritte muss für Sie die Berechtigung Builds zur Warteschlange hinzufügen auf Zulassen festgelegt sein. Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.

So stellen Sie einen privaten Build in Visual Studio in die Warteschlange

  1. Klicken Sie in Team Explorer auf das entsprechende Teamprojekt.

  2. Klicken Sie im Menü Build auf Neuen Build in Warteschlange.

    Das Dialogfeld Build "Teamprojektname" zur Warteschlange hinzufügen wird angezeigt.

  3. Wählen Sie in der Liste Builddefinition eine Builddefinition aus.

    Wenn für die ausgewählte Builddefinition eine Beschreibung vorhanden ist, wird diese unter der Liste Builddefinition angezeigt.

  4. Wählen Sie in der Liste Was möchten Sie erstellen? den Eintrag Neueste Quellen mit Shelveset aus.

    Das Feld Shelvesetname wird angezeigt.

  5. Führen Sie einen der folgenden Schritte aus:

    • Wenn bereits ein Shelveset vorhanden ist, geben Sie dessen Namen in das Feld Shelvesetname ein, oder klicken Sie auf die Schaltfläche mit den Auslassungspunkten (…), um das Shelveset zu suchen.

    • Wenn Sie ausstehende Änderungen aus dem Arbeitsbereich in ein Shelveset einfügen und dann diese Änderungen erstellen möchten, klicken Sie auf Erstellen.

  6. (Optional) Wenn Sie die Änderungen im Shelveset bei einem erfolgreichen Buildvorgang einchecken möchten, aktivieren Sie das Kontrollkästchen Änderungen nach erfolgreichem Buildvorgang einchecken.

    Wichtig

    Wenn Sie dieses Kontrollkästchen aktivieren, wird der Build nicht als privater Build, sondern als abgegrenzter Eincheckbuild ausgeführt. Weitere Informationen über abgegrenzte Eincheckbuilds finden Sie unter Definieren eines abgegrenzten Eincheckbuilds zur Überprüfung der Änderungen.

  7. (Optional) Wählen Sie in der Liste Buildcontroller einen anderen Buildcontroller als den Standardbuildcontroller aus.

  8. (Optional) Wählen Sie in der Liste Priorität in Warteschlange einen der folgenden Werte aus: Hoch, Höher als normal, Normal, Niedriger als normal oder Niedrig.

    Im Feld Position wird die geschätzte Position des Builds in der Warteschlange angezeigt.

  9. (Optional) Führen Sie die folgenden Schritte aus, um den Ordner anzugeben, in den die Ausgaben wie Binärdateien heruntergeladen werden:

    Tipp

    Ignorieren Sie das Feld Ablageordner für diesen Build. Dieses hat bei privaten Builds keine Auswirkungen.

    1. Klicken Sie auf die Registerkarte Parameter, und erweitern Sie dann die Gruppe Erweitert.

    2. Geben Sie im Feld Privater Ablagespeicherort den UNC-Pfad des Ordners ein, in dem die Ausgabe nach Abschluss des Buildvorgangs gespeichert werden soll.

      Tipp

      • Wenn Sie diesen Ordner nicht angeben, schlägt der Buildvorgang zwar nicht fehl, aber im Buildprotokoll wird eine Warnung angezeigt.

      • Wenn Sie diesen Wert ändern, müssen Sie einen Ordner angeben, der für die Verwendung als Ablageordner vorbereitet wurde. Weitere Informationen finden Sie unter Einrichten von Ablageordnern.

  10. (Optional) Auf der Registerkarte Parameter können Sie ausschließlich für diese Ausführung weitere Einstellungen der Builddefinition anzeigen und überschreiben.

    Wenn die Builddefinition auf der Standardvorlage oder der Upgradevorlage basiert, finden Sie unter Define Workflow Builds Using the Default Template bzw. Verwenden von älteren MSBuild-Builds mithilfe der Upgradevorlage weitere Informationen zu diesen Parametern.

  11. Klicken Sie auf Warteschlange.

    Build Explorer wird mit der Registerkarte In Warteschlange gestellt angezeigt. Weitere Informationen finden Sie unter Verwalten und Anzeigen von abgeschlossenen Builds.

Siehe auch

Aufgaben

Erstellen einer einfachen Builddefinition

Konzepte

Definieren eines Builds mithilfe der Standardvorlage

Arbeiten mit Shelvesets

Definieren eines abgegrenzten Eincheckbuilds zur Überprüfung der Änderungen