Erstellen von TFVC-Repositorys

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

Wichtig

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

Auswählen des zu erstellenden Repositorys

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

• Sauber
• Lokalen Pfad angeben
• Bezeichnen von Quellen

Repositoryname

Name des TFVC-Repositorys.

Zuordnungen (Arbeitsbereich)

Fügen Sie einen Typwert von Zuordnung nur die Ordner hinzu, die ihre Buildpipeline erfordert. Wenn ein Unterordner eines zugeordneten Ordners Dateien enthält, die von der Buildpipeline nicht benötigt werden, ordnen Sie ihn einem Typwert von Cloakzu.

Stellen Sie sicher, dass Sie Zuordnen alle Ordner, die Dateien enthalten, die ihre Buildpipeline erfordert. Wenn Sie beispielsweise ein weiteres Projekt hinzufügen, müssen Sie möglicherweise dem Arbeitsbereich eine weitere Zuordnung hinzufügen.

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 im Versionssteuerungsordner Ihres Projekts herunter lädt. Wenn dieser Ordner viele Daten enthält, könnte Ihr Build Systemressourcen verschwenden und die Buildpipeline verlangsamen, indem große Datenmengen heruntergeladen werden, die nicht benötigt 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 den Filtereinstellungen Ihres CI-Triggers auf der Registerkarte Triggersentsprechen.

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

Bereinigen des lokalen Repositorys für den Agent

Es gibt verschiedene Möglichkeiten zum Bereinigen des Arbeitsverzeichnisses Ihres selbstgehosteten Agents, 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 jedes Mal in diesem Fall einen neuen Agent erhalten.

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

• Quellen: Die Buildpipeline führt eine Rückgängigmachen aller Änderungen durch und schneidet den aktuellen Arbeitsbereich unter $(Build.SourcesDirectory).

• Quellen und Ausgabeverzeichnis: Dies ist der gleiche Vorgang wie bei der oben beschriebenen Option Quellen, zusätzlich wird $(Build.BinariesDirectory) gelöscht und neu erstellt.

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

• Alle Buildverzeichnisse: Löscht $(Agent.BuildDirectory) und erstellt es neu.

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, wenn ein Build ausgeführt wird, bis der Build abgeschlossen ist, und wartet dann einen anderen Build aller Änderungen, die noch nicht erstellt wurden.

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

Pfadfilter

Wählen Sie die Versionssteuerungspfade 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 den Satz von Dateien zu reduzieren, die Sie einen Build auslösen möchten.

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 deaktivieren und die Pfade im Trigger angeben.

Auswirkungen auf Ihre Entwickler

Wenn Entwickler versuchen, sich einzuchecken, werden sie aufgefordert, ihre Änderungen zu erstellen.

Das System erstellt dann ein Regal und erstellt es.

Hinweis

Wenn sie einen Fehler wie The shelveset _Build_95;Build\6bc8a077-3f27-4936-82e6-415fbd53ba07 could not be found for check-inerhalten, überprüfen Sie den Grenzwert für die Auftragsautorisierung auf das aktuelle Projekt für Nicht-Release-Pipelines Einstellung, und stellen Sie sicher, dass er nicht aktiviert ist.

Ausführliche Informationen zur Gated Check-In-Erfahrung finden Sie unter Einchecken in einem Ordner, der von einer gated Check-In-Buildpipelinegesteuert wird.

Option zum Ausführen von CI-Builds

Standardmäßig werden CI-Builds nicht ausgeführt, nachdem der Check-In-Prozess abgeschlossen ist und die Änderungen eingecheckt werden.

Wenn Sie jedoch möchten, dass CI-Builds nach einem Eingecheckt ausgeführt werden, aktivieren Sie die CI-Trigger für zugesicherte Änderungen Kontrollkästchen ausführen. Wenn Sie dies tun, fügt die Buildpipeline keine ***NO_CI*** zur Beschreibung des Changeset hinzu. Daher werden CI-Builds ausgeführt, die von der Überprüfung betroffen sind.

Ein paar andere Dinge zu wissen

• Stellen Sie sicher, dass die Ordner, die Sie in Den Trigger einfügen, auch in Ihren Arbeitsbereichszuordnungen enthalten sind.
• Sie können Gated-Builds entweder auf einem von Microsoft gehosteten Agent oder einem selbst gehosteten Agentausfü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 ihr Auftragsautorisierungsbereich auf Sammlungfestgelegt? 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 in der Projekteinstellung unter 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

• Dies ist in der Regel ein zeitweiliger Fehler, der verursacht wird, wenn der Dienst technische Probleme aufweist. Führen Sie die Pipeline erneut aus.

Was ist Scorch?

Scorch ist ein TFVC-Energietool, das sicherstellt, dass die Quellcodeverwaltung auf dem Server und der lokale Datenträger identisch sind. Siehe Microsoft Visual Studio Team Foundation Server 2015 Power Tools.