Behandeln von Ähnlichkeiten zwischen Umgebungen mithilfe von Pipelinevorlagen

5 Minuten

Wenn Sie Ihre Änderungen in mehreren Umgebungen bereitstellen, sind die Schritte für die Bereitstellung in jeder Umgebung ähnlich oder identisch. In dieser Lerneinheit erfahren Sie, wie Sie Pipelinevorlagen verwenden, um Wiederholungen zu vermeiden und die Wiederverwendung Ihres Pipelinecodes zu ermöglichen.

Bereitstellung in mehreren Umgebungen

Nachdem Sie mit Ihren Kollegen im Websiteteam gesprochen haben, entscheiden Sie sich für die folgende Pipeline für die Website Ihres Spielzeugunternehmens:

Diagramm mit einer Reihe von Pipelinestages, einschließlich Test- und Produktionsbereitstellungen

Die Pipeline führt den Bicep-Linter aus, um zu überprüfen, ob der Bicep-Code gültig ist und den bewährten Methoden folgt.

Linten erfolgt im Bicep-Code, ohne eine Verbindung mit Azure herstellen zu müssen, sodass es keine Rolle spielt, in wie vielen Umgebungen Sie bereitstellen. Es wird nur einmal ausgeführt.
Die Pipeline wird in der Testumgebung bereitgestellt. Diese Phase erfordert:
1. Ausführen der Azure Resource Manager-Preflightüberprüfung.
2. Bereitstellen des Bicep-Codes.
3. Ausführen einiger Tests für Ihre Testumgebung.
Wenn in einem Teil der Pipeline ein Fehler auftritt, wird die gesamte Pipeline beendet, damit Sie das Problem untersuchen und beheben können. Wenn jedoch alles erfolgreich ist, wird Ihre Pipeline weiterhin in Ihrer Produktionsumgebung bereitgestellt:
1. Während der Vorschau-Stage der Pipeline wird der Was-wäre-wenn-Vorgang in Ihrer Produktionsumgebung ausgeführt, um die Änderungen aufzulisten, die an Ihren Azure-Produktionsressourcen vorgenommen werden. Die Vorschauphase überprüft auch Ihre Bereitstellung, sodass Sie keine separate Überprüfungsphase für Ihre Produktionsumgebung ausführen müssen.
2. Die Pipeline wird für die manuelle Überprüfung angehalten.
3. Wenn die Genehmigung eingeht, führt die Pipeline die Bereitstellungs- und Feuerprobe für Ihre Produktionsumgebung aus.

Einige dieser Phasen werden zwischen Ihren Test- und Produktionsumgebungen wiederholt, und einige werden nur für bestimmte Umgebungen ausgeführt:

Phase	Umgebungen
Lint	Keine von beiden: Linten funktioniert nicht für eine Umgebung
Überprüfen	Nur Test
Vorschau	Nur Produktion
Bereitstellen	Beide Umgebungen
Feuerprobe	Beide Umgebungen

Wenn Sie die Schritte in Ihrer Pipeline wiederholen müssen, können Sie versuchen, Ihre Schrittdefinitionen zu kopieren und einzufügen. Dies sollte jedoch nach Möglichkeit vermieden werden. Wenn Sie den Code Ihrer Pipeline duplizieren, ist es einfach, versehentlich kleine Fehler zu machen oder die Synchronisierung zu erschweren. Wenn Sie in Zukunft eine Änderung an den Schritten durchführen müssen, müssen Sie daran denken, die Änderung an mehreren Stellen anzuwenden.

Pipelinevorlagen

Mit Pipelinevorlagen können Sie wiederverwendbare Abschnitte von Pipelinedefinitionen erstellen. Vorlagen können Schritte, Aufträge oder sogar ganze Phasen definieren. Sie können Vorlagen verwenden, um Teile einer Pipeline mehrmals innerhalb einer einzelnen Pipeline oder sogar in mehreren Pipelines wiederzuverwenden. Sie können auch eine Vorlage für eine Reihe von Variablen erstellen, die Sie in mehreren Pipelines wiederverwenden möchten.

Eine Vorlage ist einfach eine YAML-Datei, die wiederverwendbare Inhalte enthält. Eine einfache Vorlage für eine Schrittdefinition könnte wie folgt aussehen und in einer Datei namens script.yml gespeichert werden:

steps:
- script: |
    echo Hello world!

Sie können eine Vorlage in Ihrer Pipeline verwenden, indem Sie das Schlüsselwort template an der Stelle verwenden, an der Sie normalerweise den einzelnen Schritt definieren:

jobs:
- job: Job1
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: script.yml

- job: Job2
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: script.yml

Geschachtelte Vorlagen

Sie können Vorlagen auch in anderen Vorlagen schachteln. Angenommen, die vorherige Datei heißt jobs.yml, und Sie erstellen eine Datei mit dem Namen azure-pipelines.yml, die die Auftragsvorlage in mehreren Pipelinephasen wiederverwendet:

trigger:
  branches:
    include:
    - main

pool:
  vmImage: ubuntu-latest

stages:

- stage: Stage1
  jobs:
  - template: jobs.yml

- stage: Stage2
  jobs:
  - template: jobs.yml

Wenn Sie Vorlagen schachteln oder mehrmals in einer einzelnen Pipeline wiederverwenden, müssen Sie darauf achten, dass Sie nicht versehentlich den gleichen Namen für mehrere Pipelineressourcen verwenden. Beispielsweise benötigt jeder Auftrag innerhalb einer Phase einen eigenen Bezeichner. Wenn Sie also den Auftragsbezeichner in einer Vorlage definieren, können Sie ihn nicht mehrmals in derselben Phase wiederverwenden.

