Angeben der Buildtrigger und Gründe

Sie können einen Build bei Bedarf jederzeit manuell in die Warteschlange stellen. Die Anforderungen des Teams werden aber in den meisten Fällen am besten durch -Buildprozesse erfüllt, die mit automatischen Triggern definiert werden. Beim Auslösen eines Builds wird ein bestimmter Grund in der Reason-Eigenschaft erfasst. In diesem Thema wird beschrieben, wie die verfügbaren Buildtrigger und -gründe beim Entwickeln des Buildprozesses verwendet werden.

• Verwenden von Buildtriggern zum Erreichen von Teamzielen

  • Schützen des Teams vor Buildunterbrechungen

  • Beibehalten der Qualität durch Verwendung der fortlaufenden Integration

  • Überprüfen der Produktqualität durch Ausführen nächtlicher Buildüberprüfungstests (Build Verification Test, BVT)

• Verwenden von automatischen Buildtriggern

  • Verwenden des Triggers für fortlaufende Integration zum Hinzufügen eines Builds zur Warteschlange beim Einchecken einer Änderung

  • Verwenden des Triggers Parallele Builds zum Hinzufügen eines Builds zur Warteschlange beim Einchecken einer Änderung (mit Einschränkungen hinsichtlich der Anzahl der Buildausführung)

  • Verwenden des Triggers für abgegrenzte Eincheckvorgänge zum Hinzufügen eines Builds zur Warteschlange, wenn ein Teammitglied eine Änderung einchecken möchte, und Blockieren der Änderung, wenn der Buildvorgang fehlschlägt

  • Verwenden des Zeitplantriggers zum Hinzufügen eines Builds zur Warteschlange in regelmäßigen Intervallen

• Manuelles Hinzufügen eines Builds zur Warteschlange

  • Hinzufügen eines Builds zur Warteschlange

  • Hinzufügen eines privaten Builds zur Warteschlange

• Verwenden von benutzerdefiniertem Code zum Hinzufügen eines Builds zur Warteschlange

• Arbeiten mit Buildtriggern und -gründen

Verwenden von Buildtriggern zum Erreichen von Teamzielen

Schützen des Teams vor Buildunterbrechungen

Wenn ein Entwickler Änderungen eincheckt, die Fehler im Build verursachen, kann sich dies bei kleineren Teams als großes Ärgernis erweisen. Auf große Teams können hohe Kosten aufgrund von Produktivitätsverlusten und Planungsverzögerungen zukommen. Sie können den Trigger Abgegrenzter Eincheckvorgang verwenden, um die Codebasis vollständig oder teilweise vor diesem Problem zu schützen.

Beibehalten der Qualität durch Verwendung der fortlaufenden Integration

Fortlaufende Integration ist das Verfahren, den Code so häufig wie möglich in ein freigegebenes Repository zu integrieren. Während der Codeintegration kann Sie eine Buildunterbrechung oder ein Testfehler rechtzeitig über einen Fehler im Code informieren. Verwenden Sie den Trigger Fortlaufende Integration, um die fortlaufende Integration zu implementieren. Der Trigger Parallele Builds ähnelt dem Trigger Fortlaufende Integration und kann hilfreich sein, wenn das Buildsystem nicht leistungsfähig genug ist, um bei jedem Einchecken einen Buildvorgang durchzuführen.

Der Trigger Abgegrenzter Eincheckvorgang kann als auch rigoroser Ansatz für die fortlaufende Integration dienen. Der Trigger Fortlaufende Integration weist das Team auf Probleme hin, z. B. Buildunterbrechungen oder fehlgeschlagene Kernkomponententests. Im Gegensatz dazu verhindert der Trigger Abgegrenzter Eincheckvorgang, dass derartige Probleme in der Codebasis auftreten.

Weitere Informationen zur Verwendung des Buildsystems für die Unterstützung der fortlaufenden Integration finden Sie unter Kontinuierliche Builderstellung und Bereitstellung.

Überprüfen der Produktqualität durch Ausführen nächtlicher Buildüberprüfungstests (Build Verification Test, BVT)

Sie können regelmäßige Testläufe planen, um die Qualität des Builds zu bewerten. Diese Tests werden oft als Buildüberprüfungstests (Build Verification Test, BVT) oder Feuerproben bezeichnet. Die Tests bestehen in der Regel aus einer umfassenden Suite von Tests, mit denen wesentliche Bereiche einer Anwendung in einem bestimmten Build überprüft werden. Verwenden Sie den Trigger Zeitplan, um eine nächtliche BVT-Ausführung zu implementieren.

