Compreender os trabalhos do fluxo de trabalho

Concluído

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

O que são trabalhos de fluxo de trabalho?

Os trabalhos ajudam você a dividir seu fluxo de trabalho em vários blocos lógicos. Cada trabalho pode conter uma ou mais etapas.

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

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

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

Depois que seus trabalhos de CI forem executados com êxito, você ganhará maior 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 seus ambientes. Normalmente, você começa com ambientes de teste e outros ambientes que não são de produção e, em seguida, passa para ambientes de produção. Neste módulo, implantaremos em um único ambiente. Em um módulo futuro, você aprenderá como estender seu fluxo de trabalho de implantação para implantar em vários ambientes, como ambientes de não-produção e produção.

Os trabalhos são executados em paralelo por padrão. Você pode controlar como e quando cada tarefa é executada. Por exemplo, você pode configurar seus trabalhos de CD para serem executados somente depois que os trabalhos de CI forem executados com êxito. Ou, você pode ter vários trabalhos de CI que precisam ser executados em sequência, como para criar seu código e, em seguida, testá-lo. Você também pode incluir um trabalho de reversão que é executado somente se os trabalhos de implantação anteriores falharem.

Deslocando para a esquerda

Usando trabalhos, você pode verificar a qualidade do seu código antes de implantá-lo. Esse processo às vezes é chamado de deslocamento para a esquerda.

Considere uma linha do tempo das atividades que você executa quando escreve código. O cronograma começa a partir das fases de planejamento e projeto. Em seguida, passa para as fases de construção e teste. Finalmente, você implanta e, em seguida, tem que dar suporte à sua solução.

É uma regra bem compreendida no desenvolvimento de software que quanto mais cedo no processo você encontrar um erro — quanto mais próximo à esquerda da linha do tempo — mais fácil, rápido e barato é corrigir. Quanto mais tarde no seu processo você pegar um erro, mais difícil e complicado se torna corrigir.

Assim, o objetivo é deslocar a descoberta de problemas para a esquerda do diagrama anterior. Ao longo deste módulo, você verá como pode adicionar mais validação e testes ao seu fluxo de trabalho à medida que ele progride.

Você pode até mesmo adicionar validação bem antes do início da implantação. Quando você trabalha com ferramentas como o GitHub, as solicitações pull geralmente representam alterações que alguém da sua equipe deseja fazer no código em sua 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 pull. Esta técnica ajuda a validar que o código ainda funciona, mesmo com as alterações propostas. Se a validação for bem-sucedida, você terá alguma confiança de que a alteração não causará problemas quando for mesclada à sua ramificação principal. Se a verificação falhar, você sabe que há mais trabalho a fazer antes que a solicitação pull esteja pronta para mesclar. Em um módulo futuro, você aprenderá mais sobre como configurar um processo de liberação adequado usando solicitações pull e estratégias de ramificação.

Importante

A validação e os testes automatizados são tão eficazes quanto os testes que você escreve. É importante considerar as coisas que você precisa testar e as etapas que precisa executar para ter certeza de que sua implantação está OK.

Definir um trabalho de fluxo de trabalho

Cada fluxo de trabalho contém pelo menos um trabalho, e você pode definir mais trabalhos para atender às suas 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 você pode executar simultaneamente quando usa corredores hospedados no GitHub.

Imagine que você criou um arquivo Bicep que precisa implantar duas vezes: uma para infraestrutura nos Estados Unidos e outra para infraestrutura na Europa. Você também deseja validar seu código Bicep em seu fluxo de trabalho. Aqui está uma ilustração de um fluxo de trabalho multitarefa que define um processo semelhante:

Observe que este exemplo tem três trabalhos. O trabalho Validar é semelhante a um trabalho de CI. Em seguida, os trabalhos Implantar EUA e Implantar Europa são executados. 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 deseja validar seu código antes de executar seus trabalhos de implantação, assim:

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

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 aguarda que o trabalho dependente seja concluído com êxito antes de iniciar o próximo trabalho. Se o fluxo de trabalho detetar que todas as dependências de vários trabalhos foram satisfeitas, ele poderá executá-los em paralelo.

Nota

Na realidade, os trabalhos são executados em paralelo apenas se você tiver corredores suficientes para executar vários trabalhos ao mesmo tempo. O número de corredores hospedados no GitHub que você pode usar depende do tipo de conta do GitHub que você tem. Você pode comprar outro plano de conta do GitHub se precisar de mais trabalhos paralelos.

Às vezes, você deseja executar um trabalho quando um trabalho anterior falha. Por exemplo, aqui está um fluxo de trabalho diferente. Se a implantação falhar, um trabalho chamado reversão será executado imediatamente depois:

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

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 corre bem, o fluxo de trabalho executa primeiro o trabalho Test e, em seguida, o trabalho Deploy . Ele ignora o trabalho de reversão . No entanto, se o trabalho Testar ou Implantar falhar, o fluxo de trabalho executará o trabalho de Reversão . Você aprenderá mais sobre a reversão mais adiante neste módulo.

Trabalhos de implantação do Bíceps

Um fluxo de trabalho de implantação típico do Bicep contém vários trabalhos. À medida que o fluxo de trabalho se move através dos trabalhos, o objetivo é tornar-se cada vez mais confiante de que os trabalhos posteriores são bem-sucedidos. Aqui estão os trabalhos comuns para um fluxo de trabalho de implantação do Bicep:

1. Lint: Use o linter Bicep para verificar se o arquivo Bicep está bem formado e não contém erros óbvios.
2. Validar: use o processo de validação de comprovação do Azure Resource Manager para verificar se há problemas que possam ocorrer durante a implantação.
3. Pré-visualização: utilize o comando what-if para validar a lista de alterações que são aplicadas no seu ambiente do Azure. Peça a um humano para revisar manualmente os resultados hipotéticos e aprovar o fluxo de trabalho para continuar.
4. Implantar: envie sua implantação para o Gerenciador de Recursos e aguarde até que ela seja concluída.
5. Teste de fumaça: execute verificações básicas pós-implantação em relação a alguns dos recursos importantes que você implantou. Estas verificações são designadas por testes de fumo das infraestruturas.

Sua organização pode ter uma sequência diferente de trabalhos ou talvez seja necessário integrar suas implantações do Bicep em 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 de corredor que começa em um ambiente limpo. Assim, em todos os trabalhos, você normalmente precisa verificar o código-fonte como seu primeiro passo. Você também precisa entrar em seu 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 trabalho. Você também aprenderá:

• Como os fluxos de trabalho interrompem o processo de implantação se algo inesperado acontecer em qualquer um dos trabalhos anteriores.
• Como configurar seu fluxo de trabalho para pausar até verificar manualmente o que aconteceu em um trabalho anterior.