Entender os trabalhos do fluxo de trabalho

7 minutos

Os fluxos de trabalho permitem automatizar as etapas do seu processo de implantação. O processo pode incluir vários grupos lógicos de trabalhos que você deseja executar. Nesta unidade, você aprenderá sobre os trabalhos de fluxo de trabalho e como usá-los para adicionar processos de controle de qualidade às implantações do Bicep.

O que são trabalhos de fluxo de trabalho?

Os trabalhos ajudam você a dividir o fluxo de trabalho em diversos blocos lógicos. Cada trabalho pode conter uma ou mais etapas.

Diagrama que mostra um fluxo de trabalho com um trabalho. O trabalho contém quatro etapas.

Os trabalhos podem ser usados no fluxo de trabalho para marcar uma separação de interesses. Por exemplo, quando você trabalha com o código Bicep, a validação do código é um item separado da implantação do arquivo Bicep. Quando você usa um fluxo de trabalho automatizado, a criação e o teste do código são frequentemente chamados de CI (integração contínua). A implantação do código em um fluxo de trabalho automatizado costuma ser chamada de CD (implantação contínua).

Nos trabalhos de CI, você verifica a validade das alterações que foram feitas no seu código. Os trabalhos de CI fornecem garantia de qualidade. Eles podem ser executados sem afetar o ambiente de produção ao vivo.

Em muitas linguagens de programação, o código precisa ser compilado para que alguém possa executá-lo. Quando um arquivo Bicep é implantado, ele é convertido, ou transpilado, de Bicep para JSON. As ferramentas executam esse processo automaticamente. Na maioria das situações, você não precisa criar manualmente o código Bicep para modelos JSON no fluxo de trabalho. No entanto, ainda usamos o termo integração contínua quando falamos sobre o código Bicep porque as outras partes de CI ainda se aplicam, como a validação do código.

Depois que seus trabalhos de CI forem executados com êxito, você deverá ter mais confiança de que as alterações feitas também serão implantadas com êxito. Em trabalhos de CD, você implanta seu código em cada um dos ambientes. Geralmente, você começa com ambientes de teste e outros de não produção e passa para os de produção. Neste módulo, nós o implantaremos em um só ambiente. Em um módulo futuro, você aprenderá a estender o fluxo de trabalho de implantação para vários ambientes, como ambientes de produção e de não produção.

Os trabalhos são executados em paralelo por padrão. Você pode controlar como e quando cada trabalho é executado. Por exemplo, você pode configurar seus trabalhos de CD para serem executados somente depois dos trabalhos de CI. Também é possível ter vários trabalhos de CI que precisam ser executados em sequência, como para criar seu código e testá-lo. Você também pode ter um trabalho de reversão que só é executado quando os trabalhos de implantação anteriores falham.

Migração left-shift

Usando trabalhos, você pode verificar a qualidade do código antes de implantá-lo. Às vezes, esse processo é chamado de shifting left.

Considere uma linha do tempo das atividades que você executa ao escrever o código. A linha do tempo começa nas fases de planejamento e design. Em seguida, ela passa para as fases de criação e de teste. Por fim, você implanta sua solução e precisa fornecer suporte a ela.

Gráfico com uma linha do tempo no eixo horizontal, o custo no eixo vertical e uma linha que mostra que o custo aumenta quando mais tarde um erro é identificado.

É uma regra bem compreendida no desenvolvimento de software que quanto mais cedo no processo você encontrar um erro - mais próximo à esquerda da linha do tempo - mais fácil, rápido e barato será corrigi-lo. Quanto mais tarde no processo você encontrar um erro, mais difícil e complicado será corrigi-lo.

Portanto, a meta é deslocar a descoberta de problemas para a esquerda do diagrama anterior. Ao longo deste módulo, você verá como adicionar mais validações e testes à medida que o fluxo de trabalho progride.

Você pode até mesmo adicionar validações bem antes do início da implantação. Quando você trabalha com ferramentas como o GitHub, as solicitações de pull geralmente representam alterações que alguém da equipe deseja fazer no código na ramificação principal. É útil criar outro fluxo de trabalho que execute automaticamente as etapas de CI durante o processo de revisão da solicitação de pull. Essa técnica ajuda a validar se o código ainda funciona, mesmo com as alterações propostas. Se a validação for bem-sucedida, você terá certeza de que a alteração não causará problemas quando ela for mesclada na ramificação principal. Se a verificação falhar, você saberá que há mais trabalho a fazer antes de a solicitação de pull estar pronta para mesclagem. Em um módulo futuro, você aprenderá a configurar um processo de liberação adequado usando solicitações de pull e estratégias de branch.

Importante

A validação e os testes automatizados são tão eficazes quanto os testes que você escreve. É importante considerar o que você precisa testar e as etapas necessárias para garantir que a implantação esteja funcionando.

Definir um trabalho de fluxo de trabalho

Cada fluxo de trabalho contém pelo menos um trabalho e é possível definir mais trabalhos para atender às necessidades. Os trabalhos são executados em paralelo por padrão. O tipo de conta do GitHub que você tem determina o número de trabalhos que podem ser executados simultaneamente ao usar os executores hospedados no GitHub.

