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

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.

In diesem Thema

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

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 Buildprozesses mit abgegrenztem Eincheckvorgang

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. In Team Explorer:

   1. Wenn Sie nicht bereits über eine Verbindung mit dem Teamprojekt verfügen, in dem Sie arbeiten möchten, stellen Sie eine Verbindung mit dem Teamprojekt her.

   2. Wählen Sie Startseite und dann die Option Builds aus.

   3. Klicken Sie auf der Seite Builds auf Neue Builddefinition.

   Das Fenster "Neue Builddefinition" wird angezeigt.

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

3. Ordnen Sie auf der Registerkarte Arbeitsbereich 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.

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

5. Auf der Registerkarte Prozess unter Buildprozessvorlage ist standardmäßig die Standardvorlage ausgewählt.Geben Sie im Parameter Zu erstellende Dokumente die Projektmappen oder Codeprojekte an, die Sie erstellen möchten.

6. 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 Richtlinien zur Verbesserung der Funktion und Leistung des Buildprozesses.

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

Richtlinien zur Verbesserung 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.

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"

• Arbeitsbereich bereinigen: Legen Sie diesen Wert auf Keine (empfohlen) oder auf Ausgaben fest, um die Schnelligkeit zu erhöhen.Einige Arten von Fehlern, die z. B. während der Umgestaltung auftreten, werden vom Team jedoch weniger häufig erkannt, wenn der Arbeitsbereich nicht bereinigt wurde.Weitere Informationen finden Sie unter Definieren eines auf der Standardvorlage basierenden Buildprozesses.

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

• Quell- und Symbolservereinstellungen, Quellen indizieren: Legen Sie diesen Wert auf False fest, um eine bessere Leistung zu erzielen.

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

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

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

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

Weitere Informationen zu Buildprozessparametern der Standardvorlage finden Sie unter Definieren eines auf der Standardvorlage basierenden Buildprozesses.

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 Stellen eines Builds in die Warteschlange.