Projetar a canalização

Concluído

Nesta unidade, acompanhas a equipa da web da Tailspin enquanto a equipa define o seu pipeline de lançamento para o site Space Game.

Quando você planeja um pipeline de liberação, geralmente começa identificando os estágios, ou divisões principais, desse pipeline. Cada estágio normalmente é mapeado para um ambiente. Por exemplo, no módulo anterior, o pipeline básico de Andy e Mara tinha um estágio de Implantação mapeado para uma instância do Serviço de Aplicativo do Azure.

Neste módulo, você promover mudanças de um estágio para o outro. Dentro de cada estágio, você implantar site do Space Game no ambiente associado a esse estágio.

Depois de definir quais estágios você precisa, considere como as mudanças são promovidas de um estágio para o próximo. Cada estágio pode definir os critérios de sucesso que devem ser atendidos antes que a construção possa passar para o próximo estágio. O Azure Pipelines fornece várias maneiras de ajudá-lo a controlar como e quando as alterações passam pelo pipeline. Como um todo, essas abordagens são usadas para gerenciamento de versões.

Nesta secção, você:

• Saiba as diferenças entre os estágios comuns do pipeline, como Build, Dev, Teste Staging.
• Entenda como usar gatilhos de implantação manuais, programados e contínuos para controlar quando um artefato passa para o próximo estágio no pipeline.
• Veja como uma aprovação de lançamento pausa o pipeline até que um aprovador aceite ou rejeite a versão.

A reunião

Toda a equipe web da Tailspin está reunida. Em Criar um pipeline de lançamento com o Azure Pipelines, a equipe planejou suas tarefas para o sprint atual. Cada tarefa está relacionada à construção de seu pipeline de lançamento para o site Space Game.

Lembre-se que a equipa decidiu estas cinco tarefas para o seu sprint:

• Crie um pipeline de vários estágios.
• Conecte o aplicativo Web a um banco de dados.
• Automatize testes de qualidade.
• Automatize testes de desempenho.
• Melhore a cadência de lançamento.

A equipe se reúne para falar sobre a primeira tarefa, Criar um pipeline de vários estágios. Após a equipa definir o pipeline, ela pode avançar da sua prova de conceito básica para um pipeline de lançamento que inclui mais estágios, verificações de qualidade e aprovações.

Amita e Tim estão a assistir a Andy e Mara demonstrarem o pipeline de lançamento uma segunda vez. Eles veem que o artefato foi criado e instalado no App Service.

Quais estágios de pipeline você precisa?

Quando você deseja implementar um pipeline de liberação, é importante primeiro identificar quais estágios você precisa. As etapas que você escolhe dependem de suas necessidades. Vamos acompanhar a equipe enquanto eles decidem suas etapas.

Tim: OK, eu entendo a ideia de um pipeline automatizado. Gosto de como é fácil implantar no Azure. Mas para onde vamos a partir desta demonstração? Precisamos de algo que possamos realmente usar para nossos lançamentos.

Amita: Certo! Precisamos acrescentar outras etapas. Por exemplo, neste momento, não temos lugar para uma fase de testes.

Tim: Além disso, precisamos de um palco onde possamos mostrar novas funcionalidades à gestão. Não posso enviar nada para a produção sem a aprovação da gerência.

Andy: Com certeza! Agora que está atualizado sobre o que um pipeline de liberação faz, como podemos fazer com que esse pipeline faça o que precisamos?

Mara: Vamos esboçar nossos requisitos para nos ajudar a planejar nossos próximos passos. Comecemos pelo que temos.

Mara dirige-se ao quadro branco e esboça o pipeline existente.

Mara: O Build estágio constrói o código-fonte e produz um pacote. No nosso caso, esse pacote é um arquivo .zip. O estágio Deploy instala o arquivo .zip, que é o site Space Game, numa instância do App Service. O que está faltando em nosso pipeline de lançamento?

Adicionar o estágio de desenvolvimento

Andy: Posso ser tendencioso, mas acho que precisamos de uma fase Dev. Esta etapa deve ser a primeira parada para o artefato depois de construído. Os desenvolvedores nem sempre podem executar todo o serviço a partir de seu ambiente de desenvolvimento local. Por exemplo, um sistema de comércio eletrônico pode exigir um site, banco de dados de produtos e sistema de pagamento. Precisamos de um palco que inclua tudo o que o aplicativo precisa.

