Verwenden eines abgegrenzten Eincheckbuildprozesses zur Überprüfung von Ä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 aufgrund von Produktivitätsverlusten und Planungsverzögerungen noch höhere Kosten zukommen. Sie können Ihre Codebasis vollständig oder teilweise gegen diese Probleme schützen, indem Sie eine Builddefinition mit abgegrenztem Eincheckvorgang erstellen.

Hinweis

Abgegrenzte Eincheckbuilds sind nur in TFVC-Symbol-TFVC-Teamprojekten verfügbar.Sie sind nicht in Git-Symbol-Git-Teamprojekten verfügbar.

Was möchten Sie tun?

  • Auswirkungen von Builds mit abgegrenztem Eincheckvorgang auf das Team

  • Definieren eines Buildprozesses mit abgegrenztem Eincheckvorgang

  • Richtlinien zur Verbesserung der Funktion und Leistung des Buildprozesses

  • Vermeiden einer Blockierung des Teams

  • Manuelles Ausführen von Builds mit abgegrenztem Eincheckvorgang und privaten Builds

Auswirkungen von Builds mit abgegrenztem Eincheckvorgang auf das Team

Wenn Ihr Team einen Buildprozess mit abgegrenztem Eincheckvorgang einrichtet, werden von Entwicklern übermittelte Änderungen in Shelvesets angeordnet und vom Buildsystem automatisch erstellt und ggf. auch getestet.

Dialogfeld für abgegrenzten Eincheckvorgang

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 Berechtigungsreferenz für Team Foundation Server.

Definieren eines Buildprozesses mit abgegrenztem Eincheckvorgang

  1. 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).

  2. Wählen Sie den Link Neue Builddefinition oder wählen Sie ein Build aus, öffnen dann das Kontextmenü und wählen Builddefinition bearbeiten aus.

    Tipp

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

  3. Gehen Sie auf der Registerkarte Trigger wie folgt vor:

    • Wählen Sie Abgegrenzter Eincheckvorgang aus.

    • (Optional) Um die Effizienz des Buildprozesses zu erhöhen, wählen Sie Zusammenführen und für Übermittlungen n erstellen. Weitere Informationen finden Sie unter Vermeiden einer Blockierung des Teams.

  4. Ordnen Sie auf der Registerkarte Quelleinstellungen in der Tabelle Arbeitsordner die Versionskontrollordner, die von dieser Builddefinition gesteuert werden, den lokalen Ordnern im Build-Agent zu.

    Tipp

    Befolgen Sie die nachstehenden Richtlinien:

    • Um sicherzustellen, dass der Buildprozess ordnungsgemäß funktioniert, und um die Leistung zu verbessern, sollten Sie alle Ordner einbeziehen, in denen die für den Buildprozess erforderlichen Dateien enthalten sind (und nur diese Dateien).

    • Stellen Sie sicher, dass Sie keinen Versionskontrollordner angeben, der auch auf der Registerkarte Arbeitsbereich der Definition eines anderen Builds mit abgegrenztem Eincheckvorgang angegeben ist.Andernfalls wird ein Benutzer, der Dateien in diesen Ordnern eincheckt, vom Buildsystem aufgefordert zu entscheiden, welche Builddefinition in die Warteschlange gestellt werden soll.

    • Weitere Informationen zum Angeben dieser Zuordnungen finden Sie unter Arbeiten mit Buildarbeitsbereichen.

  5. Wählen Sie auf der Registerkarte Build-Standardwerte zur Verbesserung der Leistung die Option Von diesem Build werden keine Ausgabedateien in einen Ablageordner kopiert aus.

  6. Geben Sie auf der Registerkarte Prozess unter Build im Parameter Projekte die Projektmappen oder Codeprojekte an, die Sie erstellen möchten.

  7. Legen Sie auf der Registerkarte Prozess die Parameter fest, um sicherzustellen, dass beim Einchecken die geltenden Codequalität-Standards des Teams eingehalten werden, ohne dass für die Entwickler eine unnötige Verzögerung eintritt.

    Weitere Informationen finden Sie weiter unten in diesem Thema unter Verbesserung der Funktion und Leistung des Buildprozesses.

  8. Geben Sie die Optionen für den Buildprozess auf den anderen Registerkarten an. Weitere Informationen finden Sie unter Erstellen oder Bearbeiten einer Builddefinition.

