Share via

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

  • Artikel

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 eine Definition für abgegrenzte Eincheckbuilds erstellen, um CodeBase ganz oder teilweise gegen dieses Problem zu schützen.

In diesem Thema

  • Auswirkungen abgegrenzter Eincheckbuilds auf das Team

  • Definieren eines abgegrenzten Eincheckbuilds

  • Richtlinien für Einstellungen auf der Registerkarte "Prozess"

  • Ausführen abgegrenzter Eincheckbuilds

    • Automatisches Ausführen abgegrenzter Eincheckbuilds

    • Manuelles Ausführen abgegrenzter Eincheckbuilds und privater Builds

Auswirkungen abgegrenzter Eincheckbuilds auf das Team

Wenn ein abgegrenzter Eincheckbuild erstellt wird, müssen vom Entwickler übermittelte Änderungen in ein Shelveset eingefügt und im Buildsystem automatisch erstellt werden. Der Eincheckvorgang wird nur abgeschlossen, wenn der Build erfolgreich ist. Weitere Informationen finden Sie unter Einchecken ausstehender Änderungen für einen abgegrenzten Eincheckbuild.

Muss der abgegrenzte Eincheckvorgang für einige Benutzer umgehbar sein, können Sie die Berechtigung Eincheckvalidierung durch den Build außer Kraft setzen für eine Gruppe von Benutzern auf Zulassen festlegen. Weitere Informationen finden Sie unter Team Foundation Server-Berechtigungen.

Definieren eines abgegrenzten Eincheckbuilds

Erforderliche Berechtigungen

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

So definieren Sie einen abgegrenzten Eincheckbuild

  1. Klicken Sie in Team Explorer auf ein Teamprojekt.

  2. Klicken Sie im Menü Erstellen auf Neue Builddefinition.

    Das Fenster Neue Builddefinition wird mit der Registerkarte Allgemein angezeigt.

  3. Geben Sie im Feld Builddefinitionsname einen Namen ein.

  4. Klicken Sie auf der Registerkarte Trigger auf Abgegrenzter Eincheckvorgang - Eincheckvorgänge nur akzeptieren, wenn sich die übermittelten Änderungen erfolgreich zusammenführen und erstellen lassen.

  5. Klicken Sie auf die Registerkarte Arbeitsbereich.

    Die Tabelle Arbeitsordner wird angezeigt. In dieser Tabelle sind die Versionskontrollordner, die von dieser Builddefinition gesteuert werden, lokalen Ordnern im Build-Agent zugeordnet. Weitere Informationen finden Sie unter Löschen eines abgeschlossenen Builds.

    Tipp

    Stellen Sie sicher, dass ein Versionskontrollordner, den Sie für diese Definition angeben, nicht auch auf der Registerkarte Arbeitsbereich der Definition eines anderen abgegrenzten Eincheckbuilds angegeben ist. Andernfalls wird eine Person, die Dateien in diesen Ordnern eincheckt, vom System aufgefordert zu entscheiden, welche Builddefinition in die Warteschlange gestellt werden soll.

  6. Klicken Sie auf die Registerkarte Prozess, und legen Sie die Buildprozessparameter so fest, dass beim Einchecken die spezifischen Codequalitätsstandards Ihres Teams eingehalten werden.

    Bei einer umfangreichen, von einem großen Team erzeugten CodeBase sollten Sie das Ziel der Codequalitätsprüfung gegen das Ziel abwägen, unnötige Verzögerungen für die Entwickler zu vermeiden. Weitere Informationen finden Sie weiter unten in diesem Thema unter Richtlinien für Einstellungen auf der Registerkarte "Prozess".

  7. Klicken Sie auf die Registerkarten Build-Standardwerte und Beibehaltungsrichtlinie, und übernehmen Sie auf beiden Registerkarten die geeigneten Einstellungen.

    Weitere Informationen finden Sie unter Erstellen einer einfachen Builddefinition.

Richtlinien für Einstellungen auf der Registerkarte "Prozess"

Berücksichtigen Sie beim Angeben von Werten für die Buildprozessparameter auf der Registerkarte Prozess die folgenden Richtlinien, um den Zeitaufwand bei der Buildverarbeitung zu verringern.

Erforderlicher Knoten

  • Zu erstellende Dokumente, Zu erstellende Konfigurationen: Wenn Sie für diesen Parameter keinen Wert angeben, werden für jede Lösung und jedes Projekt die Standardplattform und die Standardkonfiguration verwendet. Halten Sie sich zur Optimierung der Leistung an die folgenden Richtlinien:

    • Wird eine Kombination aus Plattform und Konfiguration schneller erstellt als andere Kombinationen, geben Sie diese Kombination in diesem Parameter an.

    • Geben Sie möglichst wenige Kombinationen aus Plattform und Konfiguration an.

