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

5 minutos

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

Implantação em vários ambientes

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

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

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

O lint ocorre no código Bicep sem a necessidade de se conectar ao Azure, portanto, não importa em quantos ambientes você está implantando. Ele é executado apenas uma vez.
O fluxo de trabalho é implantado no ambiente de teste e requer:
1. Executar a validação pré-lançamento do Azure Resource Manager.
2. Implantar o código Bicep.
3. Executar alguns testes em seu ambiente de teste.
Se qualquer parte do fluxo de trabalho falhar, o fluxo de trabalho inteiro será interrompido para que você possa investigar e resolver o problema. Porém, se tudo for bem-sucedido, o fluxo de trabalho continuará sendo implantado em seu ambiente de produção:
1. O fluxo de trabalho inclui uma etapa de versão prévia, que executa a operação what-if em seu ambiente de produção para listar as alterações que serão feitas em seus recursos do Azure de produção. A operação what-if também valida sua implantação, para que você não precise 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 smoke tests em seu ambiente de produção.

Algumas dessas tarefas são repetidas entre seus ambientes de teste e produção e alguns são executados somente para ambientes específicos:

Tarefa	Ambientes
Lint	Nenhum – o lint não funciona em um ambiente
Validar	Somente teste
Versão Prévia	Somente produção
Implantar	Ambos os ambientes
Smoke Test	Ambos os ambientes

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

Fluxos de trabalho reutilizáveis

O GitHub Actions permite que você crie 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 é um fluxo de trabalho chamado e o fluxo de trabalho que o inclui é um fluxo de trabalho de chamador. Conceitualmente, você pode considerá-los análogos aos módulos Bicep.

Quando você cria um fluxo de trabalho reutilizável, usa o gatilho workflow_call para informar o GitHub Actions de que o fluxo de trabalho pode ser chamado por outros fluxos de trabalho. Veja 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ê faz referência ao fluxo de trabalho chamado, incluindo a palavra-chave uses: e especificando o caminho para o fluxo de trabalho chamado dentro do repositório atual:

on: 
  workflow_dispatch:

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

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

Entradas e segredos do fluxo de trabalho chamado

Você pode usar entradas e segredos para facilitar a reutilização dos fluxos de trabalho chamados, pois 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 as entradas e os segredos dele 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 forem necessários. Mas, assim como os parâmetros Bicep, tente não fazer uso excessivo das entradas de fluxo de trabalho. Você deve facilitar para outra pessoa reutilizar seu fluxo de trabalho sem precisar especificar muitas configurações.

As entradas podem ter várias propriedades, incluindo:

O nome de entrada, que você usa para se referir à entrada em suas definições de fluxo de trabalho.
O tipo de entrada. As entradas dão suporte a valores de cadeia de caracteres, número e boolianos.
O valor padrão da entrada, que é opcional. Se você não especificar um valor padrão, um valor precisará 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_ID e 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 }}!

Passe o valor de entradas para um fluxo de trabalho chamado usando a palavra-chave with. Você precisa definir os valores de cada entrada na seção with. Você não pode usar a palavra-chave env para se referir às variáveis de ambiente de um fluxo de trabalho. Passe os valores de segredo 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 chamador, o que garante que todos os fluxos de trabalho chamados possam acessar a identidade do fluxo de trabalho e autenticar-se 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 condições de fluxo de trabalho para especificar se uma etapa ou um trabalho deverá ser executado dependendo de uma regra que você especificar. Você pode combinar entradas e condições de fluxo de trabalho para personalizar o processo de implantação para várias situações.

Por exemplo, imagine que você defina um fluxo de trabalho que executa etapas de script. Você planeja reutilizar o modelo para cada um dos seus ambientes. Ao implantar o ambiente de produção, você executa uma etapa adicional. Veja como você pode fazer isso usando a condição if 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 fluxo de trabalho, muitas delas podem complicar seu fluxo de trabalho e dificultar a compreensão. Se você tiver muitas condições em um fluxo de trabalho chamado, convém considerar reprojetá-lo.