Zpracování podobností mezi prostředími pomocí opakovaně použitelných pracovních postupů

Dokončeno

Když nasadíte změny do více prostředí, kroky, které jsou součástí nasazení do každého prostředí, jsou podobné nebo dokonce identické. V této lekci se dozvíte, jak navrhnout pracovní postupy, abyste se vyhnuli opakování a umožnili opakované použití kódu pracovního postupu.

Nasazení do několika prostředí

Po komunikaci s kolegy v týmu webu se rozhodnete pro tento pracovní postup pro web vaší společnosti:

Diagram znázorňující řadu úloh pracovního postupu a zahrnuje testovací a produkční nasazení

  1. Pracovní postup spustí linter Bicep a zkontroluje, jestli je kód Bicep platný a dodržuje osvědčené postupy.

    Lintování probíhá v kódu Bicep bez nutnosti připojení k Azure, takže nezáleží na tom, do kolika prostředí nasazujete. Spustí se jenom jednou.

  2. Pracovní postup se nasadí do testovacího prostředí a vyžaduje:

    1. Spuštění předběžného ověření Azure Resource Manageru
    2. Nasazení kódu Bicep
    3. Spuštění některých testů v testovacím prostředí
  3. Pokud některá část pracovního postupu selže, celý pracovní postup se zastaví, abyste mohli problém prošetřit a vyřešit. Pokud ale vše proběhne úspěšně, váš pracovní postup se bude dál nasazovat do produkčního prostředí:

    1. Tento pracovní postup obsahuje krok preview, který spustí operaci citlivostní operace v produkčním prostředí a zobrazí seznam změn provedených v produkčních prostředcích Azure. Operace citlivostní operace také ověří vaše nasazení, takže pro produkční prostředí nemusíte spouštět samostatný ověřovací krok.
    2. Pracovní postup se pozastaví pro ruční ověření.
    3. Pokud je přijato schválení, pracovní postup spustí nasazení a orientační testy ve vašem produkčním prostředí.

Některé z těchto úloh se opakují mezi testovacím a produkčním prostředím a některé se spouštějí jenom pro konkrétní prostředí:

Úloha Prostředí
Chomáče vláken bavlny Ani jedno – linting nefunguje s prostředím.
Ověřit Pouze test
Preview Pouze produkční prostředí
Nasadit Obě prostředí
Zahořování Obě prostředí

Pokud potřebujete opakovat kroky v pracovním postupu, kopírování a vložení definic kroků není dobrým postupem. Při duplikování kódu pracovního postupu je snadné udělat drobné chyby nebo věci, které se nesynchronizují. A v budoucnu, když potřebujete provést změnu kroků, musíte si pamatovat, že změnu použijete na více místech. Lepším postupem je použít opakovaně použitelné pracovní postupy.

Opakovaně použitelné pracovní postupy

GitHub Actions umožňuje vytvářet opakovaně použitelné oddíly definic pracovních postupů vytvořením samostatného souboru YAML pracovního postupu, který definuje kroky nebo úlohy. Soubory YAML můžete vytvořit pro opakované použití částí pracovního postupu vícekrát v rámci jednoho pracovního postupu nebo dokonce v několika pracovních postupech. Pracovní postup, který znovu použijete, je označovaný jako pracovní postup a pracovní postup, který obsahuje pracovní postup volajícího. Koncepčně si je můžete představit jako analogické k modulům Bicep.

Když vytvoříte opakovaně použitelný pracovní postup, pomocí triggeru workflow_call sdělíte GitHub Actions, že pracovní postup může volat jiné pracovní postupy. Tady je základní příklad opakovaně použitelného pracovního postupu uloženého v souboru s názvem script.yml:

on:
  workflow_call:

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

V pracovním postupu volajícího odkazujete na volaný pracovní postup zahrnutím klíčového uses: slova a zadáním cesty k volaného pracovního postupu v aktuálním úložišti:

on: 
  workflow_dispatch:

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

Můžete také odkazovat na definiční soubor pracovního postupu v jiném úložišti.

Označované jako vstupy a tajné kódy pracovního postupu

Pomocí vstupů a tajných kódů můžete usnadnit opakované použití volaných pracovních postupů, protože můžete povolit malé rozdíly v pracovních postupech, kdykoli je použijete.

Při vytváření volaného pracovního postupu můžete indikovat jeho vstupy a tajné kódy v horní části souboru:

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

Můžete definovat tolik vstupů a tajných kódů, kolik potřebujete. Ale stejně jako parametry Bicep se nepokoušejte přečerpovat vstupy pracovního postupu. Pro někoho jiného byste měli usnadnit opakované použití pracovního postupu, aniž byste museli zadávat příliš mnoho nastavení.

Vstupy můžou mít několik vlastností, mezi které patří:

  • Název vstupu, který použijete k odkazu na vstup v definicích pracovního postupu.
  • Typ vstupu. Vstupy podporují řetězcové, číselné a logické hodnoty.
  • Výchozí hodnota vstupu, která je volitelná. Pokud nezadáte výchozí hodnotu, je nutné zadat hodnotu, když se pracovní postup použije v pracovním postupu volajícího.

Tajné kódy mají názvy, ale nemají typy ani výchozí hodnoty.

V příkladu pracovní postup definuje povinný řetězcový vstup s názvem environmentType, a tři povinné tajné kódy s názvem AZURE_CLIENT_ID, AZURE_TENANT_IDa AZURE_SUBSCRIPTION_ID.

V pracovním postupu použijete speciální syntaxi k odkazování na hodnotu parametru, například v tomto příkladu:

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

Hodnotu pro vstupy předáte volaný pracovní postup pomocí klíčového with slova. Potřebujete definovat hodnoty pro každý vstup v oddílu with – klíčové slovo nemůžete použít env k odkazování na proměnné prostředí pracovního postupu. Tajné hodnoty předáte do volaný pracovní postup pomocí klíčového secrets slova.

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

Použití identit úloh z volaných pracovních postupů

Při práci s volanými pracovními postupy často definujete některé akce nasazení napříč několika definičními soubory pracovního postupu. Potřebujete udělit oprávnění k pracovnímu postupu volajícího, který pak zajistí, že každý volaný pracovní postup bude mít přístup k identitě pracovního postupu a ověřit ho v 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 }}

Podmínky

Podmínky pracovního postupu můžete použít k určení, jestli se má krok nebo úloha spouštět v závislosti na zadaném pravidlu. Můžete kombinovat vstupy a podmínky pracovního postupu a přizpůsobit tak proces nasazení v několika situacích.

Představte si například, že definujete pracovní postup, který spouští kroky skriptu. Chcete šablonu znovu použít pro každé prostředí. Když nasadíte produkční prostředí, chcete spustit další krok. Tady je postup, jak toho dosáhnout pomocí if podmínky v kroku:

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'

Podmínka se zde přeloží na: pokud je hodnota parametru environmentType rovna "Production", pak spusťte krok.

I když podmínky vašemu pracovnímu postupu přidávají flexibilitu, příliš mnoho z nich může pracovní postup komplikovat a znesnadnit pochopení. Pokud máte v takzvaném pracovním postupu mnoho podmínek, můžete zvážit jeho návrh.

Komentáře YAML také použijte k vysvětlení podmínek, které používáte, a všech dalších aspektů pracovního postupu, které mohou vyžadovat další vysvětlení. Komentáře vám pomůžou usnadnit pochopení pracovního postupu a práci s nima v budoucnu. Ve cvičeních v tomto modulu jsou k dispozici některé příklady komentářů YAML.