Informationen zum Branching

  • 8 Minuten

Wenn Sie Bicep-Vorlagen erstellen und in einem Git-Repository arbeiten, werden alle Änderungen Ihres Teams schließlich mit dem Mainbranch Ihres Repositorys gemergt. Es ist wichtig, den Mainbranch zu schützen, damit keine unerwünschten Änderungen in Ihrer Produktionsumgebung bereitgestellt werden. Sie möchten jedoch auch, dass die Mitwirkenden flexibel arbeiten, mit Ihrem Team zusammenarbeiten und Ideen einfach ausprobieren können.

In dieser Lerneinheit erfahren Sie mehr über Branchingstrategien und das Schützen des Mainbranchs. Außerdem erfahren Sie, wie Sie einen Überprüfungsprozess für Ihre Branches einrichten können.

Warum sollten Sie den Mainbranch schützen?

Der Mainbranch ist die „Source of Turth“ für die Bereitstellung in Ihren Azure-Umgebungen. Bei einigen Lösungen verfügen Sie über mehrere Umgebungen (z. B. Entwicklung, Qualitätssicherung (QA) und Produktion). In anderen Szenarios ist möglicherweise nur eine Produktionsumgebung verfügbar. Unabhängig davon, wie viele Umgebungen Sie verwenden, ist der Mainbranch der Branch, zu dem Ihre Teammitglieder beitragen. Ihre Änderungen landen letztendlich auf dem Mainbranch.

Ein typischer Prozess kann folgendermaßen ablaufen:

  1. Ein Teammitglied klont Ihr freigegebenes Repository.
  2. Es nimmt lokale Änderungen an einem Branch in seiner eigenen lokalen Kopie des Repositorys vor.
  3. Wenn das Teammitglied mit den Änderungen fertig ist, mergt es diese Änderungen mit dem Mainbranch seines lokalen Repositorys.
  4. Diese Änderungen werden an den Mainbranch des Remoterepositorys gepusht.
  5. In einigen Szenarios löst der Push des Remoterepositorys eine automatisierte Pipeline aus, um den Code zu überprüfen, zu testen und bereitzustellen. In anderen Microsoft Learn-Modulen erfahren Sie mehr über Pipelines.

Dieser Prozess wird anhand des folgenden Diagramms veranschaulicht.

Abbildung: Durchführen von lokalen Änderungen, Pushen von Änderungen in den Remotemainbranch und Auslösen einer Pipeline

Angenommen, die vom Teammitglied vorgenommenen Änderungen führten zu einem geringfügigen Fehler. Nachdem der vollständige Prozess ausgeführt wurde, befindet sich der Fehler jetzt im Mainbranch des Projekts und wird in der Produktion bereitgestellt. Sie werden den Fehler möglicherweise erst finden, wenn Sie versuchen, den Branch bereitzustellen, und dann einen Fehler erhalten. Bei anderen Arten von Fehlern kann die Bereitstellung zwar erfolgreich sein, aber die Fehler führen später zu geringfügigen Problemen.

Angenommen, in einem anderen Szenario arbeitet ein Teammitglied an einem Feature und pusht die Hälfte der abgeschlossenen Arbeit am Feature an den Mainbranch des freigegebenen Repositorys. Sie verfügen nun über den Mainbranch mit Änderungen, die noch nicht abgeschlossen oder getestet wurden. Diese Änderungen sollten wahrscheinlich nicht in Ihrer Produktionsumgebung bereitgestellt werden. Bereitstellungen in der Produktion müssen möglicherweise blockiert werden, bis das Feature abgeschlossen ist. Wenn sich neu fertiggestellte Features im Mainbranch befinden, können Sie sie möglicherweise nicht für Ihre Kunden bereitstellen.

Tipp

Diese Probleme sind besonders schwierig für große Teams, bei denen mehrere Personen am gleichen Code arbeiten. Die Anleitung in diesem Modul ist jedoch nützlich, sobald Sie mit mehreren Personen zusammenarbeiten. Die Anleitung ist auch dann nützlich, wenn Sie nur an einem Projekt und gleichzeitig an mehreren Features arbeiten.

Sie sollten die Änderungen vorzugsweise getrennt halten, während Sie sie bearbeiten. Sie können dann ein anderes Teammitglied alle Änderungen überprüfen lassen, bevor sie im Mainbranch des gemeinsamen Repositorys Ihres Teams gemergt werden. Dieser Prozess hilft Ihrem Team, eine fundierte Entscheidung über eine Änderung zu treffen, bevor Sie deren Zusammenführung genehmigen.

Featurebranches

Ein Featurebranch zeigt an, dass Sie mit neuer Arbeit beginnen. Die Arbeit könnte z. B. eine Konfigurationsänderung einer in Ihrer Bicep-Datei definierten Ressource oder ein neuer Satz von Ressourcen sein, den Sie bereitstellen müssen. Jedes Mal, wenn Sie mit einer neuen Arbeit beginnen, erstellen Sie einen neuen Featurebranch.