Verbessern der Funktion und Leistung des Buildprozesses

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.

TF-Versionskontrolle oder Git

  • Arbeitsbereich bereinigen oder Bereinigtes Repository: Legen Sie diesen Wert für bessere Leistung auf False fest. Diese Einstellung verursacht möglicherweise, dass Ihr Team einige Typen von Fehlern übersieht, wie z. B. solche, die bei der Umgestaltung entstanden sind.

Build

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

  • Bereinigter Build Für schnellere Leistung, legen Sie diesen Parameter auf "False" fest. Diese Einstellung verursacht möglicherweise, dass Ihr Team einige Typen von Fehlern übersieht, wie z. B. solche, die bei der Umgestaltung entstanden sind.

Build, erweitert

  • Codeanalyse ausführen: Legen Sie diesen Wert auf Nie fest, um eine bessere Leistung zu erzielen.

Test, erweitert

  • Tests deaktivieren:

    • Legen Sie diese Option auf True fest, um eine höhere Leistung zu erzielen.

    • Wenn der Code bestimmte Tests bestehen muss, wählen Sie False aus. Definieren Sie dann einen Satz von Tests, die für den Build ausgeführt werden. Sie können die Leistung verbessern, indem Sie nur die für Sie erforderlichen Tests ausführen. Filtern Sie die Tests entweder nach Kategorie oder Priorität, um die Auswahl zu erleichtern. Weitere Informationen finden Sie unter Ausführen von Testläufen im Buildprozess.

Symbole veröffentlichen

  • Pfad zum Veröffentlichen von Symbolen: Für eine höhere Leistung lassen Sie diesen Wert leer.

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 Hardware ausgeführt werden, die über eine so hohe Leistungsstärke verfügt, dass dieser Build gemäß den Leistungserwartungen Ihres Teams ausreichend schnell verarbeitet wird.

      Möglicherweise haben Sie und Ihr Team nichts dagegen einzuwenden, wenn Sie 15 Minuten auf die Fertigstellung des Builds warten müssen. Es ist jedoch unwahrscheinlich, dass Sie eine Wartezeit von acht Stunden akzeptieren, bevor Sie ermitteln können, ob der Code erfolgreich eingecheckt wurde.

    • Maximale Ausführzeit: Geben Sie für diese Option einen relativ niedrigen Wert an. So können 15 Minuten für Ihr Team akzeptabel sein, während acht Stunden vermutlich zu lang sind.

Weitere Informationen zu Buildprozessparametern der Standardvorlage finden Sie unter Verwenden der Standardvorlage für Ihren Buildprozess.

Vermeiden einer Blockierung des Teams

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 des Teamfortschritts vermeiden:

  • Um den Buildprozess effizienter zu machen, wählen Sie auf der Registerkarte Trigger die Option Zusammenführen und für Übermittlungen n erstellen aus und geben die maximale Anzahl von Eincheckvorgängen an, die für einen Batch jeweils zusammen erstellt werden sollen. Normalerweise riskieren Sie mit dieser Option keine größeren Störungen. Für jeden Eincheckvorgang wird einzeln ein Commit ausgeführt bzw. jeder Eincheckvorgang wird einzeln abgelehnt.

    Wenn beispielsweise drei Eincheckvorgänge zusammen in einem Batch erstellt werden und der Build nicht folgt, stellt das System einzelne Builds aller drei Eincheckvorgänge in die Warteschlange.

    Bei dieser Option besteht jedoch das Risiko, dass ein Eincheckvorgang zur Beeinträchtigung anderer Eincheckvorgänge führt. Dies kann beispielsweise vorkommen, wenn bei mehreren Eincheckvorgängen dieselbe Datei geändert wird und ein Konflikt bei der Versionskontrolle auftritt. In diesem Fall wird für den früher erfolgten Eincheckvorgang ein Commit ausgeführt, und die späteren Eincheckvorgänge werden abgelehnt.

  • 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".

  • 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).

Manuelles Ausführen von Builds mit abgegrenztem Eincheckvorgang und privaten 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 gut für Teams, die einen abgegrenzten Eincheckvorgang nicht zwingend vorgeben möchten, aber die es Entwicklern ermöglichen möchten, den Code vor dem Einchecken freiwillig überprüfen zu lassen.

  • 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 Hinzufügen eines Builds zur Warteschlange.