Weitere Informationen zum Trigger Zeitplan finden Sie unter Verwenden des Zeitplantriggers zum Hinzufügen eines Builds zur Warteschlange in regelmäßigen Intervallen. Weitere Informationen zum Einrichten eines BVT-Prozesses finden Sie unter Gewusst wie: Konfigurieren und Ausführen von geplanten Tests nach dem Erstellen der Anwendung.

Verwenden von automatischen Buildtriggern

Für die Builddefinition müssen Sie einen Buildtrigger angeben. In den meisten Fällen ist es ratsam, dass der Buildprozess automatisch ausgeführt wird. Sie können einen der automatischen Trigger auswählen, die in diesem Abschnitt beschrieben werden.

Verwenden des Triggers für fortlaufende Integration zum Hinzufügen eines Builds zur Warteschlange beim Einchecken einer Änderung

Wenn Sie einen Build mit dem Trigger Fortlaufende Integration definieren, wird der Build immer dann in die Warteschlange gestellt, wenn ein Teammitglied eine Änderung eincheckt. Die Builddefinition Arbeitsbereich legt fest, welche Dateien die Builddefinition auslösen. Weitere Informationen zu Buildarbeitsbereichen finden Sie unter Arbeiten mit Buildarbeitsbereichen.

Builds, die von Fortlaufende Integration ausgelöst werden, wird IndividualCI als Reason zugewiesen.

Verwenden des Triggers Parallele Builds zum Hinzufügen eines Builds zur Warteschlange beim Einchecken einer Änderung (mit Einschränkungen hinsichtlich der Anzahl der Buildausführung)

Wenn Sie einen Build mit dem Trigger Parallele Builds definieren, wird der Build beim Einchecken einer Änderung in die Warteschlange gestellt. Allerdings gelten die folgenden Einschränkungen:

• Es werden keine zusätzlichen Builds in die Warteschlange gestellt, wenn bereits ein Build dieser Builddefinition ausgeführt wird.

• Sie können die Häufigkeit von Builds weiter einschränken, indem Sie das Kontrollkästchen Höchstens in folgendem Intervall erstellen n Minuten aktivieren und einen ganzzahligen Wert zwischen 0 und 2147483647 eingeben.

Die Builddefinition Arbeitsbereich legt fest, welche Dateien die Builddefinition auslösen. Weitere Informationen zu Buildarbeitsbereichen finden Sie unter Arbeiten mit Buildarbeitsbereichen.

Builds, die von Parallele Builds ausgelöst werden, wird BatchedCI als Reason zugewiesen.

Verwenden des Triggers für abgegrenzte Eincheckvorgänge zum Hinzufügen eines Builds zur Warteschlange, wenn ein Teammitglied eine Änderung einchecken möchte, und Blockieren der Änderung, wenn der Buildvorgang fehlschlägt

Wenn Sie einen Build mit dem Trigger Abgegrenzter Eincheckvorgang definieren, werden Änderungen, die ein Teammitglied in das Versionskontrollsystem eincheckt, in ein Shelveset eingefügt und für die Erstellung in die Warteschlange eingereiht. Der Eincheckvorgang wird nur abgeschlossen, wenn der Build erfolgreich ist. Die Builddefinition Arbeitsbereich bestimmt, welche Dateien von der Builddefinition gesteuert werden. Weitere Informationen zu Buildarbeitsbereichen finden Sie unter Arbeiten mit Buildarbeitsbereichen.

Builds, die von Abgegrenzter Eincheckvorgang gestartet werden, wird CheckInShelveset als Reason zugewiesen.

Weitere Informationen zum Implementieren des Triggers Abgegrenzter Eincheckvorgang finden Sie unter Definieren eines abgegrenzten Eincheckbuilds zur Überprüfung der Änderungen. Weitere Informationen darüber, wie sich diese Art von Builddefinition auf das Team auswirkt, finden Sie unter Einchecken ausstehender Änderungen für einen abgegrenzten Eincheckbuild.

Verwenden des Zeitplantriggers zum Hinzufügen eines Builds zur Warteschlange in regelmäßigen Intervallen

Zeitplantrigger