Sie erstellen einen Featurebranch über den Mainbranch. Durch das Erstellen eines Branches stellen Sie sicher, dass Sie mit Ihrer Azure-Umgebung im aktuellen Zustand beginnen. Anschließend nehmen Sie alle erforderlichen Änderungen vor.

Da alle Codeänderungen in den Featurebranch committet werden, beeinträchtigen sie nicht den Mainbranch des Repositorys. Wenn ein anderes Teammitglied eine dringende Änderung am Mainbranch vornehmen muss, kann es dies unabhängig von Ihrer Arbeit in einem anderen Featurebranch tun.

Sie können auch zusammen an Featurebranches arbeiten. Hierzu veröffentlichen Sie Ihren Featurebranch und pushen diesen an das freigegebene Repository, sodass Sie und Ihre Teammitglieder gemeinsam an einer Änderung arbeiten können. Sie können die Arbeit an einem Feature auch einer anderen Person überlassen, wenn Sie in den Urlaub gehen.

Aktualisieren Ihrer Featurebranches

Während der Bearbeitung Ihres Featurebranchs werden andere Features möglicherweise im Mainbranch Ihres Repositorys gemergt. Dies bedeutet, dass Ihr Featurebranch und der Mainbranch Ihres Projekts voneinander abweichen. Je stärker sie voneinander abweichen, desto schwieriger ist es, die beiden Branches zu einem späteren Zeitpunkt erneut zu mergen. In diesem Fall können auch deutlich mehr Mergekonflikte auftreten.

Sie sollten Ihren Featurebranch regelmäßig aktualisieren, damit Sie alle Änderungen integrieren, die am Mainbranch des Repositorys vorgenommen wurden. Es ist auch eine gute Idee, Ihren Featurebranch zu aktualisieren, bevor Sie mit dem Mergen des Featurebranches mit dem Mainbranch beginnen. Auf diese Weise stellen Sie sicher, dass Ihre neuen Änderungen problemlos im Mainbranch gemergt werden können.

Tipp

Mergen Sie den Mainbranch häufig mit Ihrem Featurebranch.

Verwenden von kleinen, kurzlebigen Branches

Kurzlebige Featurebranches sind das Ziel. Mit diesem Ansatz können Sie Mergekonflikte vermeiden, indem Sie die Zeit verkürzen, die Ihre Branches möglicherweise nicht synchronisiert sind. Außerdem erleichtert dieser Ansatz Ihren Kollegen, die vorgenommenen Änderungen zu verstehen, was hilfreich ist, wenn Ihre Änderungen überprüft werden müssen.

Teilen Sie umfassende Aufgaben in mehrere kleinere Schritte auf, und erstellen Sie neue Featurebranches für jeden Schritt. Je größer das Feature ist, desto länger muss jemand daran arbeiten, und desto länger wird der Featurebranch genutzt. Stellen Sie die kleineren Änderungen in der Produktion bereit, wenn Sie die einzelnen Featurebranches mergen, und bauen Sie schrittweise die umfassendere Arbeit auf.

Angenommen, Sie nehmen einige Änderungen an Bicep-Code vor. Sie verschieben einige Ressourcendefinitionen in Module. Sie müssen auch Ihren Bicep-Dateien einige neue Ressourcen hinzufügen. Es empfiehlt sich, das gesamte Refactoring für Ihr Modul im Branch für dieses Modul durchzuführen. Nach dem Mergevorgang können Sie mit den Ergänzungen Ihrer Bicep-Dateien fortfahren. Die Änderungen und zugehörigen Branches bleiben klein und einfach verständlich, wenn Sie die Änderungen separat vornehmen.

Wenn Sie auf diese Weise arbeiten, kann es hilfreich sein, das Schlüsselwort if zu verwenden, um die Bereitstellung von Ressourcen zu deaktivieren, bis sie fertiggestellt sind. Der folgende Beispielcode zeigt, wie Sie das Schlüsselwort if verwenden würden, um eine Bicep-Datei zu erstellen, die ein Speicherkonto definiert, aber die Bereitstellung des Speicherkontos deaktiviert, bis Sie alle Änderungen vorgenommen haben.

