Erstellen mehrerer Branches

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Sie können jede Commit- und Pullanforderung für Ihr Git-Repository mithilfe von Azure-Pipelines oder TFS erstellen. In diesem Lernprogramm diskutieren wir zusätzliche Überlegungen beim Erstellen mehrerer Zweigstellen im Git-Repository. Sie lernen Folgendes:

  • Einrichten eines CI-Triggers für Themenzweige
  • Automatisches Erstellen einer Änderung in Der Themenzweig
  • Ausschließen oder Einschließen von Vorgängen für Builds basierend auf der Erstellung des Branchs
  • Halten Sie die Codequalität hoch, indem Sie Pull-Anforderungen erstellen
  • Verwenden von Aufbewahrungsrichtlinien zum Bereinigen abgeschlossener Builds

Voraussetzungen

  • Sie benötigen ein Git-Repository in Azure Pipelines, TFS oder GitHub mit Ihrer App. Wenn Sie keines haben, empfehlen wir, die Beispiel-.NET Core-App in Ihr Azure-Pipelines- oder TFS-Projekt zu importieren oder sie in Ihr GitHub-Repository zu erstellen. Beachten Sie, dass Sie Azure-Pipelines verwenden müssen, um ein GitHub-Repository zu erstellen. Sie können TFS nicht verwenden.

  • Sie benötigen auch einen arbeitsfähigen Build für Ihr Repository.

Einrichten eines CI-Triggers für einen Themenzweig

Ein allgemeiner Workflow mit Git besteht darin, temporäre Zweigstellen aus Ihrem Hauptzweig zu erstellen. Diese Zweigstellen werden als Themen- oder Featurezweige bezeichnet und helfen Ihnen dabei, Ihre Arbeit zu isolieren. In diesem Workflow erstellen Sie einen Zweig für ein bestimmtes Feature oder eine Fehlerkorrektur. Schließlich führen Sie den Code wieder mit der Hauptzweigung zusammen und löschen sie die Themenzweige.