Wenn Sie einen Build mit dem Trigger Zeitplan definieren und das Kontrollkästchen Erstellen, auch wenn sich seit dem letzten Build keine Änderungen ergeben haben deaktivieren, wird ein Build am angegebenen Tag und zur angegebenen Uhrzeit in die Warteschlange gestellt, falls seit der letzten Ausführung dieser Builddefinition Änderungen eingecheckt wurden. Der Build wird unabhängig davon in die Warteschlange gestellt, ob die Änderungen dem letzten gültigen Build zugeordnet waren.

Builds, die auf diese Weise ausgelöst werden, wird Schedule als Reason zugewiesen.

Zeitplantrigger (Grund: ScheduleForced)

Wenn Sie einen Build mit dem Trigger Zeitplan definieren und das Kontrollkästchen Erstellen, auch wenn sich seit dem letzten Build keine Änderungen ergeben haben aktivieren, wird ein Build am angegebenen Tag und zur angegebenen Uhrzeit in die Warteschlange gestellt. Der Build wird unabhängig davon in die Warteschlange gestellt, ob Änderungen eingecheckt wurden.

Builds, die auf diese Weise ausgelöst werden, wird ScheduleForced als Reason zugewiesen.

Manuelles Hinzufügen eines Builds zur Warteschlange

In bestimmten Fällen soll ein Buildvorgang möglicherweise nicht automatisch ausgeführt werden.

• Die Builddefinition ist eventuell nicht für automatische Ausführungen bereit, da sie sich noch in der Entwicklungsphase befindet.

• Möglicherweise möchten Sie einen bestimmten Buildvorgang nur manuell ausführen.

In solchen Fällen können Sie den Trigger Manuell auswählen. Die Builddefinition wird nur dann ausgeführt, wenn ein Teammitglied sie manuell in die Warteschlangen stellt.

Hinzufügen eines Builds zur Warteschlange

Sie können jede Builddefinition manuell in die Warteschlange stellen, auch wenn sie mit einem anderen Buildtrigger als Manuell definiert ist. Wenn Sie einen Build manuell in die Warteschlange stellen, wird Reason auf Manual festgelegt. Weitere Informationen über das manuelle Hinzufügen eines Builds zur Warteschlange finden Sie unter Stellen eines Builds in die Warteschlange.

Hinzufügen eines privaten Builds zur Warteschlange

Wenn Sie Änderungen erstellen möchten, die Sie in ein Shelveset eingefügt haben, können Sie einen privaten Build (auch als "Buddybuild" bekannt) verwenden, um die Änderungen am Code vor dem Einchecken zu überprüfen. Wenn Sie einen privaten Build manuell in die Warteschlange stellen, wird Reason auf ValidateShelveset festgelegt. Weitere Informationen zum Hinzufügen eines privaten Builds zur Warteschlange finden Sie unter Stellen eines Builds in die Warteschlange.

Verwenden von benutzerdefiniertem Code zum Erstellen eines abgeschlossenen Builds

Mithilfe von Klassen im Microsoft.TeamFoundation.Build-Namespace können Sie benutzerdefinierten Code entwickeln, der einen abgeschlossenen Build erstellt. Wenn ein Build auf diese Weise in die Warteschlange gestellt wurde, wird Reason auf UserCreated festgelegt. Weitere Informationen finden Sie unter Extending Team Foundation: Build.

Arbeiten mit Buildtriggern und -gründen

Sie können Trigger und Gründe im Buildprozess wie folgt verwenden:

• Legen Sie den Trigger für den Buildprozess fest: Klicken Sie in der Builddefinition auf die Registerkarte Trigger, und wählen Sie dann den Trigger aus, der den Anforderungen des Teams am besten entspricht. Weitere Informationen zum Erstellen einer Builddefinition finden Sie unter Erstellen einer einfachen Builddefinition.

• Definieren Sie, welche Buildgründe von einem benutzerdefinierten Buildprozess akzeptiert werden: Sie können die InvokeForReason-Aktivität verwenden, um ein Segment des Buildprozesses einzuschließen, das nur in Builds ausgeführt werden soll, die aus einem bestimmten Grund ausgeführt wurden. Weitere Informationen finden Sie unter Einschränken bestimmter Abschnitte des Buildprozesses nach der Ursache (Trigger) (InvokeForReason-Aktivität).

Änderungsprotokoll