Wenn Sie mit komplexen Sätzen von Bereitstellungspipelines arbeiten, kann es hilfreich sein, ein dediziertes Git-Repository für Ihre freigegebenen Pipelinevorlagen zu erstellen. Anschließend können Sie das gleiche Repository in mehreren Pipelines wiederverwenden, auch wenn sie für verschiedene Projekte vorgesehen sind. Wir stellen einen Link zu weiteren Informationen in der Zusammenfassung bereit.

Pipelinevorlagenparameter

Pipelinevorlagenparameter erleichtern die Wiederverwendung Ihrer Vorlagendateien, da Sie bei jeder Verwendung kleine Unterschiede in Ihren Vorlagen zulassen können.

Wenn Sie eine Pipelinevorlage erstellen, können Sie deren Parameter am Anfang der Datei angeben:

parameters: 
- name: environmentType
  type: string
  default: 'Test'
- name: serviceConnectionName
  type: string

Sie können so viele Parameter definieren, wie Sie benötigen. Versuchen Sie aber genau wie bei Bicep-Parametern, nicht zu viele Pipelinevorlagenparameter zu verwenden. Sie sollten es anderen Personen erleichtern, Ihre Vorlage wiederzuverwenden, ohne zu viele Einstellungen angeben zu müssen.

Jeder Pipelinevorlagenparameter verfügt über drei Eigenschaften:

Der Name des Parameters, mit dem Sie auf den Parameter in Ihren Vorlagendateien verweisen.
Der Typ des Parameters. Parameter unterstützen verschiedene Datentypen, einschließlich Zeichenfolge,Zahlund boolescher Wert. Sie können auch komplexere Vorlagen definieren, die strukturierte Objekte akzeptieren.
Der Standardwert des Parameters (optional). Wenn Sie keinen Standardwert angeben, muss ein Wert angegeben werden, wenn die Pipelinevorlage verwendet wird.

Im Beispiel definiert die Pipeline einen Zeichenfolgenparameter namens environmentType mit dem Standardwert Test und einen obligatorischen Parameter namens serviceConnectionName.

In Ihrer Pipelinevorlage verwenden Sie eine spezielle Syntax, um auf den Wert des Parameters zu verweisen. Verwenden Sie das Makro ${{parameters.YOUR_PARAMETER_NAME}} wie in diesem Beispiel:

steps:
- script: |
    echo Hello ${{parameters.environmentType}}!

Sie übergeben den Wert für Parameter wie im folgenden Beispiel mithilfe des Schlüsselworts parameters an eine Pipelinevorlage:

steps:
- template: script.yml
  parameters:
    environmentType: Test

- template: script.yml
  parameters: 
    environmentType: Production

Sie können Parameter auch verwenden, wenn Sie Ihren Aufträgen und Phasen in Pipelinevorlagen Bezeichner zuweisen. Diese Technik ist hilfreich, wenn Sie dieselbe Vorlage mehrmals in Ihrer Pipeline wiederverwenden müssen, z. B.:

parameters:
- name: environmentType
  type: string
  default: 'Test'

jobs:
- job: Job1-${{parameters.environmentType}}
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: script.yml

- job: Job2-${{parameters.environmentType}}
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: script.yml

Bedingungen

Sie können Pipelinebedingungen verwenden, um anzugeben, ob ein Schritt, ein Auftrag oder sogar eine Phase je nach einer von Ihnen angegebenen Regel ausgeführt werden soll. Sie können Vorlagenparameter und Pipelinebedingungen kombinieren, um Ihren Bereitstellungsprozess für viele verschiedene Situationen anzupassen.

Angenommen, Sie definieren eine Pipelinevorlage, die Skriptschritte ausführt. Sie planen, die Vorlage für jede Ihrer Umgebungen wiederzuverwenden. Wenn Sie Ihre Produktionsumgebung bereitstellen, sollten Sie einen weiteren Schritt ausführen. Dies können Sie mithilfe des if-Makros und des eq-Operators (gleich) erreichen:

parameters: 
- name: environmentType
  type: string
  default: 'Test'

steps:
- script: |
    echo Hello ${{parameters.environmentType}}!

- ${{ if eq(parameters.environmentType, 'Production') }}:
  - script: |
      echo This step only runs for production deployments.

Die Bedingung lässt sich hier wie folgt übersetzen: Wenn der Wert des environmentType-Parameters gleich „Production“ ist, sollen die folgenden Schritte ausgeführt werden.

Tipp

Achten Sie in der YAML-Datei auf den Einzug, wenn Sie Bedingungen wie in diesem Beispiel verwenden. Die Schritte, für die die Bedingung gilt, müssen um eine zusätzliche Ebene eingerückt werden.

Sie können die Eigenschaft condition auch für eine Phase, einen Auftrag oder einen Schritt angeben. Das folgende Beispiel zeigt, wie Sie den Operator ne (ungleich) verwenden können, um eine Bedingung anzugeben, z. B. Wenn der Wert des environmentType-Parameters ungleich „Production“ ist, sollen die folgenden Schritte ausgeführt werden:

- script: |
    echo This step only runs for non-production deployments.
  condition: ne('${{ parameters.environmentType }}', 'Production')

Obwohl Bedingungen eine Möglichkeit sind, Ihrer Pipeline Flexibilität zu verleihen, versuchen Sie, nicht zu viele davon zu verwenden. Sie machen Ihre Pipeline kompliziert und erschweren das Verständnis des Ablaufs. Wenn die Pipelinevorlage viele Bedingungen enthält, ist sie möglicherweise nicht die beste Lösung für den Workflow, den Sie ausführen möchten, und Sie müssen Ihre Pipeline möglicherweise umgestalten.