Overeenkomsten tussen omgevingen afhandelen met behulp van pijplijnsjablonen

  • 5 minuten

Wanneer u uw wijzigingen in meerdere omgevingen implementeert, zijn de stappen voor het implementeren in elke omgeving vergelijkbaar of identiek. In deze les leert u hoe u pijplijnsjablonen gebruikt om herhaling te voorkomen en om hergebruik van uw pijplijncode mogelijk te maken.

Implementatie in meerdere omgevingen

Nadat u met uw collega's in het websiteteam hebt gepraat, besluit u over de volgende pijplijn voor de website van uw speelgoedbedrijf:

Diagram met een reeks pijplijnfasen met test- en productie-implementaties.

  1. De pijplijn voert de Bicep linter uit om te controleren of de Bicep-code geldig is en volgt de aanbevolen procedures.

    Linting vindt plaats in de Bicep-code zonder verbinding te hoeven maken met Azure, dus het maakt niet uit in hoeveel omgevingen u implementeert. Het wordt slechts één keer uitgevoerd.

  2. De pijplijn wordt geïmplementeerd in de testomgeving. Voor deze fase is het volgende vereist:

    1. De voorbereidende validatie van Azure Resource Manager uitvoeren.
    2. De Bicep-code implementeren.
    3. Voer enkele tests uit op uw testomgeving.

  3. Als een deel van de pijplijn mislukt, stopt de hele pijplijn zodat u het probleem kunt onderzoeken en oplossen. Maar als alles slaagt, blijft uw pijplijn implementeren in uw productieomgeving:

    1. De pijplijn voert een preview-fase uit, waarmee de wat-als-bewerking in uw productieomgeving wordt uitgevoerd om de wijzigingen weer te geven die in uw Azure-productiebronnen zouden worden aangebracht. De preview-fase valideert ook uw implementatie, zodat u geen afzonderlijke validatiefase hoeft uit te voeren voor uw productieomgeving.
    2. De pijplijn wordt onderbroken voor handmatige validatie.
    3. Als er goedkeuring wordt ontvangen, voert de pijplijn de implementatie- en betrouwbaarheidstests uit op uw productieomgeving.

Sommige van deze fasen worden herhaald tussen uw test- en productieomgevingen, en sommige worden alleen uitgevoerd voor specifieke omgevingen:

Fase Omgevingen
Pluis Geen van beide: linting werkt niet tegen een omgeving
Valideren Alleen testen
Preview uitvoeren Alleen productie
Implementeren Beide omgevingen
Betrouwbaarheidstest Beide omgevingen

Wanneer u stappen in uw pijplijn wilt herhalen, kunt u proberen uw stapdefinities te kopiëren en plakken. Het is echter het beste om die praktijk te vermijden. Het is eenvoudig om per ongeluk subtiele fouten te maken of om synchronisatie uit te voeren wanneer u de code van uw pijplijn dupliceren. En in de toekomst, wanneer u een wijziging moet aanbrengen in de stappen, moet u onthouden om de wijziging op meerdere plaatsen toe te passen.

Pijplijnsjablonen

Met pijplijnsjablonen kunt u herbruikbare secties van pijplijndefinities maken. Sjablonen kunnen stappen, taken of zelfs volledige fasen definiëren. U kunt sjablonen gebruiken om onderdelen van een pijplijn meerdere keren binnen één pijplijn of zelfs in meerdere pijplijnen opnieuw te gebruiken. U kunt ook een sjabloon maken voor een set variabelen die u in meerdere pijplijnen opnieuw wilt gebruiken.

Een sjabloon is gewoon een YAML-bestand dat uw herbruikbare inhoud bevat. Een eenvoudige sjabloon voor een stapdefinitie kan er als volgt uitzien en worden opgeslagen in een bestand met de naam script.yml:

steps:
- script: |
    echo Hello world!

U kunt een sjabloon in uw pijplijn gebruiken met behulp van het template trefwoord op de plaats waar u normaal gesproken de afzonderlijke stap definieert:

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

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

Geneste sjablonen

U kunt sjablonen ook nesten in andere sjablonen. Stel dat het voorgaande bestand de naam jobs.yml heeft en u een bestand met de naam azure-pipelines.yml maakt waarmee de taaksjabloon in meerdere pijplijnfasen opnieuw wordt gebruikt:

trigger:
  branches:
    include:
    - main

pool:
  vmImage: ubuntu-latest

stages:

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

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

Wanneer u sjablonen nestt of meerdere keren in één pijplijn opnieuw gebruikt, moet u ervoor zorgen dat u niet per ongeluk dezelfde naam gebruikt voor meerdere pijplijnbronnen. Elke taak in een fase heeft bijvoorbeeld een eigen id nodig. Dus als u de taak-id in een sjabloon definieert, kunt u deze niet meerdere keren opnieuw gebruiken in dezelfde fase.