No nosso caso, o recurso de tabela de classificação do site Space Game lê pontuações altas de uma fonte externa. Neste momento, lê partituras fictícias de um ficheiro. Configurar um estágio de desenvolvimento nos daria um ambiente onde podemos integrar o aplicativo web com um banco de dados real. Esse banco de dados ainda pode conter pontuações fictícias, mas nos deixa um passo mais perto do nosso aplicativo final.

Mara: eu gosto. Ainda não nos integraremos com uma base de dados real. Mas numa fase Dev, podemos desdobrar num ambiente onde seja possível adicionar uma base de dados.

Mara atualiza seu desenho no quadro branco. Ela substitui "Deploy" por "Dev" para mostrar o Dev palco.

Andy: Você traz um ponto interessante. Criamos o aplicativo cada vez que enviamos uma alteração para o GitHub. Isso significa que cada compilação é promovida para o estágio Dev após a sua conclusão?

Mara: Building continuamente nos dá feedback importante sobre nossa saúde de construção e teste. Mas queremos promover para o Dev estágio apenas quando fundimos o código em algum ramo central: principal ou algum outro ramo de lançamento. Vou atualizar o desenho para mostrar esse requisito.

Mara: acho que essa promoção será fácil de realizar. Podemos definir uma condição que promove para o estágio Dev somente quando as alterações acontecem em uma ramificação de lançamento.

O que são condições?

No Azure Pipelines, usar uma condição para executar tarefa ou trabalho com base no estado do pipeline. Você trabalhou com condições em módulos anteriores.

Lembre-se, algumas das condições que você pode especificar são:

• Apenas quando todas as tarefas dependentes anteriores tiverem sido bem-sucedidas.
• Mesmo que uma dependência anterior tenha falhado, a menos que a execução tenha sido cancelada.
• Mesmo que uma dependência anterior tenha falhado, mesmo que a execução tenha sido cancelada.
• Apenas quando uma dependência anterior falhou.
• Uma condição personalizada.

Aqui está um exemplo básico:

steps:
  - script: echo Hello!
    condition: always()

A condição always() faz com que esta tarefa imprima "Olá!" incondicionalmente, mesmo que as tarefas anteriores tenham falhado.

Esta condição é usada se você não especificar uma condição:

condition: succeeded()

A função interna succeeded() verifica se a tarefa anterior foi bem-sucedida. Se a tarefa anterior falhar, esta tarefa e as tarefas posteriores que usam a mesma condição serão ignoradas.

Aqui você deseja criar uma condição que especifique:

• A tarefa anterior foi bem sucedida.
• O nome da ramificação atual do Git é versão.

Para criar essa condição, use a função and() incorporada. Esta função verifica se cada uma das suas condições é verdadeira. Se alguma condição não for verdadeira, a condição geral falhará.

Para obter o nome da ramificação atual, use a variável interna Build.SourceBranchName. Você pode acessar variáveis dentro de uma condição de algumas maneiras. Aqui você usa a sintaxe variables[].

Para testar o valor de uma variável, você pode usar a função eq() interna. Esta função verifica se seus argumentos são iguais.

Com isso em mente, aplica esta condição para executar a etapa de desenvolvimento na fase apenas quando o nome da ramificação atual for "release":

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

A primeira condição na função and() verifica se a tarefa anterior foi bem-sucedida. A segunda condição verifica se o nome da ramificação atual é igual a release.

Em YAML, você usa a sintaxe pipe (|) para definir uma cadeia de caracteres que abrange várias linhas. Você pode definir a condição em uma única linha, mas nós a escrevemos dessa maneira para torná-la mais legível.

Observação

Neste módulo, usamos o release branch como exemplo. Você pode combinar condições para definir o comportamento de que precisa. Por exemplo, você pode criar uma condição que executa o estágio somente quando a compilação é acionada por uma solicitação pull na ramificação principal .

Na unidade seguinte, ao configurares o estágio Dev, trabalhas com um exemplo mais completo.

Para obter uma descrição mais completa das condições no Azure Pipelines, consulte documentação de expressões.

Mara: Usando condições, você pode controlar quais mudanças são promovidas para quais estágios. Podemos produzir um artefacto de build para qualquer alteração, para validar a nossa build e confirmar que ela está em bom estado. Quando estivermos prontos, podemos integrar essas alterações num ramo de lançamento e promover essa versão para a fase Dev.

Adicionar o estágio de teste

Mara: Até agora, temos os estágios Build e Dev. O que vem a seguir?

Amita: Podemos adicionar o Test etapa a seguir? Esse parece ser o lugar certo para eu testar as últimas mudanças.

Mara acrescenta a etapa de teste ao seu desenho no quadro branco.

