Entender a validação da solicitação de pull
Ao usar solicitações de pull, você pode garantir que outra pessoa examine todas as atualizações de suas implantações do Azure sejam revisadas por outra pessoa. Mas costuma se útil ter verificações automatizadas em suas alterações de código também. Nesta unidade, você aprenderá como pode usar a validação e as verificações de solicitação de pull automatizadas para aumentar a confiança da sua equipe em suas alterações de código.
Validação de solicitação de pull
Ao revisar uma solicitação de pull de código do Bicep, você pode estabelecer algumas etapas comuns para avaliar a alteração. Essas etapas podem incluir:
- Verificar se o arquivo Bicep tem erros ou avisos de linter.
- Garantir que todos os recursos previamente definidos no arquivo Bicep continuam a funcionar.
- Testar recursos recém-definidos para garantir que eles sejam implantados com êxito e que funcionem conforme o esperado.
A validação de solicitação de pull envolve a automatização de algumas dessas atividades. Ao automatizar verificações de solicitação de pull, os revisores podem gastar tempo em outras etapas mais importantes de revisão, como garantir que o código atenda aos padrões de qualidade da sua equipe e alcance a meta da empresa.
Em um fluxo de trabalho de GitHub Actions, você pode definir gatilhos que invocam o fluxo de trabalho em determinados pontos durante o processo de solicitação de pull, incluindo quando uma solicitação de pull é criada, atualizada, mesclada ou fechada.
Testar seu código do Bicep em um fluxo de trabalho de validação de solicitação de pull
Nos módulos anteriores, você aprendeu a criar fluxos de trabalho de GitHub Actions abrangentes para lint, validação, implantação e teste de alterações de infraestrutura do Azure, inclusive em vários ambientes. Esses fluxos de trabalho são executados depois que suas alterações são mescladas à ramificação principal.
Você também pode executar muitas das mesmas atividades em um fluxo de trabalho de validação de solicitação de pull. Por exemplo:
- Fazer o lint do código do Bicep ajuda a garantir que ele seja semanticamente correto e que siga algumas práticas recomendadas de linha de base do Bicep.
- A validação de simulação ajuda construir a confiança de que o código será implantado com êxito, sem realmente precisar implantar o arquivo. Dependendo do tipo de recurso, a validação de simulação pode procurar problemas como nomes de recursos inválidos, regiões inválidas de recursos específicos e se você especificou alguma configuração que não possa ser implantada com êxito.
- O teste de hipóteses, que lista as alterações que serão feitas no ambiente do Azure como resultado da implantação.
- Implantações, para realmente implantar seus recursos e garantir que não haja erros de implantação.
- Testar seus recursos após a implantação para garantir que eles estejam configurados de acordo com seus requisitos de negócios.
Um fluxo de trabalho de validação de solicitação de pull é um fluxo de trabalho normal do GitHub Actions, portanto, ele pode executar qualquer uma dessas tarefas. No entanto, vale a pena pensar nos tipos de verificações que fazem sentido executar em uma solicitação de pull. Muitas das atividades de validação listadas aqui exigem acesso a um ambiente do Azure. Por exemplo, a operação de teste de hipóteses compara os recursos definidos em seus arquivos Bicep com os recursos em sua assinatura do Azure. Faz sentido executar essa comparação em relação a um ambiente de produção, mas como isso introduz algum risco adicional, você pode não se sentir confortável executando operações em um ambiente de produção de um fluxo de trabalho projetado para código que ainda não foi concluído ou mesclado.
Neste módulo, você adicionará dois tipos de verificações ao fluxo de trabalho de validação de solicitação de pull:
- Adicionar lint ao seu código Bicep para executar um conjunto inicial de verificações nele.
- Implantar o código em um ambiente novo e temporário.
Essas duas atividades não exigem a conexão com seu ambiente do Azure de produção, nem mesmo com qualquer um dos ambientes regulares de não produção, como teste, garantia de qualidade ou processo de preparo. Ao executar essas duas atividades, você ainda consegue estabelecer uma boa quantidade de confiança em suas alterações de código para que possa mesclá-las na ramificação principal do repositório.
As verificações são úteis para seus revisores, pois economizam tempo que, de outra forma, seriam gastos executando as atividades manualmente. Elas também são úteis para você, autor da solicitação de pull, pois você pode usá-las para obter uma visão inicial de como as alterações funcionarão posteriormente no processo de implantação.
Em seus próprios fluxos de trabalho de validação de solicitação de pull, você pode optar por estender as verificações de validação com outras atividades.
Gatilhos de ciclo de vida da solicitação de pull
Uma solicitação de pull no GitHub pode passar por vários eventos de ciclo de vida diferentes. Por exemplo, uma solicitação de pull é aberta. Em seguida, o autor pode fazer push de alterações para o branch de origem (sincronizar), o que afeta o conteúdo da solicitação de pull. Em seguida, a solicitação de pull pode ser mesclada, fechada sem ser mesclada e até mesmo reaberta no futuro.
Com o GitHub Actions, você pode definir gatilhos de fluxo de trabalho que respondem a qualquer um desses eventos. Por exemplo, você pode definir um fluxo de trabalho que será executado automaticamente sempre que uma solicitação de pull for aberta, sincronizada ou reaberta especificando o gatilho pull_request sem nenhuma configuração adicional:
on: pull_request
Você também pode especificar eventos de solicitação de pull que disparam um fluxo de trabalho. Por exemplo, o fluxo de trabalho a seguir é executado automaticamente sempre que uma solicitação de pull é fechada:
on:
pull_request:
types: [closed]
Importante
Se houver conflitos de mesclagem em uma solicitação de pull, o fluxo de trabalho não será executado. Você precisa resolver o conflito e efetuar push da resolução para que o fluxo de trabalho possa ser executado.
Verificações de status da solicitação de pull
Os resultados de um fluxo de trabalho de solicitação de pull são mostrados na página de detalhes da solicitação de pull como verificações. As verificações permitem que autores e revisores recebam comentários rapidamente informando se as atividades automatizadas foram bem-sucedidas ou falharam, como mostrado no seguinte exemplo:
Por padrão, mesmo se uma verificação falhar, a solicitação de pull poderá ser mesclada. Talvez você não queira permitir isso, portanto, você pode configurar regras de proteção de branch para impor que verificações específicas devam ser bem-sucedidas para que uma solicitação de pull possa ser mesclada.
Atualizando arquivos
Depois que uma solicitação de pull é criada, é comum que um autor precise fazer atualizações. Por exemplo:
- Um revisor pode solicitar que o autor faça alterações no código.
- Se uma verificação automatizada falhar, o autor poderá alterar o código para corrigir o problema e, em seguida, fazer commit e efetuar push das alterações.
Usando o gatilho pull_request, você pode configurar o fluxo de trabalho de validação para ser executado sempre que o branch de origem for atualizado. Os resultados da última execução do fluxo de trabalho são mostrados na página de detalhes da solicitação de pull.
Fluxos de trabalho reutilizáveis
Se você examinar a lista de possíveis verificações para a validação de solicitação de pull, observará que essas são as mesmas etapas que você executaria em um fluxo de trabalho de implantação regular. Para evitar a repetição, a boa prática é usar os fluxos de trabalho reutilizáveis do GitHub.
Você pode definir fluxos de trabalho reutilizáveis para cada um dos trabalhos que usará nas várias definições de fluxo de trabalho. Você verá como fazer isso no próximo exercício.
Solicitação de pull de rascunho
Como autor, você normalmente abriria uma solicitação de pull quando estivesse pronto para que suas alterações fossem examinadas, aprovadas e mescladas. Mas pode ser útil obter acesso às verificações de validação de solicitação de pull automatizadas durante todo o processo de escrita do código, mesmo que você não esteja pronto para mesclar as alterações.
Ao abrir uma solicitação de pull no GitHub, você pode marcá-la como um rascunho. O GitHub executa todas as mesmas verificações automatizadas, e os revisores ainda podem fornecer comentários. No entanto, quando sua solicitação de pull está no status do rascunho, fica claro para todos que o trabalho ainda não está pronto para uma revisão completa e não pode ser mesclado.
É especialmente comum criar solicitações de pull de rascunho quando seu fluxo de trabalho de validação de solicitação de pull cria ambientes efêmeros, pois você pode visualizar suas alterações em um ambiente de trabalho em tempo real. À medida que você continua a efetuar push de alterações, seu ambiente efêmero é atualizado para incorporar as alterações mais recentes.