Overeenkomsten tussen omgevingen afhandelen met behulp van herbruikbare werkstromen

5 minuten

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

Implementatie in meerdere omgevingen

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

Diagram met een reeks werkstroomtaken en bevat test- en productie-implementaties.

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

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.
De werkstroom wordt geïmplementeerd in de testomgeving en vereist het volgende:
1. De voorbereidende validatie van Azure Resource Manager uitvoeren.
2. De Bicep-code implementeren.
3. Voer enkele tests uit op uw testomgeving.
Als een deel van de werkstroom mislukt, stopt de hele werkstroom zodat u het probleem kunt onderzoeken en oplossen. Maar als alles slaagt, blijft uw werkstroom implementeren in uw productieomgeving:
1. De werkstroom bevat een preview-stap, waarmee de wat-als-bewerking in uw productieomgeving wordt uitgevoerd om de wijzigingen weer te geven die worden aangebracht in uw Azure-productiebronnen. De wat-als-bewerking valideert ook uw implementatie, dus u hoeft geen afzonderlijke validatiestap uit te voeren voor uw productieomgeving.
2. De werkstroom wordt onderbroken voor handmatige validatie.
3. Als er goedkeuring wordt ontvangen, voert de werkstroom de implementatie- en betrouwbaarheidstests uit op uw productieomgeving.

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

Opdracht	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 werkstroom moet herhalen, is het kopiëren en plakken van uw stapdefinities geen goede gewoonte. Het is eenvoudig om per ongeluk subtiele fouten te maken of om te voorkomen dat de synchronisatie wordt uitgevoerd wanneer u de code van uw werkstroom 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. Een betere gewoonte is om herbruikbare werkstromen te gebruiken.

Herbruikbare werkstromen

Met GitHub Actions kunt u herbruikbare secties van werkstroomdefinities maken door een afzonderlijk YAML-werkstroombestand te maken dat stappen of taken definieert. U kunt YAML-bestanden maken om delen van een werkstroom meerdere keren binnen één werkstroom of zelfs in meerdere werkstromen opnieuw te gebruiken. De werkstroom die u opnieuw gebruikt, is een zogenaamde werkstroom en de werkstroom die deze bevat, is een aanroeperwerkstroom. Conceptueel gezien kunt u ze beschouwen als vergelijkbaar met Bicep-modules.

Wanneer u een herbruikbare werkstroom maakt, gebruikt u de workflow_call trigger om GitHub Actions te vertellen dat de werkstroom kan worden aangeroepen door andere werkstromen. Hier volgt een eenvoudig voorbeeld van een herbruikbare werkstroom, opgeslagen in een bestand met de naam script.yml:

on:
  workflow_call:

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

In de aanroeperwerkstroom verwijst u naar de aangeroepen werkstroom door het uses: trefwoord op te geven en het pad op te geven naar de aangeroepen werkstroom in de huidige opslagplaats:

on: 
  workflow_dispatch:

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

U kunt ook verwijzen naar een werkstroomdefinitiebestand in een andere opslagplaats.

Werkstroominvoer en -geheimen genoemd

U kunt invoer en geheimen gebruiken om uw zogenaamde werkstromen gemakkelijker te hergebruiken, omdat u kleine verschillen in uw werkstromen kunt toestaan wanneer u ze gebruikt.

Wanneer u een aangeroepen werkstroom maakt, kunt u de invoer en geheimen bovenaan het bestand aangeven:

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

U kunt zoveel invoer- en geheimen definiëren als u nodig hebt. Maar probeer niet te veel werkstroominvoer te gebruiken, net zoals Bicep-parameters. U moet het voor iemand anders gemakkelijk maken om uw werkstroom opnieuw te gebruiken zonder te veel instellingen op te geven.

Invoer kan verschillende eigenschappen hebben, waaronder:

De invoernaam, die u gebruikt om te verwijzen naar de invoer in uw werkstroomdefinities.
Het invoertype. Invoer ondersteunt tekenreeks-, getal- en Booleaanse waarden.
De standaardwaarde van de invoer, die optioneel is. Als u geen standaardwaarde opgeeft, moet er een waarde worden opgegeven wanneer de werkstroom wordt gebruikt in een aanroeperwerkstroom.

Geheimen hebben namen, maar ze hebben geen typen of standaardwaarden.

In het voorbeeld definieert de werkstroom een verplichte tekenreeksinvoer met de naam environmentType, en drie verplichte geheimen met de naam AZURE_CLIENT_ID, AZURE_TENANT_IDen AZURE_SUBSCRIPTION_ID.

In uw werkstroom gebruikt u een speciale syntaxis om te verwijzen naar de waarde van de parameter, zoals in dit voorbeeld:

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

U geeft de waarde voor invoer door aan een aangeroepen werkstroom met behulp van het with trefwoord. U moet de waarden definiëren voor elke invoer in de with sectie. U kunt het env trefwoord niet gebruiken om te verwijzen naar de omgevingsvariabelen van een werkstroom. U geeft geheime waarden door aan een aangeroepen werkstroom met behulp van het secrets trefwoord.

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 }}

Workloadidentiteiten van aangeroepen werkstromen gebruiken

Wanneer u met aangeroepen werkstromen werkt, definieert u vaak een aantal van uw implementatieacties in meerdere werkstroomdefinitiebestanden. U moet toestemming verlenen aan de aanroeperwerkstroom, die er vervolgens voor zorgt dat elke aangeroepen werkstroom toegang heeft tot de identiteit van de werkstroom en zich kan verifiëren bij 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 }}

Voorwaarden

U kunt werkstroomvoorwaarden gebruiken om op te geven of een stap of taak moet worden uitgevoerd, afhankelijk van een regel die u opgeeft. U kunt invoer- en werkstroomvoorwaarden combineren om uw implementatieproces voor meerdere situaties aan te passen.

Stel dat u een werkstroom 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 voorwaarde in de stap:

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'

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

Hoewel voorwaarden flexibiliteit toevoegen aan uw werkstroom, kunnen er te veel van uw werkstroom uw werkstroom bemoeilijken en het moeilijker te begrijpen maken. Als u veel voorwaarden in een aangeroepen werkstroom hebt, kunt u overwegen deze opnieuw te ontwerpen.