Es sei denn, Sie geben einen Trigger in Ihrer YAML-Datei an, eine Änderung in einer der Zweige löst einen Build aus. Fügen Sie den folgenden Codeausschnitt zu Ihrer YAML-Datei in der main Zweigstelle hinzu. Dies führt dazu, dass Änderungen an main und feature/* Zweigstellen automatisch erstellt werden.

trigger:
- main
- feature/*

YAML-Builds sind noch nicht auf TFS verfügbar.

Automatisches Erstellen einer Änderung in Der Themenzweig

Sie sind jetzt bereit für CI für die Hauptzweige und zukünftige Feature-Branchs, die dem Verzweigungsmuster entsprechen. Jede Codeänderung für den Zweig verwendet eine automatisierte Buildpipeline, um sicherzustellen, dass die Qualität Ihres Codes hoch bleibt.

Führen Sie die folgenden Schritte aus, um eine Datei zu bearbeiten und einen neuen Themenzweig zu erstellen.

  1. Navigieren Sie zu Ihrem Code in Azure Repos, TFS oder GitHub.
  2. Erstellen Sie einen neuen Zweig für Ihren Code, der mit feature/dem Code beginnt, z. B. feature/feature-123.
  3. Ändern Sie Ihren Code in der Featurezweigung, und setzen Sie die Änderung fest.
  4. Navigieren Sie zum Menü "Pipelines" in Azure Pipelines oder TFS, und wählen Sie "Builds" aus.
  5. Wählen Sie die Buildpipeline für dieses Repo aus. Jetzt sollte ein neuer Build angezeigt werden, der für den Themenzweig ausgeführt wird. Dieser Build wurde durch den zuvor erstellten Trigger initiiert. Warten Sie, bis der Buildvorgang abgeschlossen ist.

Der typische Entwicklungsprozess umfasst die lokale Entwicklung von Code und regelmäßigen Pushen an Ihre Remotethema-Zweigstelle. Jeder Push führt zu einer Buildpipeline, die im Hintergrund ausgeführt wird. Die Buildpipeline hilft Ihnen beim Früheren Abfangen von Fehlern und hilft Ihnen, einen qualitätsbezogenen Themenzweig zu erhalten, der sicher mit dem Haupt zusammengeführt werden kann. Das Üben von CI für Ihre Themenzweige hilft beim Zusammenführen mit dem Hauptrisiko zu minimieren.

Ausschließen oder Einschließen von Vorgängen für Builds basierend auf der Erstellung des Branchs

Der Hauptzweig erzeugt in der Regel bereitstellungsfähige Artefakte wie Binärdateien. Sie müssen keine Zeit verbringen, diese Artefakte für kurzlebige Featurezweige zu erstellen und zu speichern. Sie implementieren benutzerdefinierte Bedingungen in Azure Pipelines oder TFS, sodass bestimmte Aufgaben nur in Ihrem Hauptzweig während einer Buildausführung ausgeführt werden. Sie können einen einzelnen Build mit mehreren Zweigen verwenden und bestimmte Aufgaben basierend auf Bedingungen überspringen oder ausführen.

Bearbeiten Sie die azure-pipelines.yml Datei in Ihrer Zweigstelle, suchen Sie eine Aufgabe in Ihrer main YAML-Datei, und fügen Sie eine Bedingung hinzu. Der folgende Codeausschnitt fügt beispielsweise eine Bedingung hinzu, um Artefakte zu veröffentlichen .

- task: PublishBuildArtifacts@1
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

YAML-Builds sind noch nicht auf TFS verfügbar.

Überprüfen von Pullanforderungen

Verwenden Sie Richtlinien, um Ihre Zweigen zu schützen, indem Sie erfolgreiche Builds benötigen, bevor Sie Pullanforderungen zusammenführen. Sie haben Optionen, immer einen neuen erfolgreichen Build zu benötigen, bevor Änderungen an wichtigen Zweigen wie dem Hauptzweig zusammengeführt werden. Es gibt andere Zweigrichtlinieneinstellungen, die weniger häufig erstellt werden sollen. Sie können auch eine bestimmte Anzahl von Codeüberprüfungen benötigen, um sicherzustellen, dass Ihre Pullanforderungen hochqualität sind und nicht zu fehlerhaften Builds für Ihre Zweigstellen führen.

GitHub-Repository

Es sei denn, Sie geben Trigger in Ihrer YAML-Datei an pr , werden Pull-Anforderungsbuilds automatisch für alle Zweigen aktiviert. Sie können die Zielzweige für Ihre Pull-Anforderungsbuilds angeben. Zum Ausführen des Builds nur für Pullanforderungen, die zielsziel sind: main und feature/*:

pr:
- main
- feature/*

Weitere Details finden Sie unter Trigger.

YAML-Builds sind noch nicht auf TFS verfügbar.

Azure-Pipelines oder TFS-Repository

  1. Navigieren Sie zum Repos-Hub in Azure Repos oder TFS.
  2. Wählen Sie Ihr Repository aus, und wählen Sie "Verzweigungen" aus. Wählen Sie den Hauptzweig aus.
  3. Sie implementieren eine Verzweigungsrichtlinie, um den Hauptzweig zu schützen. Wählen Sie die Auslassungspunkte rechts neben Ihrem Zweignamen aus, und wählen Sie Branch-Richtlinien aus.
  4. Wählen Sie das Kontrollkästchen für den Schutz dieses Zweigs aus. Es gibt mehrere Optionen zum Schützen des Zweigs.
  5. Wählen Sie im Menü " Überprüfung erstellen" die Option "Buildrichtlinie hinzufügen" aus.
  6. Wählen Sie die entsprechende Buildpipeline aus.
  7. Stellen Sie sicher, dass Der Trigger auf automatisch festgelegt ist und die Richtlinienanforderung auf erforderlich festgelegt ist.
  8. Geben Sie einen beschreibenden Anzeigenamen ein, um die Richtlinie zu beschreiben.
  9. Wählen Sie "Speichern " aus, um die Richtlinie zu erstellen und zu aktivieren. Wählen Sie "Änderungen speichern " oben links auf dem Bildschirm aus.
  10. Um die Richtlinie zu testen, navigieren Sie zum Pull-Anforderungsmenü in Azure Pipelines oder TFS.
  11. Wählen Sie New pull request aus. Stellen Sie sicher, dass Ihr Themenzweig auf die Zusammenführung in Ihre Hauptzweige festgelegt ist. Klicken Sie auf Erstellen.
  12. Ihr Bildschirm zeigt die ausgeführte Richtlinie an.
  13. Wählen Sie den Richtliniennamen aus, um den Build zu untersuchen. Wenn der Build erfolgreich ist, wird Ihr Code mit dem Haupt zusammengeführt. Wenn der Build fehlschlägt, wird die Zusammenführung blockiert.

Sobald die Arbeit im Themenzweig abgeschlossen und mit dem Haupt zusammengeführt wurde, können Sie Ihre Themenzweige löschen. Anschließend können Sie zusätzliche Feature- oder Bugfix-Verzweigungen wie erforderlich erstellen.

Wichtig

Azure Pipelines unterstützt keine Aufbewahrungsrichtlinien pro Pipeline mehr. Wir empfehlen die Verwendung von Aufbewahrungsregeln auf Projektebene.

Verwenden von Aufbewahrungsrichtlinien zum Bereinigen Ihrer abgeschlossenen Builds

Aufbewahrungsrichtlinien ermöglichen Es Ihnen, die Bereinigung Ihrer verschiedenen Builds zu steuern und zu automatisieren. Bei kürzeren Verzweigungen wie Themenzweigen möchten Sie möglicherweise weniger Verlauf beibehalten, um die Clutter- und Speicherkosten zu verringern. Wenn Sie CI-Builds auf mehreren verwandten Zweigen erstellen, wird es weniger wichtig, Builds für alle Ihre Niederlassungen beizubehalten.

  1. Navigieren Sie zum Menü "Pipelines" in Azure Pipelines oder TFS.

  2. Suchen Sie die Buildpipeline, die Sie für Ihr Repo eingerichtet haben.

  3. Wählen Sie oben rechts auf dem Bildschirm bearbeiten aus.

  4. Wählen Sie unter dem Namen der Buildpipeline die Registerkarte "Aufbewahrung " aus. Wählen Sie " Hinzufügen " aus, um eine neue Aufbewahrungsrichtlinie hinzuzufügen.

    Aufbewahrungsmenü

  5. Typfeature/* in der Dropdownliste "Branch-Spezifikation" Dadurch wird sichergestellt, dass alle Funktionszweige, die dem Wildcard entsprechen, die Richtlinie verwenden.

  6. Legen Sie "Tage" fest, um auf 1 und Mindestens zu halten, um auf 1 zu bleiben.

  7. Wählen Sie das Menü "Warteschlange speichern&" und dann "Speichern" aus.

Richtlinien werden in der Reihenfolge ausgewertet, indem die erste übereinstimmende Richtlinie auf jeden Build angewendet wird. Die Standardregel unten entspricht allen Builds. Die Aufbewahrungsrichtlinie bereinigt die Ressourcen jeden Tag. Sie behalten mindestens einen Build jederzeit bei. Sie können auch einen bestimmten Build für eine unbegrenzte Zeit beibehalten.

Nächste Schritte

In diesem Lernprogramm haben Sie gelernt, wie Sie CI für mehrere Zweigstellen in Ihren Git-Repositorys mithilfe von Azure Pipelines oder TFS verwalten.

Sie haben Folgendes gelernt:

  • Einrichten eines CI-Triggers für Themenzweige
  • Automatisches Erstellen einer Änderung in Der Themenzweig
  • Ausschließen oder Einschließen von Vorgängen für Builds basierend auf der Erstellung des Branchs
  • Halten Sie die Codequalität hoch, indem Sie Pull-Anforderungen erstellen
  • Verwenden von Aufbewahrungsrichtlinien zum Bereinigen abgeschlossener Builds