Wanneer u met complexe sets implementatiepijplijnen werkt, kan het handig zijn om een toegewezen Git-opslagplaats te maken voor uw gedeelde pijplijnsjablonen. Vervolgens kunt u dezelfde opslagplaats in meerdere pijplijnen opnieuw gebruiken, zelfs als ze voor verschillende projecten zijn. We bieden een koppeling naar meer informatie in de samenvatting.

Parameters voor pijplijnsjablonen

Met parameters voor pijplijnsjablonen kunt u uw sjabloonbestanden gemakkelijker hergebruiken, omdat u kleine verschillen in uw sjablonen kunt toestaan wanneer u ze gebruikt.

Wanneer u een pijplijnsjabloon maakt, kunt u de bijbehorende parameters boven aan het bestand aangeven:

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

U kunt zoveel parameters definiëren als u nodig hebt. Maar probeer net als Bicep-parameters niet te veel parameters voor pijplijnsjablonen te gebruiken. U moet het voor iemand anders gemakkelijk maken om uw sjabloon opnieuw te gebruiken zonder te veel instellingen op te geven.

Elke parameter voor een pijplijnsjabloon heeft drie eigenschappen:

  • De naam van de parameter, die u gebruikt om te verwijzen naar de parameter in uw sjabloonbestanden.
  • Het type van de parameter. Parameters ondersteunen verschillende typen gegevens, waaronder tekenreeks, getal en Booleaanse waarde. U kunt ook complexere sjablonen definiëren die gestructureerde objecten accepteren.
  • De standaardwaarde van de parameter, die optioneel is. Als u geen standaardwaarde opgeeft, moet er een waarde worden opgegeven wanneer de pijplijnsjabloon wordt gebruikt.

In het voorbeeld definieert de pijplijn een tekenreeksparameter met de naam environmentType, die een standaardwaarde heeft en Testeen verplichte parameter met de naam serviceConnectionName.

In de pijplijnsjabloon gebruikt u een speciale syntaxis om te verwijzen naar de waarde van de parameter. Gebruik de ${{parameters.YOUR_PARAMETER_NAME}} macro, zoals in dit voorbeeld:

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

U geeft de waarde voor parameters door aan een pijplijnsjabloon met behulp van het parameters trefwoord, zoals in dit voorbeeld:

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

- template: script.yml
  parameters: 
    environmentType: Production

U kunt ook parameters gebruiken wanneer u id's toewijst aan uw taken en fasen in pijplijnsjablonen. Deze techniek helpt wanneer u dezelfde sjabloon meerdere keren opnieuw moet gebruiken in uw pijplijn, zoals deze:

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

Voorwaarden

U kunt pijplijnvoorwaarden gebruiken om op te geven of een stap, taak of zelfs een fase moet worden uitgevoerd, afhankelijk van een regel die u opgeeft. U kunt sjabloonparameters en pijplijnvoorwaarden combineren om uw implementatieproces voor veel verschillende situaties aan te passen.

Stel dat u een pijplijnsjabloon definieert waarmee scriptstappen worden uitgevoerd. U wilt de sjabloon opnieuw gebruiken voor elk van uw omgevingen. Wanneer u uw productieomgeving implementeert, wilt u een andere stap uitvoeren. U kunt dit als volgt bereiken met behulp van de if macro en de eq operator (is gelijk aan):

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.

De voorwaarde hier wordt omgezet in: als de waarde van de parameter environmentType gelijk is aan Production, voert u de volgende stappen uit.

Tip

Let op de inspringing van het YAML-bestand wanneer u voorwaarden zoals in het voorbeeld gebruikt. De stappen waarop de voorwaarde van toepassing is, moeten met één extra niveau worden ingesprongen.

U kunt ook de condition eigenschap opgeven voor een fase, taak of stap. Hier volgt een voorbeeld waarin wordt getoond hoe u de ne operator (niet gelijk aan) kunt gebruiken om een voorwaarde op te geven, bijvoorbeeld als de waarde van de parameter environmentType niet gelijk is aan Productie. Voer vervolgens de volgende stappen uit:

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

Hoewel voorwaarden een manier zijn om flexibiliteit toe te voegen aan uw pijplijn, kunt u er niet te veel van gebruiken. Ze maken uw pijplijn ingewikkeld en maken het moeilijker om de stroom te begrijpen. Als uw pijplijnsjabloon veel voorwaarden bevat, is de sjabloon mogelijk niet de beste oplossing voor de werkstroom die u wilt uitvoeren en moet u de pijplijn mogelijk opnieuw ontwerpen.

Overweeg ook YAML-opmerkingen te gebruiken om de voorwaarden uit te leggen die u gebruikt en eventuele andere aspecten van uw pijplijn die mogelijk meer uitleg nodig hebben. Opmerkingen helpen uw pijplijn in de toekomst gemakkelijk te begrijpen en ermee te werken. Er zijn voorbeelden van YAML-opmerkingen in de oefeningen in deze module.