Entwerfen einer Workflow- und Versionsverwaltungsstrategie
Wenn Sie mit der Veröffentlichung von wiederverwendbarem Bicep-Code beginnen, verwenden Sie wahrscheinlich einen manuellen Ansatz. Es ist einfach, zu ermitteln, welche Bicep-Datei Sie veröffentlichen müssen, und Sie haben wahrscheinlich einen manuellen Prozess zum Inkrementieren der Versionsnummer.
Wenn Sie den Veröffentlichungsprozess automatisieren, müssen Sie überlegen, wie Sie diese Schritte automatisieren. In dieser Lerneinheit erfahren Sie, wie Sie ein Versionsverwaltungssystem einführen, das die Änderungen kommuniziert, die Sie an Ihrem Code vorgenommen haben. Außerdem lernen Sie, wie Sie Ihre Workflows auf die Veröffentlichung des erwarteten Codes beschränken können.
Versionsnummern
In früheren Microsoft Learn-Schulungsmodulen haben Sie mehr über die Bedeutung der Versionsverwaltung für Vorlagenspezifikationen und Bicep-Module erfahren. Sie können aus vielen verschiedenen Versionsverwaltungsansätzen auswählen. In vielen Situationen empfiehlt es sich, ein mehrteiliges Versionsverwaltungssystem zu verwenden. Ein mehrteiliges Versionsverwaltungssystem besteht aus einer Hauptversion, einer Nebenversion und einer Revisionsnummer, ähnlich wie im folgenden Beispiel:
Im vorherigen Beispiel ist die Hauptversion 1, die Nebenversion ist 4, und die Revisionsnummer lautet 106.
Änderungen in verschiedenen Teilen von Versionsnummern kommunizieren wichtige Informationen zu den Arten von Änderungen im Code:
Wenn Sie einen Breaking Change vornehmen, sollten Sie die Hauptversionsnummer inkrementieren. Angenommen, Sie fügen einen neuen obligatorischen Parameter hinzu oder entfernen einen Parameter aus Ihrer Bicep-Datei. Dies sind Beispiele für Breaking Changes, da Bicep obligatorische Parameter erfordert, die zur Bereitstellungszeit angegeben werden müssen, und die Einstellungswerte für nicht vorhandene Parameter nicht zulässig sind. Aus diesem Grund würden Sie also die Hauptversionsnummer aktualisieren.
Wenn Sie dem Code etwas Neues hinzufügen, es sich aber um keinen Breaking Change handelt, sollten Sie die Nebenversionsnummer inkrementieren. Angenommen, Sie fügen einen neuen optionalen Parameter mit einem Standardwert hinzu. Optionale Parameter sind keine Breaking Changes, sodass Sie die Nebenversionsnummer aktualisieren sollten.
Wenn Sie abwärtskompatible Fehlerkorrekturen oder andere Änderungen vornehmen, die sich nicht auf die Funktionsweise des Codes auswirken, sollten Sie die Revisionsnummer inkrementieren. Angenommen, Sie gestalten Ihren Bicep-Code neu, um Variablen und Ausdrücke besser verwenden zu können. Wenn die Umgestaltung das Verhalten des Bicep-Codes überhaupt nicht ändert, aktualisieren Sie die Revisionsnummer.
Ihr Workflow kann auch die Revisionsnummer automatisch festlegen. Die Ausführungsnummer des Workflows kann als Revisionsnummer verwendet werden. Diese Konvention hilft dabei, sicherzustellen, dass Ihre Versionsnummern immer eindeutig sind, auch wenn Sie die anderen Komponenten Ihrer Versionsnummern nicht aktualisieren.
Angenommen, Sie verwenden ein Bicep-Modul, das jemand anderes veröffentlicht hat. Das Modul hat die Versionsnummer 2.0.496. Sie sehen, dass eine neue Version des Moduls mit der Versionsnummer 2.1.502 verfügbar ist. Die einzige wesentliche Änderung ist die Nebenversionsnummer, die angibt, dass Sie bei Verwendung der neuen Version keinen Breaking Change erwarten sollten.
Hinweis
Die semantische Versionsverwaltung ist eine formalisierte Versionsverwaltungsstruktur, die der mehrteiligen Versionsverwaltung ähnelt. Die semantische Versionsverwaltung enthält zusätzliche Komponenten in der Versionsnummer sowie strenge Regeln zum Zeitpunkt des Festlegens oder Zurücksetzens der einzelnen Komponenten. In der Zusammenfassung sind weitere Informationen zur semantischen Versionsverwaltung verlinkt.
Ihr Team muss entscheiden, wie es einen Breaking Change für den Zweck der Versionsverwaltung definiert. Angenommen, Sie haben ein Bicep-Modul erstellt, das ein Speicherkonto bereitstellt. Sie aktualisieren jetzt die Bicep-Datei, um private Endpunkte für Ihr Speicherkonto zu aktivieren. Gleichzeitig fügen Sie Ihrer Bicep-Datei eine private DNS-Zone zu.
In diesem Beispiel können Sie die Änderung vornehmen, ohne dass sich dies auf die Parameter oder Ausgaben der Bicep-Datei auswirkt. Auf diese Weise bemerken Personen, die die Datei bereitstellen, möglicherweise keine Änderungen. Diese Änderung führt jedoch zu einem erheblichen Unterschied im Verhalten Ihrer Ressourcen, sodass Sie dies möglicherweise als Hauptversionsupdate behandeln müssen.
Sie können auch eine einfachere Versionsverwaltungsstrategie verwenden (z. B. nur die Ausführungsnummer des Workflows als Versionsnummer verwenden). Obwohl dieser Ansatz einfacher zu implementieren ist, bedeutet dies, dass Sie die Unterschiede zwischen Versionen nicht effektiv an alle Personen kommunizieren können, die Ihren Code verwenden.
Versionen und Workflows
Wenn Sie Ihren Code interaktiv veröffentlichen (z. B. mithilfe der Azure CLI), machen Sie sich bei der Veröffentlichung wahrscheinlich Gedanken über die Versionsnummer, die Sie Ihrer Vorlagenspezifikation oder Ihrem Modul zuweisen. In einem automatisierten Bereitstellungsworkflow müssen Sie ihren Ansatz jedoch ändern, um Versionsnummern zuzuweisen. Ihr Workflow kann keine Breaking Changes automatisch erkennen oder Ihnen Hinweise geben, wenn Sie Ihre Haupt- oder Nebenversionsnummern inkrementieren sollten. Sie sollten sich Gedanken zur Versionsverwaltung machen, bevor Sie die Vorlagenspezifikation oder das Modul veröffentlichen.
Ein Ansatz besteht darin, wie in der folgenden Abbildung eine Metadatendatei mit Ihrem Bicep-Code zu speichern:
Wenn Sie den Bicep-Code aktualisieren, aktualisieren Sie die Versionsinformationen in der entsprechenden Metadatendatei. Stellen Sie sicher, dass Sie Breaking Changes und Nonbreaking Changes ordnungsgemäß identifizieren, sodass Sie die Versionsnummern korrekt inkrementieren können.
Tipp
Wenn Ihr Team Ihren Bicep-Code mithilfe von Pull Requests überprüft, bitten Sie die Reviewer, zu überprüfen, ob Änderungen an Ihrem Code eine Änderung der Haupt- oder Nebenversionsnummer erfordern.
In der nächsten Übung erfahren Sie, wie Sie eine Metadatendatei verwenden können.
Wie viele Workflows?
Es ist üblich, eine Sammlung von Vorlagenspezifikationen und Modulen zu erstellen. Häufig ist es sinnvoll, diese im gleichen Git-Repository zu speichern.
Mithilfe von Pfadfiltern in GitHub Actions können Sie separate Workflows für jedes Modul oder jede Vorlagenspezifikation innerhalb Ihres Repositorys erstellen. Dieser Ansatz hilft Ihnen, zu verhindern, dass jedes Mal eine neue Version jeder Bicep-Datei im Repository veröffentlicht wird, wenn Sie eine Änderung an einer Datei vornehmen. Sie können wiederverwendbare Workflows verwenden, um die Schritte Ihres Workflows in einer zentralen Datei zu definieren, wodurch der Workflow jedes Moduls und jeder Vorlagenspezifikation einfach gehalten wird.
Angenommen, Sie verfügen über eine Dateistruktur, die der zuvor dargestellten Struktur ähnelt. Sie können drei separate Workflows konfigurieren (eine für jede Bicep-Datei). Klicken Sie auf jede Registerkarte, um die entsprechende Workflowdefinition und den Pfadfilter anzuzeigen:
name: 'publish-module-1'
on:
push:
branches:
- main
paths:
- 'module-1/**'
jobs:
publish:
uses: ./.github/workflows/publish-module.yml
with:
path: 'module-1/main.bicep'
Angenommen, Sie ändern nur die Datei module-2/main.bicep. Nur der Workflow für Modul 2 wird ausgeführt. Wenn Sie jedoch mehrere Dateien im gleichen Commit ändern, wird jeder der relevanten Workflows ausgelöst.
Hinweis
Der Ansatz zum Erstellen eines Workflows für jede Ihrer wiederverwendbaren Bicep-Dateien ist einfach und flexibel. Dies kann sich jedoch schwierig gestalten, wenn Sie über eine große Anzahl von Bicep-Dateien verfügen oder Sie keine separaten Workflows für jedes Modul und jede Vorlagenspezifikation verwalten möchten.
Sie können auch Skripts in Ihren Workflow schreiben, um den geänderten Code zu suchen und nur diese Dateien zu veröffentlichen. Dies ist ein komplexerer Ansatz und übersteigt den Rahmen dieses Microsoft Learn-Schulungsmoduls.
Umgebungen für wiederverwendbaren Bicep-Code
Wenn Sie mithilfe von Bicep in Azure bereitstellen, müssen Sie häufig mehrere Umgebungen verwenden, um Ihren Code zu überprüfen und zu testen, bevor Sie den Code in einer Produktionsumgebung veröffentlichen. In früheren Microsoft Learn-Schulungsmodulen haben Sie gelernt, wie Sie mit mehreren Umgebungen aus einem Bereitstellungsworkflow arbeiten.
Einige Organisationen wenden dieselben Prinzipien auf Bicep-Module und Vorlagenspezifikationen an. So können Sie beispielsweise zuerst neue Versionen Ihrer Module in einer Nichtproduktionsregistrierung veröffentlichen, damit die Benutzer*innen jedes Moduls die neuen Versionen testen können. Nachdem sie sich abgemeldet haben, können Sie die Module dann in der Produktionsregistrierung Ihrer Organisation veröffentlichen.
Wie bei normalen Bereitstellungen können Sie Aufträge und wiederverwendbare Workflows verwenden, um die Bereitstellungssequenz in Ihren Umgebungen zu definieren. In diesem Microsoft Learn-Schulungsmodul veröffentlichen Sie die Elemente in einer einzigen Umgebung, um den Workflow einfach zu halten.
Wenn Sie Module aus einer Registrierung nutzen oder eine Vorlagenspezifikation als Bicep-Modul verwenden, können Sie Aliase verwenden. Anstatt bei der Definition eines Moduls jedes Mal den Registrierungsnamen oder den Speicherort der Vorlagenspezifikation anzugeben, verwenden Sie dessen Alias.
Mithilfe von Aliasen können Sie sicherstellen, dass Ihr Bereitstellungsprozess in mehreren Umgebungen funktioniert. Wenn Sie beispielsweise ein Modul definieren, können Sie anstelle eines Registrierungsnamens einen Alias verwenden. Anschließend können Sie einen Bereitstellungsworkflow entwerfen, um den Alias zu konfigurieren, der den folgenden Komponenten zugeordnet werden soll:
- Entwicklungsmodulregistrierung, wenn Sie in einer Sandkastenumgebung bereitstellen
- Produktionsregistrierung, wenn Sie in anderen Umgebungen bereitstellen
Hinweis
Aliase können bei der Veröffentlichung nicht angewendet werden. Sie funktionieren nur, wenn Sie Vorlagenspezifikationen oder Module in einer Bicep-Datei verwenden.