Entender as fases do pipeline

Concluído

Os pipelines permitem automatizar as etapas em 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 estágios de pipeline e como usá-los para adicionar processos de controle de qualidade às implantações do Bicep.

O que são fases do pipeline?

As fases ajudam você a dividir o pipeline em vários blocos lógicos. Cada fase pode conter um ou mais trabalhos. Os trabalhos contêm uma lista ordenada de etapas que devem ser concluídas, como a execução de scripts de linha de comando.

Você pode usar estágios no pipeline para marcar uma separação de responsabilidades. Por exemplo, ao trabalhar com código Bicep, a validação do código é uma responsabilidade separada da implantação do arquivo Bicep. Quando você usa um pipeline automatizado, em geral, a criação e o teste do código são conhecidos como CI (integração contínua). A implantação de código em um pipeline automatizado geralmente é chamada de CD (implantação contínua).

Durante os estágios de CI, você verifica a validade das alterações que foram feitas em seu código. As fases de CI fornecem garantia de qualidade. Você pode executá-los sem afetar seu 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 transcompilado de Bicep para JSON. As ferramentas executam esse processo automaticamente. Na maioria das situações, não é necessário compilar manualmente o código Bicep em modelos JSON no pipeline. 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 os estágios de CI forem executados com êxito, você terá mais confiança de que as alterações que você fez também sejam implantadas com sucesso. Durante as etapas de CD, você implanta o código em cada um dos ambientes. Você geralmente começa com o teste e outros ambientes de não produção e, em seguida, continua para ambientes de produção. Neste módulo, você implantará em um único ambiente. Em um módulo futuro, você aprenderá a estender o pipeline de implantação para implantar em vários ambientes, como ambientes não produtivos e produtivos.

As fases são executadas em uma sequência. Você pode controlar como e quando cada fase é executada. Por exemplo, você pode configurar suas fases de CD para serem executadas somente depois que as fases de CI sejam concluídas com sucesso. Ou você pode ter vários estágios de CI que precisam ser executados em sequência, por exemplo, para criar seu código e testá-lo. Você também pode incluir um estágio de reversão executado somente se os estágios de implantação anteriores falharem.

Migração left-shift

Usando fases, você pode verificar a qualidade do código antes de implantá-lo. O uso desses estágios às vezes é chamado de shift left.

Considere uma linha do tempo das atividades que você executa ao escrever o código. A linha do tempo começa com as fases de planejamento e design. Em seguida, ela passa para as fases de criação e de teste. Por fim, você implanta e dá suporte à sua solução. O diagrama a seguir mostra esses estágios em uma linha do tempo.

É uma regra bem compreendida no desenvolvimento de software que, no início do processo, você encontra um erro (quanto mais próximo do lado esquerdo da linha do tempo), mais fácil, mais rápido e mais barato é corrigir. Quanto mais tarde no processo você detectar um erro, mais difícil será corrigi-lo.

Portanto, o objetivo é deslocar a descoberta de problemas para o lado esquerdo do diagrama. Neste módulo, você verá como adicionar mais etapas de validação e testes ao seu pipeline à medida que ele progride.

Você pode até mesmo adicionar validações bem antes do início da implantação. Quando você trabalha com ferramentas como o Azure DevOps, as solicitações de pull normalmente representam as alterações que alguém da sua equipe deseja fazer no código na ramificação principal. É útil criar outro pipeline que executa 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 ser feito antes que a solicitação de pull esteja pronta para mesclar.

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 uma fase de pipeline

Cada pipeline contém, pelo menos, uma fase. Se o pipeline tiver apenas um estágio, você não precisará defini-lo explicitamente. O Azure Pipelines o define automaticamente para você. Quando você tiver várias fases em um pipeline, precisará definir cada uma delas. As fases são executadas em uma sequência especificada por você.

