Obsługa podobieństw między środowiskami przy użyciu przepływów pracy wielokrotnego użytku

5 min

Podczas wdrażania zmian w wielu środowiskach kroki wdrażania w każdym środowisku są podobne lub nawet identyczne. W tej lekcji dowiesz się, jak zaprojektować przepływy pracy, aby uniknąć powtórzeń i umożliwić ponowne użycie kodu przepływu pracy.

Wdrażanie w wielu środowiskach

Po rozmowie ze współpracownikami w zespole witryny internetowej decydujesz się na następujący przepływ pracy witryny internetowej twojej firmy:

Diagram przedstawiający szereg zadań przepływu pracy oraz wdrożenia testowe i produkcyjne.

Przepływ pracy uruchamia linter Bicep, aby sprawdzić, czy kod Bicep jest prawidłowy i postępuje zgodnie z najlepszymi rozwiązaniami.

Linting występuje w kodzie Bicep bez konieczności nawiązywania połączenia z platformą Azure, więc nie ma znaczenia, ile środowisk wdrażasz. Jest uruchamiany tylko raz.
Przepływ pracy jest wdrażany w środowisku testowym i wymaga:
1. Uruchamianie weryfikacji wstępnej usługi Azure Resource Manager.
2. Wdrażanie kodu Bicep.
3. Uruchamianie niektórych testów w środowisku testowym.
Jeśli którakolwiek część przepływu pracy zakończy się niepowodzeniem, cały przepływ pracy zostanie zatrzymany, aby można było zbadać i rozwiązać problem. Jeśli jednak wszystko powiedzie się, przepływ pracy będzie nadal wdrażany w środowisku produkcyjnym:
1. Przepływ pracy zawiera krok w wersji zapoznawczej, który uruchamia operację analizy warunkowej w środowisku produkcyjnym, aby wyświetlić listę zmian, które zostaną wprowadzone do produkcyjnych zasobów platformy Azure. Operacja analizy co-jeżeli weryfikuje również wdrożenie, więc nie trzeba uruchamiać oddzielnego kroku weryfikacji dla środowiska produkcyjnego.
2. Przepływ pracy wstrzymuje się na potrzeby ręcznej weryfikacji.
3. Jeśli zatwierdzenie zostanie odebrane, przepływ pracy uruchamia wdrożenia i testy weryfikacyjne kompilacji w środowisku produkcyjnym.

Niektóre z tych zadań są powtarzane między środowiskami testowymi i produkcyjnymi, a niektóre są uruchamiane tylko dla określonych środowisk:

Zadanie	Środowiska
Lint	Żadna z nich — linting nie działa w środowisku
Sprawdź poprawność	Tylko test
Podgląd	Tylko produkcja
Wdróż	Oba środowiska
Test weryfikacyjny kompilacji	Oba środowiska

Jeśli musisz powtórzyć kroki w przepływie pracy, kopiowanie i wklejanie definicji kroków nie jest dobrym rozwiązaniem. Łatwo jest przypadkowo popełnić subtelne błędy lub w przypadku, gdy kod przepływu pracy zostanie zduplikowany. A w przyszłości, gdy musisz wprowadzić zmianę w krokach, musisz pamiętać, aby zastosować zmianę w wielu miejscach. Lepszym rozwiązaniem jest użycie przepływów pracy wielokrotnego użytku.

Przepływy pracy wielokrotnego użytku

Funkcja GitHub Actions umożliwia tworzenie sekcji definicji przepływu pracy wielokrotnego użytku przez utworzenie oddzielnego pliku YAML przepływu pracy, który definiuje kroki lub zadania. Pliki YAML można tworzyć w celu wielokrotnego ponownego użycia części przepływu pracy w ramach jednego przepływu pracy, a nawet w wielu przepływach pracy. Ponownie używany przepływ pracy jest nazywany przepływem pracy, który zawiera przepływ pracy wywołujący. Koncepcyjnie można traktować je jako analogiczne do modułów Bicep.

Podczas tworzenia przepływu pracy wielokrotnego użytku użyjesz workflow_call wyzwalacza, aby poinformować funkcję GitHub Actions, że przepływ pracy może być wywoływany przez inne przepływy pracy. Oto podstawowy przykład przepływu pracy wielokrotnego użytku zapisany w pliku o nazwie script.yml:

on:
  workflow_call:

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

W przepływie pracy wywołującego odwołujesz się do wywoływanego przepływu pracy, dołączając uses: słowo kluczowe i określając ścieżkę do wywoływanego przepływu pracy w bieżącym repozytorium:

on: 
  workflow_dispatch:

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

Możesz również odwołać się do pliku definicji przepływu pracy w innym repozytorium.

Wywoływane dane wejściowe i wpisy tajne przepływu pracy

Możesz użyć danych wejściowych i wpisów tajnych , aby ułatwić ponowne użycie nazywanych przepływów pracy, ponieważ można zezwolić na niewielkie różnice w przepływach pracy za każdym razem, gdy ich używasz.

Podczas tworzenia wywoływanego przepływu pracy można wskazać jego dane wejściowe i wpisy tajne w górnej części pliku:

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

Możesz zdefiniować dowolną liczbę danych wejściowych i wpisów tajnych. Ale podobnie jak parametry Bicep, spróbuj nie nadużyć danych wejściowych przepływu pracy. Możesz ułatwić innym osobom ponowne użycie przepływu pracy bez konieczności określania zbyt wielu ustawień.

Dane wejściowe mogą mieć kilka właściwości, w tym:

Nazwa danych wejściowych używana do odwoływania się do danych wejściowych w definicjach przepływu pracy.
Typ danych wejściowych. Dane wejściowe obsługują ciągi, liczby i wartości logiczne .
Wartość domyślna danych wejściowych, która jest opcjonalna. Jeśli nie określisz wartości domyślnej, należy podać wartość, gdy przepływ pracy jest używany w przepływie pracy wywołującego.

Wpisy tajne mają nazwy, ale nie mają typów ani wartości domyślnych.

W tym przykładzie przepływ pracy definiuje obowiązkowe dane wejściowe ciągu o nazwie i trzy obowiązkowe wpisy tajne o nazwie environmentTypeAZURE_CLIENT_ID, AZURE_TENANT_IDi AZURE_SUBSCRIPTION_ID.

W przepływie pracy używasz specjalnej składni do odwoływania się do wartości parametru, tak jak w tym przykładzie:

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

Wartość danych wejściowych należy przekazać do wywoływanego przepływu pracy przy użyciu słowa kluczowego with . Należy zdefiniować wartości dla poszczególnych danych wejściowych w with sekcji — nie można użyć słowa kluczowego env , aby odwołać się do zmiennych środowiskowych przepływu pracy. Wartości wpisów tajnych są przekazywane do wywoływanego przepływu pracy przy użyciu słowa kluczowego 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 }}

Używanie tożsamości obciążeń z wywoływanych przepływów pracy

Podczas pracy z nazywanymi przepływami pracy często definiujesz niektóre akcje wdrażania w wielu plikach definicji przepływu pracy. Musisz udzielić uprawnień do przepływu pracy wywołującego, co gwarantuje, że każdy wywoływany przepływ pracy będzie mógł uzyskać dostęp do tożsamości przepływu pracy i uwierzytelnić się na platformie 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 }}

Warunki

Możesz użyć warunków przepływu pracy, aby określić, czy krok lub zadanie ma być uruchamiane w zależności od określonej reguły. Możesz połączyć dane wejściowe i warunki przepływu pracy, aby dostosować proces wdrażania w wielu sytuacjach.

Załóżmy na przykład, że zdefiniujesz przepływ pracy, który uruchamia kroki skryptu. Planujesz ponownie użyć szablonu dla każdego środowiska. Podczas wdrażania środowiska produkcyjnego chcesz uruchomić kolejny krok. Poniżej przedstawiono sposób, w jaki można to osiągnąć przy użyciu if warunku w 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'

Warunek przekłada się na: jeśli wartość parametru environmentType jest równa wartości "Production", uruchom krok.

Mimo że warunki dodają elastyczność przepływu pracy, zbyt wiele z nich może skomplikować przepływ pracy i utrudnić zrozumienie. Jeśli masz wiele warunków w wywoływanym przepływie pracy, warto rozważyć jego przeprojektowanie.