@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = if (storageAccountReady) {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

Sie können Parameter verwenden, um unterschiedliche Werte für die Variable storageAccountReady in verschiedenen Umgebungen anzugeben. Beispielsweise könnten Sie den Parameterwert für Ihre Testumgebung auf true und für Ihre Produktionsumgebung auf false festlegen. Auf diese Weise können Sie das neue Speicherkonto in Ihrer Testumgebung testen.

Hinweis

Wenn Sie das Feature in der Produktion aktivieren möchten, denken Sie daran, dass Sie die folgenden Schritte ausführen müssen, damit Ihre Änderung wirksam wird:

  1. Ändern des Parameterwerts
  2. Erneutes Bereitstellen Ihrer Bicep-Datei

Mergen von Featurebranches

Wenn Sie mit der Arbeit an einem Featurebranch fertig sind, müssen Sie ihn mit dem Mainbranch Ihres Repositorys mergen. Es empfiehlt sich, die Änderungen vor dem Mergen zu überprüfen, die am Featurebranch vorgenommen wurden. Pull Requests ermöglichen Ihnen das Überprüfen Ihres Codes. Weitere Informationen zu Pull Requests erhalten Sie später in diesem Modul.

Branchschutz

Auf GitHub können Sie Branchschutzmechanismen für den Mainbranch des freigegebenen Repositorys konfigurieren. Branchschutzmechanismen erzwingen Regeln wie die folgenden:

  • Es kann keine Änderung im Mainbranch gemergt werden, außer durch einen Pull Request.
  • Änderungen müssen von mindestens zwei anderen Personen überprüft werden.

Wenn jemand versucht, einen Commit direkt an einen geschützten Branch zu pushen, tritt beim Pushvorgang ein Fehler auf. In der nächsten Lerneinheit erfahren Sie, wie Sie Branchschutzmechanismen anwenden.

Branchrichtlinien

In Azure DevOps können Sie Branchrichtlinien für den Mainbranch des freigegebenen Repositorys konfigurieren. Branchrichtlinien erzwingen Regeln wie die folgenden:

  • Es kann keine Änderung im Mainbranch gemergt werden, außer durch einen Pull Request.
  • Änderungen müssen von mindestens zwei anderen Personen überprüft werden.

Wenn jemand versucht, einen Commit direkt an einen geschützten Branch zu pushen, tritt beim Pushvorgang ein Fehler auf. In der nächsten Lerneinheit erfahren Sie, wie Sie Branchrichtlinien anwenden.

Andere Branchingstrategien

Sie können verschiedene Branchingstrategien verwenden, wenn Sie mit anderen an Ihrem Bicep-Code arbeiten. Jede Branchingstrategie hat Vor- und Nachteile.

Der Prozess, den Sie bisher kennengelernt haben, ist eine Version der trunkbasierten Entwicklungsstrategie. Bei dieser Branchingstrategie erfolgt die Arbeit an kurzlebigen Featurebranches, die dann in einem einzelnen Mainbranch gemergt werden. Sie können den Inhalt des Mainbranchs des freigegebenen Repositorys automatisch für die Produktion bereitstellen, wenn eine Änderung gemergt wird. Alternativ können Sie Änderungen in Batches zusammenfassen und nach einem Zeitplan veröffentlichen (z. B. wöchentlich). Die trunkbasierte Entwicklung ist leicht verständlich und ermöglicht die Zusammenarbeit ohne Mehraufwand.

Einige Teams trennen die Arbeit, die sie abgeschlossen haben, von der Arbeit, die sie in der Produktion bereitgestellt haben. Sie verwenden einen langlebigen Entwicklungsbranch als Ziel für die Zusammenführung ihrer Featurebranches. Sie führen den Entwicklungsbranch mit ihrem Mainbranch zusammen, wenn sie Änderungen für die Produktion freigeben.

Bei einigen anderen Branchingstrategien müssen Sie Releasebranches erstellen. Wenn Sie über eine Reihe von Änderungen verfügen, die für die Bereitstellung in der Produktion bereit sind, erstellen Sie einen Releasebranch mit den bereitzustellenden Änderungen. Diese Strategien können sinnvoll sein, wenn Sie Ihre Azure-Infrastruktur in regelmäßigen Abständen bereitstellen oder wenn Sie und andere Teams Änderungen integrieren.

Andere Branchingstrategien umfassen Gitflow, GitHub Flow und GitLab Flow. Einige Teams verwenden GitHub Flow oder GitLab Flow, da hiermit das Trennen der Arbeit verschiedener Teams sowie dringender Fehlerbehebungen für andere Änderungen möglich ist. Mithilfe dieser Prozesse können Sie Ihre Commits auch in verschiedene Releases Ihrer Lösung unterteilen, was als Cherrypicking bezeichnet wird. Sie erfordern jedoch mehr Verwaltung, um sicherzustellen, dass Ihre Änderungen miteinander konform sind. Im Abschnitt „Zusammenfassung“ des Moduls finden Sie Links zu Artikeln mit weiteren Informationen zu diesen Branchingstrategien.

Die für Ihr Team geeignete Branchingstrategie hängt davon ab, wie Ihr Team arbeitet, an Projekten zusammenarbeitet und Änderungen veröffentlicht. Es ist eine gute Idee, mit einem einfachen Prozess wie der trunkbasierten Entwicklung zu beginnen. Wenn Sie feststellen, dass Ihr Team mit diesem Prozess nicht effektiv arbeiten kann, führen Sie nach und nach zusätzliche Branchingebenen ein oder übernehmen eine Branchingstrategie. Beachten Sie jedoch, dass die Verwaltung Ihres Repositorys komplexer wird, wenn Sie weitere Branches hinzufügen.

Tipp

Unabhängig von der verwendeten Branchingstrategie sollten Sie Branchrichtlinien verwenden, um den Mainbranch zu schützen. Nutzen Sie zudem Pull Requests, um Ihre Änderungen zu überprüfen. Andere Branchingstrategien umfassen auch wichtige Branches, die Sie schützen sollten.

In diesem Modul haben Sie die trunkbasierte Entwicklung mit Featurebranches verwendet, da sie benutzerfreundlich ist.