Lidar com semelhanças entre ambientes usando fluxos de trabalho reutilizáveis

5 minutos

Quando você implanta suas alterações em vários ambientes, as etapas envolvidas na implantação em cada ambiente são semelhantes ou até mesmo idênticas. Nesta unidade, você aprenderá como projetar seus fluxos de trabalho para evitar a repetição e permitir a reutilização do código do fluxo de trabalho.

Implantação em vários ambientes

Depois de conversar com seus colegas da equipe do site, você decide sobre o seguinte fluxo de trabalho para o site da sua empresa de brinquedos:

Diagrama que mostra uma série de trabalhos de fluxo de trabalho e inclui implantações de teste e produção.

O fluxo de trabalho executa o linter do Bicep para verificar se o código do Bicep é válido e segue as práticas recomendadas.

O Linting acontece no código Bicep sem precisar se conectar ao Azure, portanto, não importa em quantos ambientes você está implantando. Funciona apenas uma vez.
O fluxo de trabalho é implantado no ambiente de teste e requer:
1. Executando a validação de comprovação do Azure Resource Manager.
2. Implantando o código Bicep.
3. Executando alguns testes em seu ambiente de teste.
Se qualquer parte do fluxo de trabalho falhar, todo o fluxo de trabalho será interrompido para que você possa investigar e resolver o problema. Mas se tudo for bem-sucedido, seu fluxo de trabalho continuará a ser implantado em seu ambiente de produção:
1. O fluxo de trabalho inclui uma etapa de visualização, que executa a operação hipotética em seu ambiente de produção para listar as alterações que serão feitas em seus recursos de produção do Azure. A operação hipotética também valida sua implantação, portanto, você não precisa executar uma etapa de validação separada para seu ambiente de produção.
2. O fluxo de trabalho é pausado para validação manual.
3. Se a aprovação for recebida, o fluxo de trabalho executará a implantação e os testes de fumaça em seu ambiente de produção.

Algumas dessas tarefas são repetidas entre seus ambientes de teste e produção, e algumas são executadas apenas para ambientes específicos:

Task	Ambientes
Linho	Nem - o forro não funciona contra um ambiente
Validar	Apenas teste
Pré-visualizar	Apenas produção
Implementar	Ambos os ambientes
Teste de fumaça	Ambos os ambientes

Quando você precisa repetir etapas em seu fluxo de trabalho, copiar e colar suas definições de etapas não é uma boa prática. É fácil cometer erros sutis acidentalmente ou que as coisas fiquem fora de sincronia quando você duplica o código do seu fluxo de trabalho. E no futuro, quando você precisar fazer uma alteração nas etapas, você tem que se lembrar de aplicar a mudança em vários lugares. Uma prática melhor é usar fluxos de trabalho reutilizáveis.

Fluxos de trabalho reutilizáveis

As Ações do GitHub permitem criar seções reutilizáveis de definições de fluxo de trabalho criando um arquivo YAML de fluxo de trabalho separado que define etapas ou trabalhos. Você pode criar arquivos YAML para reutilizar partes de um fluxo de trabalho várias vezes em um único fluxo de trabalho ou até mesmo em vários fluxos de trabalho. O fluxo de trabalho que você reutiliza é chamado fluxo de trabalho e o fluxo de trabalho que o inclui é um fluxo de trabalho de chamador. Conceitualmente, você pode pensar neles como sendo análogos aos módulos Bicep.

Ao criar um fluxo de trabalho reutilizável, você usa o gatilho para informar ao workflow_call GitHub Actions que o fluxo de trabalho pode ser chamado por outros fluxos de trabalho. Aqui está um exemplo básico de um fluxo de trabalho reutilizável, salvo em um arquivo chamado script.yml:

on:
  workflow_call:

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

No fluxo de trabalho do chamador, você se refere ao fluxo de trabalho chamado incluindo a uses: palavra-chave e especificando o caminho para o fluxo de trabalho chamado no repositório atual:

on: 
  workflow_dispatch:

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

Você também pode consultar um arquivo de definição de fluxo de trabalho em outro repositório.

Chamadas entradas e segredos do fluxo de trabalho

Você pode usar entradas e segredos para tornar seus fluxos de trabalho chamados mais fáceis de reutilizar, porque você pode permitir pequenas diferenças em seus fluxos de trabalho sempre que usá-los.

Ao criar um fluxo de trabalho chamado, você pode indicar suas entradas e segredos na parte superior do arquivo:

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

Você pode definir quantas entradas e segredos precisar. Mas, assim como os parâmetros do Bicep, tente não usar demais as entradas do fluxo de trabalho. Você deve facilitar a reutilização do fluxo de trabalho por outra pessoa sem precisar especificar muitas configurações.

As entradas podem ter várias propriedades, incluindo:

O nome da entrada, que você usa para se referir à entrada em suas definições de fluxo de trabalho.
O tipo de entrada. As entradas suportam valores de cadeia de caracteres, número e booleanos .
O valor padrão da entrada, que é opcional. Se você não especificar um valor padrão, um valor deverá ser fornecido quando o fluxo de trabalho for usado em um fluxo de trabalho de chamador.

Os segredos têm nomes, mas não têm tipos ou valores padrão.

No exemplo, o fluxo de trabalho define uma entrada de cadeia de caracteres obrigatória chamada environmentType, e três segredos obrigatórios chamados AZURE_CLIENT_ID, AZURE_TENANT_IDe AZURE_SUBSCRIPTION_ID.

No fluxo de trabalho, você usa uma sintaxe especial para se referir ao valor do parâmetro, como neste exemplo:

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

Você passa o valor de entradas para um fluxo de trabalho chamado usando a with palavra-chave. Você precisa definir os valores para cada entrada dentro da with seção - você não pode usar a env palavra-chave para se referir às variáveis de ambiente de um fluxo de trabalho. Você passa valores secretos para um fluxo de trabalho chamado usando a palavra-chave 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 }}

Usar identidades de carga de trabalho de fluxos de trabalho chamados

Quando você trabalha com fluxos de trabalho chamados, geralmente define algumas de suas ações de implantação em vários arquivos de definição de fluxo de trabalho. Você precisa conceder permissão ao fluxo de trabalho do chamador, o que garante que cada fluxo de trabalho chamado possa acessar a identidade do fluxo de trabalho e autenticar no 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 }}

Condições

Você pode usar as condições do fluxo de trabalho para especificar se uma etapa ou um trabalho deve ser executado, dependendo de uma regra especificada. Você pode combinar entradas e condições de fluxo de trabalho para personalizar seu processo de implantação para várias situações.

Por exemplo, imagine que você defina um fluxo de trabalho que execute etapas de script. Você planeja reutilizar o modelo para cada um dos seus ambientes. Ao implantar seu ambiente de produção, você deseja executar outra etapa. Veja como você pode conseguir isso usando a if condição na etapa:

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'

A condição aqui se traduz em: se o valor do parâmetro environmentType for igual a 'Production', execute a etapa.

Embora as condições adicionem flexibilidade ao seu fluxo de trabalho, muitas delas podem complicar o fluxo de trabalho e torná-lo mais difícil de entender. Se você tiver muitas condições em um fluxo de trabalho chamado, convém considerar redesenhá-lo.