Erstellen von TFVC-Repositorys

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Wichtig

TFVC wird nur von klassischen Pipelines unterstützt, YAML wird nicht unterstützt.

Auswählen des zu erstellenden Repositorys

Beim Bearbeiten einer Pipeline, die ein TFVC-Repository verwendet, stehen Ihnen die folgenden Optionen zur Auswahl.

• Clean
• Lokalen Pfad angeben
• Bezeichnen von Quellen

Name des Repositorys

Name des TFVC-Repositorys.

Zuordnungen (Arbeitsbereich)

Schließen Sie mit dem Typwert Map (Zuordnen) nur die Ordner ein, die für Ihre Buildpipeline erforderlich sind. Wenn ein Unterordner eines zugeordneten Ordners Dateien enthält, die für die Buildpipeline nicht benötigt werden, ordnen Sie ihm den Typwert Cloak (Verdecken) zu.

Stellen Sie sicher, dass Sie alle Ordner mit Map einschließen, die Ihre Buildpipeline benötigt. Wenn Sie beispielsweise ein weiteres Projekt hinzufügen, müssen Sie möglicherweise dem Arbeitsbereich eine weitere Zuordnung hinzufügen.

Cloak-Ordner, die Sie nicht benötigen. Standardmäßig wird der Stammordner des Projekts im Arbeitsbereich zugeordnet. Diese Konfiguration führt dazu, dass der Build-Agent alle Dateien in den Versionskontrollordner des Projekts herunterlädt. Wenn dieser Ordner große Datenmengen enthält, werden für den Build möglicherweise Systemressourcen verschwendet, und Ihre Buildpipeline wird verlangsamt, da umfangreiche nicht erforderliche Datenmengen heruntergeladen werden.

Wenn Sie Projekte entfernen, suchen Sie nach Zuordnungen, die Sie aus dem Arbeitsbereich entfernen können.

Wenn es sich um einen CI-Build handelt, sollten Sie in den meisten Fällen sicherstellen, dass diese Zuordnungen mit den Filtereinstellungen Ihres CI-Triggers auf der Registerkarte Trigger übereinstimmen.

Weitere Informationen zum Optimieren eines TFVC-Arbeitsbereichs finden Sie unter Optimieren Ihres Arbeitsbereichs.

Bereinigen des lokalen Repositorys für den Agent

Sie können das Arbeitsverzeichnis Ihres selbstgehosteten Agents auf verschiedene Arten bereinigen, bevor ein Build ausgeführt wird.

Im Allgemeinen sollten Sie das Repository nicht bereinigen, um die Leistung Ihrer selbstgehosteten Agents zu erhöhen. Um die beste Leistung zu erzielen, sollten Sie in diesem Fall auch sicherstellen, dass die Erstellung inkrementell erfolgt. Deaktivieren Sie dazu die Option Bereinigen der Aufgabe oder des Tools, die bzw. das Sie zur Builderstellung verwenden.

Wenn Sie das Repository bereinigen müssen (z. B. um Probleme zu vermeiden, die durch verbleibende Dateien aus einem früheren Build verursacht werden), haben Sie folgende Möglichkeiten.

Hinweis

Die Reinigung ist nicht relevant, wenn Sie einen von Microsoft gehosteten Agent verwenden, da Sie in diesem Fall jedes Mal einen neuen Agent erhalten.

Wenn Sie das Repository sauber möchten, wählen Sie true und dann eine der folgenden Optionen aus:

• Quellen: Die Buildpipeline führt eine Rollbackphase aller Änderungen durch und führt Scorch für den aktuellen Arbeitsbereich unter $(Build.SourcesDirectory) aus.

• Quellen und Ausgabeverzeichnis: Gleicher Vorgang wie bei der obigen Option Quellen, und zusätzlich wird $(Build.BinariesDirectory) gelöscht und neu erstellt.

• Quellenverzeichnis: Löscht $(Build.SourcesDirectory) und erstellt das Verzeichnis neu.

• Alle Buildverzeichnisse:$(Agent.BuildDirectory) wird gelöscht und neu erstellt.

CI-Trigger

Wählen Sie auf der Registerkarte Trigger die Option Continuous Integration aktivieren aus, um diesen Trigger zu aktivieren, wenn der Build ausgeführt werden soll, sobald jemand Code eincheckt.

Batchänderungen

Aktivieren Sie dieses Kontrollkästchen, wenn viele Teammitglieder häufig Änderungen hochladen und Sie die Anzahl der ausgeführten Builds reduzieren möchten. Wenn Sie diese Option auswählen, wartet das System bei der Ausführung eines Builds, bis dieser abgeschlossen ist, und reiht dann einen weiteren Build mit allen Änderungen, die noch nicht kompiliert wurden, in die Warteschlange ein.

