Entwerfen einer Pipeline- 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 Pipelines 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.
Ihre Pipeline kann auch die Revisionsnummer automatisch festlegen. Die Buildnummer der Pipeline 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 zuvor veröffentlichtes Bicep-Modul mit einer Versionsnummer von 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 die 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 unabhängig davon als Hauptversionsupdate behandeln müssen.
Sie können auch eine einfachere Versionsverwaltungsstrategie verwenden (z. B. nur die Buildnummer der Pipeline 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 Pipelines
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 einer automatisierten Bereitstellungspipeline müssen Sie ihren Ansatz jedoch ändern, um Versionsnummern zuzuweisen. Ihre Pipeline 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 Pipelines?
Es ist üblich, eine Sammlung von Vorlagenspezifikationen und Modulen zu erstellen. Häufig ist es sinnvoll, diesen Code im gleichen Git-Repository zu speichern.
Mithilfe von Pfadfiltern in Azure Pipelines können Sie separate Pipelines 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 Pipelinevorlagen verwenden, um die Schritte Ihrer Pipeline in einer zentralen Datei zu definieren, wodurch die Pipeline der Module und Vorlagenspezifikationen einfach gehalten wird.
Angenommen, Sie verfügen über eine Dateistruktur, die der zuvor dargestellten Struktur ähnelt. Sie können drei separate Pipelines konfigurieren (eine für jede Bicep-Datei). Klicken Sie auf jede Registerkarte, um die entsprechende Pipelinedefinition und den Pfadfilter anzuzeigen:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Angenommen, Sie ändern nur die Datei module-2/main.bicep. Nur die Pipeline für Modul 2 wird ausgeführt. Wenn Sie jedoch mehrere Dateien im gleichen Commit ändern, wird jede der relevanten Pipelines ausgelöst.
Hinweis
Der Ansatz zum Erstellen einer Pipeline 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 Pipelines für jedes Modul und jede Vorlagenspezifikation verwalten möchten.
Sie können auch Skripts in Ihrer Pipeline 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-Moduls.
Umgebungen für wiederverwendbaren Bicep-Code
Wenn Sie Elemente mithilfe von Bicep in Azure bereitstellen, ist es üblich, mehrere Umgebungen zum Validieren und Testen Ihres Codes zu verwenden, bevor dieser in einer Produktionsumgebung veröffentlicht wird. In früheren Microsoft Learn-Schulungsmodulen haben Sie gelernt, wie Sie mit mehreren Umgebungen aus einer Bereitstellungspipeline 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 die Änderungen genehmigt wurden, können Sie die Module im Produktionsregister Ihrer Organisation veröffentlichen.
Wie bei normalen Bereitstellungen können Sie Aufträge und Pipelinevorlagen verwenden, um die Bereitstellungssequenz in Ihren Umgebungen zu definieren. In diesem Microsoft Learn-Modul veröffentlichen Sie die Elemente in einer einzigen Umgebung, um die Pipeline 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 eine Bereitstellungspipeline 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.