Amita: Uma preocupação que tenho é a frequência com que preciso testar o aplicativo. Um e-mail me notifica sempre que Mara ou Andy faz uma alteração. As mudanças acontecem ao longo do dia, e eu nunca sei quando entrar. Acho que gostaria de ver uma construção uma vez por dia, talvez quando chegar ao escritório. Podemos fazê-lo?

Andy: claro. Por que não implantamos em Teste fora do horário de trabalho? Digamos que lhe enviamos uma compilação todos os dias às 3h da manhã.

Mara: Isso soa bem. Podemos sempre acionar manualmente o processo também, se necessário. Por exemplo, podemos acioná-lo se precisarmos que você verifique uma correção de bug importante imediatamente.

Mara atualiza seu desenho para mostrar que a construção passa do estágio Dev para o estágio Test às 3 da manhã todas as manhãs.

O que são gatilhos?

Amita: estou me sentindo melhor agora que sabemos como uma etapa se move para outra. Mas como controlar quando uma etapa é executada?

Mara: Nos Azure Pipelines, podemos usar gatilhos. Um gatilho de define quando um estágio é executado. O Azure Pipelines fornece alguns tipos de gatilhos. Aqui estão as nossas escolhas:

• Gatilho de integração contínua (CI)
• Gatilho de solicitação pull (PR)
• Gatilho programado
• Gatilho de conclusão da compilação

Os gatilhos de CI e RP permitem controlar quais filiais participam do processo geral. Por exemplo, você deseja criar o projeto quando uma alteração é feita em qualquer ramificação. Um gatilho agendado inicia uma implantação em um momento específico. Um gatilho de conclusão de compilação executa uma compilação quando outra compilação, como uma para um componente dependente, é concluída com êxito. Parece que queremos um gatilho programado.

O que são gatilhos agendados?

Um gatilho programado utiliza a sintaxe cron para executar uma compilação numa agenda definida.

Em sistemas Unix e Linux, cron é uma maneira popular de agendar trabalhos para serem executados em um intervalo de tempo definido ou em um horário específico. No Azure Pipelines, os gatilhos agendados usam a sintaxe cron para definir quando um estágio é executado.

Uma expressão cron inclui campos que correspondem a determinados parâmetros de tempo. Aqui estão os campos:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

Por exemplo, esta expressão cron descreve "3 A.M. todos os dias": 0 3 * * *

Uma expressão cron pode incluir caracteres especiais para especificar uma lista de valores ou um intervalo de valores. Neste exemplo, o asterisco (*) corresponde a todos os valores dos campos Dias, Mesese Dias da semana.

Dito de outra forma, esta expressão cron lê-se como:

• Ao minuto 0,
• À terceira hora,
• Em qualquer dia do mês,
• Em qualquer mês,
• Em qualquer dia da semana,
• Executar a tarefa

Para especificar 3 da manhã apenas nos dias de segunda a sexta-feira, você usaria esta expressão: 0 3 * * 1-5

Observação

O fuso horário para horários cron é Tempo Universal Coordenado (UTC), portanto, neste exemplo, 3 A.M. refere-se a 3 A.M. em UTC. Na prática, você pode querer ajustar o tempo em sua programação cron em relação ao UTC para que o pipeline seja executado no horário esperado para você e sua equipe.

Para configurar um gatilho agendado no Azure Pipelines, você precisa de uma seção schedules em seu arquivo YAML. Aqui está um exemplo:

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

Na seção schedules:

• cron especifica a expressão cron.
• branches indica para desplegar somente a partir da ramificação release.
• always especifica se a implantação deve ser executada incondicionalmente (true) ou somente quando a ramificação release tiver sido alterada desde a última execução (false). Aqui, você especifica false porque precisa implantar somente quando a ramificação release tiver sido alterada desde a última execução.

Todo o pipeline é executado quando o Azure Pipelines aciona um disparador programado. O pipeline também é executado sob outras condições, como quando você envia uma alteração para o GitHub. Para executar um estágio somente em resposta a um gatilho agendado, você pode usar uma condição que verifica se o motivo da compilação é uma execução agendada.

Aqui está um exemplo:

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

Este estágio, Test, é executado somente quando o estágio anterior é bem-sucedido e a variável interna de pipeline Build.Reason é igual a Schedule.

Você verá um exemplo mais completo mais adiante neste módulo.

Amita: eu gosto disso. Eu nem preciso pegar a versão manualmente e instalá-la. Está pronto para mim.

Andy: E não se esqueça de que, se quisermos automatizar mais tarde, podemos. Nada está escrito em pedra. O processo evolui à medida que melhoramos e aprendemos.