Imagine que você criou um arquivo Bicep que precisa ser implantado duas vezes: uma vez na infraestrutura dos Estados Unidos e outra na infraestrutura da Europa. Você também quer validar o código Bicep no fluxo de trabalho. Veja a seguinte ilustração de um fluxo de trabalho com diversos trabalhos que define um processo semelhante:

Diagrama que mostra um fluxo de trabalho com os trabalhos Validar, Implantar nos EUA e Implantar na Europa em execução paralela.

Observe que este exemplo tem três trabalhos. O trabalho Validar é semelhante a um trabalho de CI. Em seguida, são executados os trabalhos Implantar nos EUA e Implantar na Europa. Cada um implanta o código em um dos ambientes. Por padrão, os trabalhos são executados em paralelo.

Veja como os trabalhos são definidos em um arquivo YAML de fluxo de trabalho:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Controlar a sequência de trabalhos

Você pode adicionar dependências entre os trabalhos para alterar a ordem. Continuando o exemplo anterior, você provavelmente quer validar o código antes de executar os trabalhos de implantação, como mostrado abaixo:

Diagrama que mostra um fluxo de trabalho com os trabalhos Validar, Implantar nos EUA e Implantar na Europa, em que os dois trabalhos de implantação são executados em paralelo.

Você pode especificar as dependências entre trabalhos usando a palavra-chave needs:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Quando você usa a palavra-chave needs, o fluxo de trabalho espera que o trabalho dependente seja concluído com sucesso antes de iniciar o seguinte. Se o fluxo de trabalho detectar que todas as dependências de vários trabalhos foram atendidas, ele poderá executar esses trabalhos em paralelo.

Observação

Na verdade, os trabalhos serão executados em paralelo apenas se você tiver executores suficientes para executar diversos trabalhos ao mesmo tempo. O número de executores hospedados no GitHub que é possível usar depende do tipo de conta do GitHub que você tem. Você pode comprar outro plano de conta do GitHub caso precise de mais trabalhos paralelos.

Às vezes, você quer executar um trabalho quando outro anterior falha. Por exemplo, veja um fluxo de trabalho diferente a seguir. Se a implantação falhar, um trabalho de reversão será executado imediatamente em seguida:

Diagrama que mostra um fluxo de trabalho com o trabalhos Implantar e uma condição para que uma falha nesse trabalho resulte na execução do trabalho Reverter.

Use a palavra-chave if para especificar uma condição que deve ser atendida para executar um trabalho:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deploy: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy."
  rollback: 
    runs-on: ubuntu-latest
    needs: deploy
    if: ${{ failure() }}
    steps:
      - run: echo "Here is where you'd perform the steps to roll back a failure."

No exemplo anterior, quando tudo dá certo, o fluxo de trabalho executa primeiro o trabalho Testar e, depois, o trabalho Implantar. Ele ignora o trabalho Reverter. No entanto, se o trabalho Testar ou Implantar falha, o fluxo de trabalho executará o trabalho Reverter. Você verá mais sobre a reversão posteriormente neste módulo.

Trabalhos de implantação do Bicep

Um fluxo de trabalho típico de implantação do Bicep contém vários trabalhos. À medida que o fluxo de trabalho passa pelos trabalhos, o objetivo é tornar-se cada vez mais confiante de que os trabalhos posteriores serão bem-sucedidos. Veja as seguintes tarefas comuns para um fluxo de trabalho de implantação do Bicep:

Diagrama que mostra um fluxo de trabalho de implantação de Bicep com cinco tarefas: Lint, Validar, Visualizar, Implantar e Smoke Test.

Lint: use o linter do Bicep para verificar se o arquivo Bicep tem o formato correto e não contém erros óbvios.
Validar: use o processo de validação de comprovação do Azure Resource Manager para verificar se problemas podem ocorrer durante a implantação.
Visualizar: Use o comando Teste de hipóteses para validar a lista de alterações que são aplicadas em seu ambiente do Azure. Peça a uma pessoa que analise manualmente os resultados do teste de hipóteses e aprove o fluxo de trabalho para prosseguir.
Implantar: envie a implantação ao Resource Manager e aguarde até que ela seja concluída.
Smoke Test: Execute verificações básicas pós-implantação em alguns dos recursos importantes que você implantou. Essas verificações são chamadas de smoke tests de infraestrutura.

Sua organização pode ter uma sequência diferente de trabalhos ou precisar integrar as implantações do Bicep a um fluxo de trabalho que implanta outros componentes. Depois de entender como os trabalhos funcionam, você pode projetar um fluxo de trabalho para atender às suas necessidades.

Cada trabalho é executado em uma nova instância do executor que começa em um ambiente limpo. Portanto, em cada trabalho, você normalmente precisa conferir o código-fonte como a primeira etapa. Você também precisa entrar no ambiente do Azure em cada trabalho que interage com o Azure.

Ao longo deste módulo, você aprenderá mais sobre esses trabalhos e criará progressivamente um fluxo de trabalho que inclui cada um deles. Você também aprenderá os seguintes tópicos: