Hantera likheter mellan miljöer med hjälp av återanvändbara arbetsflöden

• 5 minuter

När du distribuerar ändringarna till flera miljöer är stegen som ingår i distributionen till varje miljö likartade eller till och med identiska. I den här lektionen får du lära dig hur du utformar arbetsflöden för att undvika upprepningar och för att tillåta återanvändning av arbetsflödeskoden.

Distribution till flera miljöer

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

1. Arbetsflödet 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.

2. Arbetsflödet distribueras till testmiljön och kräver:

   1. Köra förhandsvalidering av Azure Resource Manager.
   2. Distribuera Bicep-koden.
   3. Köra några tester mot testmiljön.

3. Om någon del av arbetsflödet misslyckas stoppas hela arbetsflödet så att du kan undersöka och lösa problemet. Men om allt lyckas fortsätter arbetsflödet att distribueras till produktionsmiljön:

   1. Arbetsflödet innehåller ett förhandsversionssteg som kör konsekvensåtgärden i produktionsmiljön för att visa en lista över de ändringar som ska göras i dina Azure-produktionsresurser. Konsekvensåtgärden verifierar även distributionen, så du behöver inte köra ett separat valideringssteg för produktionsmiljön.
   2. Arbetsflödet pausar för manuell validering.
   3. Om godkännande tas emot kör arbetsflödet distributions- och röktesterna mot din produktionsmiljö.

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

Uppgift	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 arbetsflödet är det inte bra att kopiera och klistra in dina stegdefinitioner. Det är lätt att oavsiktligt göra subtila misstag eller att saker blir osynkroniserade när du duplicerar arbetsflödets 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. En bättre metod är att använda återanvändbara arbetsflöden.

Återanvändbara arbetsflöden

Med GitHub Actions kan du skapa återanvändbara avsnitt av arbetsflödesdefinitioner genom att skapa en separat YAML-fil för arbetsflödet som definierar steg eller jobb. Du kan skapa YAML-filer för att återanvända delar av ett arbetsflöde flera gånger i ett enda arbetsflöde, eller till och med i flera arbetsflöden. Arbetsflödet som du återanvänder är ett kallat arbetsflöde, och arbetsflödet som innehåller det är ett uppringararbetsflöde. Konceptuellt kan du betrakta dem som analoga med Bicep-moduler.

När du skapar ett återanvändbart arbetsflöde använder workflow_call du utlösaren för att berätta för GitHub Actions att arbetsflödet kan anropas av andra arbetsflöden. Här är ett grundläggande exempel på ett återanvändbart arbetsflöde som sparats i en fil med namnet script.yml:

on:
  workflow_call:

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

I anropararbetsflödet refererar du till det anropade arbetsflödet genom att inkludera nyckelordet uses: och ange sökvägen till det anropade arbetsflödet i den aktuella lagringsplatsen:

on: 
  workflow_dispatch:

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

Du kan också referera till en arbetsflödesdefinitionsfil på en annan lagringsplats.

Kallas arbetsflödesindata och hemligheter

Du kan använda indata och hemligheter för att göra dina kallade arbetsflöden enklare att återanvända, eftersom du kan tillåta små skillnader i dina arbetsflöden när du använder dem.

När du skapar ett kallat arbetsflöde kan du ange dess indata och hemligheter ö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 definiera så många indata och hemligheter som du behöver. Men precis som Bicep-parametrar kan du försöka att inte överanvända arbetsflödesindata. Du bör göra det enkelt för någon annan att återanvända arbetsflödet utan att behöva ange för många inställningar.

Indata kan ha flera egenskaper, bland annat:

• Indatanamnet som du använder för att referera till indata i arbetsflödesdefinitionerna.
• Indatatypen. Indata stöder sträng-, tal- och booleska värden.
• Indatans standardvärde, som är valfritt. Om du inte anger något standardvärde måste ett värde anges när arbetsflödet används i ett anropararbetsflöde.

Hemligheter har namn, men de har inte typer eller standardvärden.

I exemplet definierar arbetsflödet en obligatorisk stränginmatning med namnet environmentType, och tre obligatoriska hemligheter med namnet AZURE_CLIENT_ID, AZURE_TENANT_IDoch AZURE_SUBSCRIPTION_ID.

I arbetsflödet använder du en särskild syntax för att referera till värdet för parametern, som i det här exemplet:

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

Du skickar värdet för indata till ett kallat arbetsflöde med hjälp av nyckelordet with . Du måste definiera värdena för varje indata i with avsnittet – du kan inte använda nyckelordet env för att referera till ett arbetsflödes miljövariabler. Du skickar hemliga värden till ett kallat arbetsflöde med hjälp av nyckelordet 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 }}

Använda arbetsbelastningsidentiteter från kallade arbetsflöden

När du arbetar med kallade arbetsflöden definierar du ofta några av dina distributionsåtgärder i flera definitionsfiler för arbetsflöden. Du måste ge behörighet till det anropande arbetsflödet, vilket sedan säkerställer att varje kallat arbetsflöde kan komma åt arbetsflödets identitet och autentisera till 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 }}

Villkor

Du kan använda arbetsflödesvillkor för att ange om ett steg eller ett jobb ska köras beroende på en regel som du anger. Du kan kombinera indata och arbetsflödesvillkor för att anpassa distributionsprocessen för flera situationer.

Anta till exempel att du definierar ett arbetsflöde 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 villkoret if i steget:

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'

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

Även om villkor ger flexibilitet i arbetsflödet kan för många av dem komplicera arbetsflödet och göra det svårare att förstå. Om du har många villkor i ett så kallat arbetsflöde kan du överväga att göra om det.

Använd även YAML-kommentarer för att förklara de villkor som du använder och andra aspekter av arbetsflödet som kan behöva mer förklaring. Kommentarer gör arbetsflödet enklare att förstå och arbeta med i framtiden. Det finns några exempel på YAML-kommentarer i övningarna i den här modulen.