Hantera likheter mellan miljöer med hjälp av pipelinemallar

5 minuter

När du distribuerar dina ändringar till flera miljöer är stegen som ingår i distributionen till varje miljö likartade eller identiska. I den här lektionen får du lära dig hur du använder pipelinemallar för att undvika upprepning och för att tillåta återanvändning av pipelinekoden.

Distribution till flera miljöer

När du har pratat med dina kollegor i webbplatsteamet bestämmer du dig för följande pipeline för leksaksföretagets webbplats:

Diagram som visar en serie pipelinesteg som innehåller test- och produktionsdistributioner.

Pipelinen kör Bicep-lintern för att kontrollera att Bicep-koden är giltig och följer metodtipsen.

Linting sker på Bicep-koden utan att behöva ansluta till Azure, så det spelar ingen roll hur många miljöer du distribuerar till. Den körs bara en gång.
Pipelinen distribueras till testmiljön. Det här steget kräver:
1. Köra förhandsvalidering av Azure Resource Manager.
2. Distribuera Bicep-koden.
3. Köra några tester mot testmiljön.
Om någon del av pipelinen misslyckas stoppas hela pipelinen så att du kan undersöka och lösa problemet. Men om allt lyckas fortsätter pipelinen att distribueras till produktionsmiljön:
1. Pipelinen kör en förhandsversionsfas som kör konsekvensåtgärden i produktionsmiljön för att visa en lista över de ändringar som skulle göras i dina Azure-produktionsresurser. Förhandsversionssteget verifierar även distributionen, så du behöver inte köra ett separat valideringssteg för produktionsmiljön.
2. Pipelinen pausar för manuell validering.
3. Om godkännande tas emot kör pipelinen distributions- och röktesterna mot din produktionsmiljö.

Vissa av dessa steg upprepas mellan test- och produktionsmiljöerna och vissa körs endast för specifika miljöer:

Fas	Miljöer
Ludd	Inte heller – lintning fungerar inte mot en miljö
Validera	Endast test
Förhandsversion	Endast produktion
Distribuera	Båda miljöerna
Röktest	Båda miljöerna

När du behöver upprepa steg i pipelinen kan du försöka kopiera och klistra in dina stegdefinitioner. Det är dock bäst att undvika den metoden. Det är lätt att oavsiktligt göra subtila misstag eller att saker blir osynkroniserade när du duplicerar pipelinens kod. Och i framtiden, när du behöver göra en ändring i stegen, måste du komma ihåg att tillämpa ändringen på flera platser.

Pipelinemallar

Med pipelinemallar kan du skapa återanvändbara delar av pipelinedefinitioner. Mallar kan definiera steg, jobb eller hela faser. Du kan använda mallar för att återanvända delar av en pipeline flera gånger inom en enda pipeline, eller till och med i flera pipelines. Du kan också skapa en mall för en uppsättning variabler som du vill återanvända i flera pipelines.

En mall är helt enkelt en YAML-fil som innehåller ditt återanvändbara innehåll. En enkel mall för en stegdefinition kan se ut så här och sparas i en fil med namnet script.yml:

steps:
- script: |
    echo Hello world!

Du kan använda en mall i pipelinen med hjälp av nyckelordet template på den plats där du normalt definierar det enskilda steget:

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

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

Kapslade mallar

Du kan också kapsla mallar i andra mallar. Anta att den föregående filen hette jobs.yml och du skapar en fil med namnet azure-pipelines.yml som återanvänder jobbmallen i flera pipelinesteg:

trigger:
  branches:
    include:
    - main

pool:
  vmImage: ubuntu-latest

stages:

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

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

När du kapslar mallar eller återanvänder dem flera gånger i en enda pipeline måste du vara försiktig så att du inte oavsiktligt använder samma namn för flera pipelineresurser. Varje jobb i en fas behöver till exempel en egen identifierare. Så om du definierar jobbidentifieraren i en mall kan du inte återanvända den flera gånger i samma fas.

När du arbetar med komplexa uppsättningar med distributionspipelines kan det vara bra att skapa en dedikerad Git-lagringsplats för dina delade pipelinemallar. Sedan kan du återanvända samma lagringsplats i flera pipelines, även om de är för olika projekt. Vi tillhandahåller en länk till mer information i sammanfattningen.

Parametrar för pipelinemallar

Parametrar för pipelinemallar gör dina mallfiler enklare att återanvända, eftersom du kan tillåta små skillnader i dina mallar när du använder dem.

När du skapar en pipelinemall kan du ange dess parametrar överst i filen:

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

Du kan definiera så många parametrar som du behöver. Men precis som Bicep-parametrar kan du försöka att inte överanvända parametrar för pipelinemallar. Du bör göra det enkelt för någon annan att återanvända mallen utan att behöva ange för många inställningar.

Varje pipelinemallparameter har tre egenskaper:

Namnet på parametern som du använder för att referera till parametern i dina mallfiler.
Typ av parameter. Parametrar stöder flera olika typer av data, inklusive sträng, tal och booleskt värde. Du kan också definiera mer komplexa mallar som accepterar strukturerade objekt.
Standardvärdet för parametern, som är valfritt. Om du inte anger något standardvärde måste ett värde anges när pipelinemallen används.

I exemplet definierar pipelinen en strängparameter med namnet environmentType, som har standardvärdet Test, och en obligatorisk parameter med namnet serviceConnectionName.

I pipelinemallen använder du en särskild syntax för att referera till värdet för parametern. Använd makrot ${{parameters.YOUR_PARAMETER_NAME}} , som i det här exemplet:

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

Du skickar värdet för parametrar till en pipelinemall med hjälp av nyckelordet parameters , som i det här exemplet:

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

- template: script.yml
  parameters: 
    environmentType: Production

Du kan också använda parametrar när du tilldelar identifierare till dina jobb och steg i pipelinemallar. Den här tekniken hjälper dig när du behöver återanvända samma mall flera gånger i pipelinen, så här:

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

Villkor

Du kan använda pipelinevillkor för att ange om ett steg, ett jobb eller till och med en fas ska köras beroende på en regel som du anger. Du kan kombinera mallparametrar och pipelinevillkor för att anpassa distributionsprocessen för många olika situationer.

Anta till exempel att du definierar en pipelinemall som kör skriptsteg. Du planerar att återanvända mallen för var och en av dina miljöer. När du distribuerar produktionsmiljön vill du köra ett annat steg. Så här kan du uppnå det med hjälp av makrot if och operatorn eq (lika med):

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.

Villkoret här översätts till: om värdet för parametern environmentType är lika med Produktion kör du följande steg.

Dricks

Var uppmärksam på YAML-filens indrag när du använder villkor som i exemplet. De steg som villkoret gäller för måste vara indragna med en extra nivå.

Du kan också ange egenskapen condition på en fas, ett jobb eller ett steg. Här är ett exempel som visar hur du kan använda operatorn ne (inte lika med) för att ange ett villkor som om parametern environmentType-parameterns värde inte är lika med Produktion och kör sedan följande steg:

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

Även om villkor är ett sätt att öka flexibiliteten i pipelinen kan du försöka att inte använda för många av dem. De komplicerar din pipeline och gör det svårare att förstå flödet. Om det finns många villkor i pipelinemallen kanske mallen inte är den bästa lösningen för arbetsflödet som du planerar att köra, och du kan behöva göra om pipelinen.