Adicionar o estágio de preparo

Tim: É a minha vez. Preciso de um estágio para executar mais testes de stress. Também precisamos de uma etapa em que possamos demonstrar à gerência para obter sua aprovação. Por enquanto, podemos combinar essas duas necessidades numa fase que podemos chamar de Preparação.

Andy: Bem disse, Tim. Ter um ambiente de estágio ou um ambiente de pré-produçãoé importante. Esse ambiente de preparação geralmente é a última parada antes que um recurso ou correção de bug chegue aos nossos usuários.

Mara acrescenta Encenação ao seu desenho no quadro branco.

Amita: Usamos um gatilho programado para promover mudanças do estágio Dev para o estágio Test. Mas como promover mudanças de Teste para Staging? Essa promoção também tem que acontecer dentro de um cronograma?

Mara: acho que a melhor maneira de lidar com isso seria uma aprovação de lançamento . Uma aprovação de liberação permite que você promova manualmente uma alteração de um estágio para o seguinte.

Amita: Parece exatamente o que eu preciso! Uma aprovação de lançamento me daria tempo para testar as mudanças mais recentes antes de apresentarmos a compilação ao gerenciamento. Posso promover a compilação quando estiver pronto.

Mara atualiza o seu desenho para mostrar que a versão passa de Teste para Pré-produção apenas quando a Amita aprova.

Tim: Também consigo imaginar-nos a usar aprovações de lançamento para promover do ambiente de teste para o ambiente de produção após a aprovação da gerência. Nunca posso prever quanto tempo isso demora. Depois de eles assinarem, posso aprovar o lançamento e promovê-lo à produção manualmente. Mas como funcionam as aprovações de liberação?

O que são aprovações de lançamento?

Uma aprovação de lançamento é uma maneira de pausar o pipeline até que um aprovador aceite ou rejeite a versão. Para definir seu fluxo de trabalho de liberação, você pode combinar aprovações, condições e gatilhos.

Lembre-se de que, em Criar um pipeline de liberação com o Azure Pipelines, você definiu um ambiente em sua configuração de pipeline para representar seu ambiente de implantação. Aqui está um exemplo da sua linha de produção existente:

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

Seu ambiente pode incluir critérios específicos para sua liberação. Os critérios podem especificar quais pipelines podem ser implantados nesse ambiente e quais aprovações humanas são necessárias para promover a liberação de um estágio para o outro.

Mais adiante neste módulo, você define o de preparação ambiente e atribui-se como aprovador para promover o aplicativo Web Space Game do estágio de de teste de para de preparação.

Automatize o mínimo ou o quanto precisar

O Azure Pipelines oferece a flexibilidade de automatizar alguns estágios enquanto controla manualmente os estágios que não estão prontos para automação.

Tim: gosto de como podemos definir os critérios que promovem mudanças de uma etapa para outra. Mas definimos alguns critérios manuais em nosso pipeline. Eu pensei que DevOps era sobre automatizar tudo.

Mara: Você levanta um bom ponto. DevOps é realmente sobre automatizar tarefas repetitivas e propensas a erros. Por vezes, é necessária a intervenção humana. Por exemplo, obtemos aprovação da gestão antes de lançar novos recursos. À medida que adquirimos mais experiência com nossas implantações automatizadas, podemos automatizar mais de nossas etapas manuais para acelerar o processo. Por exemplo, podemos automatizar mais verificações de qualidade na etapa de teste , para que Amita não precise aprovar cada compilação.

Tim: Parece ótimo. Vamos seguir com este plano por enquanto e ver como podemos acelerar o sistema mais tarde.

Amita: Falando do nosso plano, podemos resumir os nossos próximos passos?

O plano

Vamos rever o plano da equipe Tailspin à medida que avançam para as próximas etapas.

Mara: Aqui está o processo de lançamento que queremos desenvolver.

Mara aponta para o quadro branco.

Mara: Para resumir, nossos passos são:

1. Gere um artefato de build sempre que enviarmos uma alteração para o GitHub. Esta etapa acontece no estágio Build.
2. Promova o artefato de build para o estágio de desenvolvimento. Esta etapa acontece automaticamente quando o estágio de compilação é bem-sucedido e a alteração está na ramificação de versão.
3. Promova o artefacto de build para o estágio de teste todas as manhãs às 3h. Usamos um gatilho agendado para promover automaticamente o artefacto de build.
4. Promova o artefacto de construção para Preparação após o teste e a aprovação da compilação por Amita. Usamos uma aprovação de lançamento para promover o artefacto de build.