Imagine que você criou um arquivo Bicep que precisa ser implantado duas vezes: uma na infraestrutura dos Estados Unidos e outra na infraestrutura da Europa. Antes de implantar o arquivo, valide o código Bicep. Esta é uma ilustração de um pipeline de várias fases que define esse processo:

Observe que este exemplo tem três fases. A fase Validar é semelhante a uma fase de CI. Os estágios DeployUS e DeployEurope são executados em seguida. Cada um implanta o código em um dos ambientes.

Veja como as fases são definidas em um arquivo YAML de pipeline:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

Controlar a sequência de fases

Por padrão, as fases são executadas na ordem que você define. Um estágio é executado somente se o estágio anterior for bem-sucedido. Você pode adicionar dependências entre as fases para alterar a ordem.

Continuando o exemplo acima, imagine que você deseja executar as duas implantações em paralelo, desta forma:

Você pode especificar as dependências entre as fases usando a palavra-chave dependsOn:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

Quando você usa a palavra-chave dependsOn, o Azure Pipelines espera que a fase dependente seja concluída com êxito antes de iniciar a próxima. Se o Azure Pipelines detectar que todas as dependências de vários estágios estão satisfeitas, ele poderá executar esses estágios em paralelo.

Observação

Na realidade, as fases e os trabalhos só serão executados em paralelo se você tiver agentes suficientes para executar vários trabalhos ao mesmo tempo. Ao usar agentes hospedados pela Microsoft, talvez seja necessário comprar trabalhos paralelos adicionais para conseguir isso.

Talvez você queira executar um estágio quando o estágio anterior falhar. Por exemplo, veja este outro pipeline. Se a implantação falhar, uma fase chamada Reversão será executada imediatamente depois:

Você pode usar a palavra-chave condition para especificar uma condição que deve ser atendida antes que uma fase seja executada:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

No exemplo anterior, quando tudo corre bem, o Azure Pipelines executa a fase Validar primeiro e, depois, a fase Implantar. Ele ignora a fase Reversão. No entanto, se a fase Implantar falha, o Azure Pipelines executa a fase Reversão. Você verá mais sobre a reversão posteriormente neste módulo.

Cada trabalho é executado em um novo agente. Isso significa que cada trabalho começa em um ambiente limpo. Portanto, em cada trabalho, normalmente, é necessário conferir o código-fonte como primeira etapa.

Fases de implantação do Bicep

Um pipeline de implantação típico do Bicep contém várias fases. À medida que o pipeline passa pelas fases, a meta é ficar cada vez mais confiante de que as fases posteriores serão bem-sucedidas. Estas são as fases comuns de um pipeline de implantação do Bicep:

1. Lint: use o linter do Bicep para verificar se o arquivo Bicep tem o formato correto e não contém erros óbvios.
2. Validar: use o processo de validação de pré-vôo do Azure Resource Manager para verificar se há problemas que podem ocorrer durante a implantação.
3. Versão prévia: use o comando what-if para validar uma lista de alterações que serão aplicadas em seu ambiente do Azure. Solicite que uma pessoa revise manualmente os resultados do teste de hipóteses e aprove o pipeline antes de prosseguir.
4. Implantar: envie a implantação ao Resource Manager e aguarde até que ela seja concluída.
5. Smoke Test: Execute verificações básicas pós-implantação em alguns dos recursos importantes que você implantou. Essas revisões são chamadas smoke tests de infraestrutura.

Sua organização pode ter uma sequência diferente de fases ou talvez seja necessário integrar suas implantações do Bicep em um pipeline que implanta outros componentes. Depois de entender como as fases funcionam, você pode criar um pipeline de acordo com suas necessidades.

Neste módulo, você saberá mais sobre essas fases e criará progressivamente um pipeline que inclui cada uma delas. Você também aprenderá os seguintes tópicos:

• De que forma os pipelines interrompem o processo de implantação se algo inesperado acontecer durante qualquer um dos estágios anteriores.
• Como configurar seu pipeline para pausar até que você verifique manualmente o que aconteceu em uma fase anterior.