Knoten "Standard"

  • Automatisierte Tests: Wenn der Code bestimmte Tests bestehen muss, um gültig zu sein, richten Sie zum Ausführen der erforderlichen Tests einen Testlauf ein. Filtern Sie beim Einrichten des Testlaufs nach Kategorie oder Priorität, sodass lediglich die wichtigsten Tests ausgeführt werden. Weitere Informationen finden Sie unter Definieren eines Builds mithilfe der Standardvorlage.

  • Arbeitsbereich bereinigen: Legen Sie diesen Wert auf Keine (empfohlen) oder auf Ausgaben fest. Einige Typen von Fehlern werden jedoch mit höherer Wahrscheinlichkeit nicht erkannt, wenn der Arbeitsbereich nicht bereinigt wurde. Weitere Informationen finden Sie unter Definieren eines Builds mithilfe der Standardvorlage.

  • Codeanalyse ausführen: Legen Sie diesen Wert auf Nie fest.

  • Quell- und Symbolservereinstellungen, Quellen indizieren: Legen Sie diesen Wert auf False fest.

Knoten "Erweitert"

  • Agent-Einstellungen

    • Namensfilter oder Tagfilter: Verwenden Sie einen Build-Agent-Namen oder ein Tag, um diese Builddefinition an einen Build-Agent zu binden, der ausdrücklich zum Ausführen dieses Builds entworfen wurde. Der Build-Agent sollte auf einem Buildcomputer mit Hardware ausgeführt werden, die leistungsstark genug ist, dass dieser Build für die Leistungserwartungen Ihres Teams ausreichend schnell verarbeitet wird.

      Möglicherweise haben die Entwickler im Team nichts dagegen einzuwenden, 15 Minuten auf das Fertigstellen des Builds zu warten. Es ist jedoch unwahrscheinlich, dass die Entwickler eine Wartezeit von acht Stunden akzeptieren, bis sie bestimmen können, ob der Code erfolgreich eingecheckt wurde.

    • Maximale Ausführzeit: Legen Sie diesen Wert auf eine angemessen kleine Anzahl aufeinander folgender Integrationsbuilds fest. So können 15 Minuten für Ihr Team akzeptabel sein, während acht Stunden vermutlich zu lang sind.

  • Ausgaben in Ablageordner kopieren: Dieser Wert wird vom System als False interpretiert. Dies gilt auch, wenn der Wert auf True festgelegt wird.

  • Bei Fehler Arbeitsaufgabe erstellen: Dieser Wert wird vom System als False interpretiert. Dies gilt auch, wenn der Wert auf True festgelegt wird.

  • Quellen mit Bezeichnungen versehen: Legen Sie diesen Wert auf False fest.

Weitere Informationen zum Festlegen der Werte von Buildprozessparametern finden Sie unter Definieren eines Builds mithilfe der Standardvorlage.

Ausführen abgegrenzter Eincheckbuilds

Jede Definition eines abgegrenzten Eincheckbuilds darf lediglich einen einzelnen ausgeführten Build besitzen. Aus diesem Grund kommen umfangreiche Warteschlangen mit abgegrenzten Eincheckbuilds eher bei großen, aktiven Teams vor. Mithilfe der folgenden Best Practices lassen sich Blockaden vermeiden:

  • Verwenden Sie für den Build-Agent, der in der Definition des abgegrenzten Eincheckbuilds verwendet wird, einen dedizierten Buildcomputer mit leistungsfähiger Hardware (beispielsweise mit einem schnellen Prozessor und einer schnellen Festplatte).

  • Definieren Sie den Build, sodass vom Build-Agent lediglich die Aufgaben ausgeführt werden, die zum Überprüfen der Qualität des eingecheckten Codes erforderlich sind. Weitere Informationen finden Sie weiter oben in diesem Thema unter Richtlinien für Einstellungen auf der Registerkarte "Prozess".

Abgegrenzte Eincheckbuilds können entweder automatisch oder manuell ausgeführt werden.

Automatisches Ausführen abgegrenzter Eincheckbuilds

Ein abgegrenzter Eincheckbuild wird automatisch ausgeführt, wenn eines der folgenden Ereignisse auftritt:

  • Beim Definieren eines Builds wurde auf der Registerkarte Trigger das Kontrollkästchen Abgegrenzter Eincheckvorgang aktiviert.

  • Von einer Person wird versucht, mindestens eine Änderung einzuchecken, die sich mit einem zugeordneten Ordner auf der Registerkarte Arbeitsbereich der Builddefinition überschneidet.

Manuelles Ausführen abgegrenzter Eincheckbuilds und privater Builds

Entwickler, die sich bei einzucheckenden Änderungen nicht ganz sicher sind, können der Warteschlange manuell einen Build eines Shelvesets hinzufügen. Bei dieser Vorgehensweise stehen zwei Optionen zur Fortsetzung des Vorgangs zur Verfügung, sofern der Buildvorgang erfolgreich ist:

  • Die Änderungen werden eingecheckt (manueller abgegrenzter Eincheckbuild): Diese Option eignet sich für Entwickler, die ihren Code vor dem Einchecken zwar überprüfen möchten, aber in einem Team arbeiten, von dem der Trigger für abgegrenzte Eincheckvorgänge nicht verwendet wird.

  • Die Änderungen werden nicht eingecheckt (privater Build): Mit dieser Option können Entwickler Änderungen in einem Shelveset überprüfen, ohne sie einzuchecken.

Weitere Informationen finden Sie unter Stellen eines Builds in die Warteschlange.