Depois que o gerenciamento aprovar a compilação, podemos implantar o artefato de compilação em um ambiente de produção.

Amita: Isso vai ser difícil de fazer? Parece muito trabalho.

Mara: não acho muito ruim. Cada etapa é separada de todas as outras. As etapas são distintas. Cada etapa tem o seu próprio conjunto de tarefas. Por exemplo, o que acontece no estágio de de teste de permanece no estágio de de teste de.

Cada estágio de implantação em nosso pipeline também tem seu próprio ambiente. Por exemplo, quando implantamos o aplicativo em de Desenvolvimento ou de Teste, o ambiente é uma instância do Serviço de Aplicativo.

Finalmente, testamos apenas uma versão de cada vez. Nunca mudamos lançamentos no meio do pipeline. Usamos a mesma versão no estágio Dev como no estágio Staging, e cada lançamento tem seu próprio número de versão. Se a versão falhar em um dos estágios, corrigimos e construímos novamente com uma nova numeração de versão. Essa nova versão, então, passa pelo processo desde o início.

Algumas palavras sobre qualidade

Você acabou de ver a equipe projetar um pipeline que leva seu aplicativo desde a compilação até a preparação. O objetivo deste pipeline não é apenas tornar suas vidas mais fáceis. É para garantir a qualidade do software que eles estão entregando aos seus clientes.

Como você mede a qualidade do seu processo de liberação? A qualidade do seu processo de liberação não pode ser medida diretamente. O que você pode medir é o quão bem o seu processo funciona. Se você está constantemente mudando o processo, pode ser um indício de que há algo errado. As versões que falham consistentemente em um ponto específico do pipeline também podem indicar que há um problema com o processo de liberação.

Os lançamentos sempre falham em um determinado dia ou horário? Eles sempre falham depois que você implanta em um ambiente específico? Procure esses e outros padrões para ver se alguns aspetos do processo de liberação são dependentes ou relacionados.

Uma boa maneira de acompanhar a qualidade do seu processo de lançamento é criar visualizações da qualidade dos lançamentos. Por exemplo, adicione um widget de painel que mostre o status de cada versão.

Quando você deseja medir a qualidade de uma liberação em si, você pode executar todos os tipos de verificações dentro do pipeline. Por exemplo, você pode executar diferentes tipos de testes, como testes de carga e testes de interface do usuário durante a execução do pipeline.

Usar um portão de qualidade também é uma ótima maneira de verificar a qualidade do seu lançamento. Existem muitos portões de qualidade diferentes. Por exemplo, portões de item de trabalho podem verificar a qualidade do seu processo de requisitos. Você também pode adicionar mais verificações de segurança e conformidade. Por exemplo, cumpre o princípio dos quatro olhos ou tem a rastreabilidade adequada?

À medida que você progride nesse caminho de aprendizagem, você vê muitas dessas técnicas colocadas em prática.

Por fim, ao projetar um processo de liberação de qualidade, pense em que tipo de documentação ou notas de versão você precisa fornecer ao usuário. Manter a documentação atualizada pode ser difícil. Talvez você queira considerar o uso de uma ferramenta, como o Azure DevOps Release Notes Generator. O gerador é um aplicativo de função que contém uma função acionada por HTTP. Usando o Armazenamento de Blobs do Azure, ele cria um arquivo Markdown sempre que uma nova versão é criada no Azure DevOps.

Verifique os seus conhecimentos

1.

O seu processo inclui muitos testes e verificações de controlo de qualidade que levam vários minutos para serem concluídos. Que tipo de gatilho é melhor para executar testes apenas em código que foi revisado por pares?

Um gatilho de conclusão de compilação

Um gatilho de IC ou um gatilho de RP

Um gatilho programado

2.

Qual é a melhor maneira de pausar o pipeline até que um aprovador aprove uma alteração?

Use uma aprovação de liberação.

Instale uma extensão do Marketplace que disponibilize tarefas do Azure Pipelines capazes de pausar o pipeline.

Peça ao seu aprovador para ver a alteração. Em seguida, acione manualmente o pipeline para ser executado.

3.

Você deseja implantar seu aplicativo Web no ambiente Test sempre que uma compilação for concluída. Qual é a maneira mais fácil de configurar o processo?

Use um gatilho agendado.

Fique atento aos e-mails de notificação de compilação e acione manualmente sua compilação quando a outra for concluída com êxito.

Use um gatilho de conclusão de compilação.

Tem de responder a todas as questões antes de verificar o seu trabalho.