Håndter ligheder mellem miljøer ved hjælp af arbejdsprocesser, der kan genbruges

Fuldført

Når du udruller dine ændringer i flere miljøer, er de trin, der er involveret i udrulning i hvert miljø, ens eller endda identiske. I dette undermodul lærer du, hvordan du designer dine arbejdsprocesser for at undgå gentagelser og for at gøre det muligt at genbruge din arbejdsproceskode.

Udrulning i flere miljøer

Når du har talt med dine kolleger på webstedsteamet, beslutter du dig for følgende arbejdsproces for dit legetøjsfirmas websted:

1. Arbejdsprocessen kører Bicep linter for at kontrollere, at Bicep-koden er gyldig og følger bedste praksis.

   Linting sker på Bicep-koden uden at skulle oprette forbindelse til Azure, så det er ligegyldigt, hvor mange miljøer du udruller til. Den kører kun én gang.

2. Arbejdsprocessen udrulles i testmiljøet og kræver:

   1. Kørsel af forhåndsgodkendelse af Azure Resource Manager.
   2. Udrulning af Bicep-koden.
   3. Kørsel af nogle test i dit testmiljø.

3. Hvis en del af arbejdsprocessen mislykkes, stopper hele arbejdsprocessen, så du kan undersøge og løse problemet. Men hvis alt lykkes, fortsætter arbejdsprocessen med at udrulle til dit produktionsmiljø:

   1. Arbejdsprocessen indeholder et eksempeltrin, der kører what if-handlingen i dit produktionsmiljø for at få vist de ændringer, der foretages i azure-produktionsressourcerne. What If-handlingen validerer også udrulningen, så du ikke behøver at køre et separat valideringstrin for dit produktionsmiljø.
   2. Arbejdsprocessen afbrydes midlertidigt for manuel validering.
   3. Hvis der modtages godkendelse, kører arbejdsprocessen udrulnings- og røgtest i dit produktionsmiljø.

Nogle af disse opgaver gentages mellem dine test- og produktionsmiljøer, og nogle køres kun for bestemte miljøer:

Opgave	Miljøer
Fnug	Ingen af delene – lining fungerer ikke mod et miljø
Bekræfte	Test kun
Preview	Kun produktion
Installere	Begge miljøer
Røgtest	Begge miljøer

Når du har brug for at gentage trin i arbejdsprocessen, er det ikke en god idé at kopiere og indsætte dine trindefinitioner. Det er nemt ved et uheld at lave diskrete fejl eller for ting at komme ud af synkronisering, når du duplikerer koden for din arbejdsproces. Og når du fremover skal foretage en ændring af trinnene, skal du huske at anvende ændringen flere steder. En bedre praksis er at bruge arbejdsprocesser, der kan genbruges.

Arbejdsprocesser, der kan genbruges

Med GitHub-handlinger kan du oprette sektioner med arbejdsprocesdefinitioner, der kan genbruges, ved at oprette en separat YAML-arbejdsprocesfil, der definerer trin eller job. Du kan oprette YAML-filer for at genbruge dele af en arbejdsproces flere gange i en enkelt arbejdsproces eller endda i flere arbejdsprocesser. Den arbejdsproces, du genbruger, er en kaldet arbejdsproces, og den arbejdsproces, der indeholder den, er en arbejdsproces. Konceptuelt kan du tænke på, at de er analoge med Bicep-moduler.

Når du opretter en arbejdsproces, der kan genbruges, kan du bruge udløseren workflow_call til at fortælle GitHub-handlinger, at arbejdsprocessen kan kaldes af andre arbejdsprocesser. Her er et grundlæggende eksempel på en arbejdsproces, der kan genbruges, og som er gemt i en fil med navnet script.yml:

on:
  workflow_call:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello world!

I arbejdsprocessen for kalderen henviser du til den kaldte arbejdsproces ved at inkludere nøgleordet uses: og angive stien til den kaldte arbejdsproces i det aktuelle lager:

on: 
  workflow_dispatch:

jobs:
  job:
    uses: ./.github/workflows/script.yml

Du kan også referere til en arbejdsprocesdefinitionsfil i et andet lager.

Kaldte arbejdsprocesinput og -hemmeligheder