Sie können Änderungen in einem Batch zusammenfassen und gemeinsam kompilieren.

Pfadfilter

Wählen Sie die Versionskontrollpfade aus, die Sie einschließen und ausschließen möchten. In den meisten Fällen sollten Sie sicherstellen, dass diese Filter mit Ihren TFVC-Zuordnungen konsistent sind. Sie können Pfadfilter verwenden, um die Dateien zu reduzieren, die einen Build auslösen sollen.

Tipps:

• Pfade werden immer relativ zum Stamm des Arbeitsbereichs angegeben.
• Wenn Sie keine Pfadfilter festlegen, wird der Stammordner des Arbeitsbereichs standardmäßig implizit eingeschlossen.
• Wenn Sie einen Pfad ausschließen, können Sie ihn nicht gleichzeitig einschließen, es sei denn, Sie qualifizieren ihn in einem Ordner auf einer tieferen Ebene. Wenn Sie beispielsweise /tools ausschließen, können Sie /tools/trigger-runs-on-these einschließen.
• Die Reihenfolge der Pfadfilter spielt keine Rolle.

Gated-Check-In

Sie können Gated-Check-In verwenden, um vor Breaking Changes zu schützen.

Standardmäßig ist Arbeitsbereichszuordnungen für Filter verwenden ausgewählt. Builds werden immer dann ausgelöst, wenn eine Änderung unter einem Pfad eingecheckt wird, der in Ihren Quellzuordnungen angegeben ist.

Andernfalls können Sie dieses Kontrollkästchen löschen und die Pfade im Trigger angeben.

Auswirkungen auf Ihre Entwickler*innen

Wenn Entwickler*innen versuchen, einen Check-In durchzuführen, werden sie aufgefordert, ihre Änderungen zu erstellen.

Das System erstellt dann ein Shelveset.

Hinweis

Wenn Sie einen Fehler wie The shelveset _Build_95;Build\6bc8a077-3f27-4936-82e6-415fbd53ba07 could not be found for check-in erhalten, überprüfen Sie die Einstellung Autorisierungsbereich für Auftrag für Nicht-Releasepipelines auf aktuelles Projekt begrenzen, und stellen Sie sicher, dass sie nicht aktiviert ist.

Ausführliche Informationen zur Gated-Check-In-Funktion finden Sie unter Einchecken in einen von einer Gated-Check-In-Buildpipeline gesteuerten Ordner.

Option zum Ausführen von CI-Builds

Standardmäßig werden CI-Builds nicht nach Abschluss des Gated-Check-In-Vorgangs abgeschlossen und wenn die Änderungen eingecheckt sind.

Wenn die CI-Builds aber nach einem Gated-Check-In ausgeführt werden sollen, aktivieren Sie das Kontrollkästchen CI-Trigger für committete Änderungen ausführen. Wenn Sie dies tun, fügt die Buildpipeline der Changesetbeschreibung nicht ***NO_CI*** hinzu. Daher werden CI-Builds ausgeführt, die von diesem Check-In betroffen sind.

Weitere wichtige Informationen

• Stellen Sie sicher, dass die Ordner, die Sie Ihren Trigger einfügen, auch in Ihren Arbeitsbereichszuordnungen enthalten sind.
• Sie können abgegrenzte Builds entweder auf einem von Microsoft gehosteten Agent oder auf einem selbstgehosteten Agent ausführen.

Häufig gestellte Fragen

Beim Ausführen einer Pipeline wird die folgende Fehlermeldung angezeigt:

The shelveset <xyz> could not be found for check-in

• Ist der Autorisierungsbereich für den Auftrag auf Sammlung festgelegt? TFVC-Repositorys sind in der Regel über die Projekte in Ihrer Sammlung verteilt. Möglicherweise lesen oder schreiben Sie in einen Ordner, auf den nur zugegriffen werden kann, wenn der Bereich die gesamte Sammlung ist. Sie können dies in den Organisationseinstellungen oder den Projekteinstellung auf der Registerkarte Pipelines festlegen.

Beim Ausführen einer Pipeline wird die folgende Fehlermeldung angezeigt:

The underlying connection was closed: An unexpected error occurred on a receive. ##[error]Exit code 100 returned from process: file name 'tf', arguments 'vc workspace /new /location:local /permission:Public

• In der Regel handelt es sich hierbei um einen zeitweiligen Fehler, der verursacht wird, wenn für den Dienst technische Probleme auftreten. Führen Sie die Pipeline erneut aus.

Was ist Scorch?

Scorch ist ein TFVC-Powertool, das sicherstellt, dass die Quellcodeverwaltung auf dem Server und der lokale Datenträger identisch sind. Weitere Informationen finden Sie unter Microsoft Visual Studio Team Foundation Server 2015 Power Tools.