Du kan bruge input og hemmeligheder til at gøre det nemmere at genbruge dine kaldte arbejdsprocesser, da du kan tillade små forskelle i dine arbejdsprocesser, når du bruger dem.

Når du opretter en kaldet arbejdsproces, kan du angive dens input og hemmeligheder øverst i filen:

on:
  workflow_call:
    inputs:
      environmentType:
        required: true
        type: string
    secrets:
      AZURE_CLIENT_ID:
        required: true
      AZURE_TENANT_ID:
        required: true
      AZURE_SUBSCRIPTION_ID:
        required: true

Du kan definere lige så mange input og hemmeligheder, du har brug for. Men på samme måde som med Bicep-parametre kan du prøve ikke at overforbruge input til arbejdsprocesser. Du bør gøre det nemt for andre at genbruge arbejdsprocessen uden at skulle angive for mange indstillinger.

Input kan have flere egenskaber, herunder:

• Inputtet navnet, som du bruger til at referere til inputtet i dine arbejdsprocesdefinitioner.
• Inputtypen . Input understøtter streng, talog booleske værdier.
• Inputtets standardværdi, hvilket er valgfrit. Hvis du ikke angiver en standardværdi, skal der angives en værdi, når arbejdsprocessen bruges i en arbejdsproces for kaldere.

Hemmeligheder har navne, men de har ikke typer eller standardværdier.

I eksemplet definerer arbejdsprocessen et obligatorisk strenginput med navnet environmentTypeog tre obligatoriske hemmeligheder med navnet AZURE_CLIENT_ID, AZURE_TENANT_IDog AZURE_SUBSCRIPTION_ID.

I arbejdsprocessen skal du bruge en særlig syntaks til at referere til værdien af parameteren, f.eks. i dette eksempel:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

Du overfører værdien for input til en kaldet arbejdsproces ved hjælp af nøgleordet with. Du skal definere værdierne for hvert input i afsnittet with . Du kan ikke bruge nøgleordet env til at referere til en arbejdsprocess miljøvariabler. Du sender hemmelige værdier til en kaldet arbejdsproces ved hjælp af nøgleordet secrets.

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Brug arbejdsbelastningsidentiteter fra kaldte arbejdsprocesser

Når du arbejder med kaldte arbejdsprocesser, definerer du ofte nogle af dine installationshandlinger på tværs af flere arbejdsprocesdefinitionsfiler. Du skal give tilladelse til opkaldsarbejdsprocessen, som derefter sikrer, at alle kaldte arbejdsprocesser kan få adgang til arbejdsprocessens identitet og godkende i Azure:

on: 
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  job-test:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Test
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_TEST }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  job-production:
    uses: ./.github/workflows/script.yml
    with:
      environmentType: Production
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID_PRODUCTION }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Kår

Du kan bruge arbejdsproces betingelser til at angive, om et trin eller et job skal køre, afhængigt af en regel, du angiver. Du kan kombinere input og arbejdsprocesbetingelser for at tilpasse udrulningsprocessen til flere situationer.

Forestil dig f.eks., at du definerer en arbejdsproces, der kører scripttrin. Du planlægger at genbruge skabelonen for hvert af dine miljøer. Når du udruller dit produktionsmiljø, skal du køre et andet trin. Sådan opnår du dette ved hjælp af betingelsen if på trinnet:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo Hello ${{ inputs.environmentType }}!

    - run: |
        echo This step only runs for production deployments.
      if: inputs.environmentType == 'Production'

Betingelsen her oversættes til: , hvis miljøtypeparameterens værdi er lig med 'Produktion', og kør derefter trinnet.

Selvom betingelser føjer fleksibilitet til din arbejdsproces, kan for mange af dem komplicere din arbejdsproces og gøre det sværere at forstå. Hvis du har mange betingelser i en kaldet arbejdsproces, kan du overveje at omdesigne den.

Du kan også bruge YAML-kommentarer til at forklare de betingelser, du bruger, og eventuelle andre aspekter af arbejdsprocessen, der kan kræve mere forklaring. Kommentarer hjælper med at gøre din arbejdsproces nemmere at forstå og arbejde med i fremtiden. Der er nogle eksempler på YAML-kommentarer i øvelserne i hele dette modul.