Rever e integrar alterações do Bicep
Você aprendeu como usar ramificações de funcionalidades e como aplicar proteção de ramificação para garantir que as alterações sejam revisadas antes de serem integradas. Agora, você precisa seguir um processo consistente para propor e revisar suas alterações antes que elas sejam mescladas.
Nesta unidade, você aprenderá mais sobre solicitações pull, incluindo como criá-las e usá-las. Você também aprenderá como usar pull requests para revisar o código Bicep.
Solicitações pull
Um pedido de pull é uma solicitação de si, o desenvolvedor de uma funcionalidade, para o mantenedor do ramo principal. Você pede ao mantenedor para puxar suas alterações para a ramificação principal do repositório.
Solicitações pull e proteções de ramificação
Ao configurar proteções de ramificação, você pode exigir que os proprietários do código analisem a solicitação pull. Por exemplo, pode incluir os líderes do projeto como revisores para todos os seus pedidos de pull, ou especificar que um determinado número de pessoas deve revisar cada pedido de pull.
Solicitações pull e políticas de ramificação
Ao configurar políticas de filial, você pode exigir que pessoas específicas ou um grupo de pessoas analisem a solicitação pull. Por exemplo, pode incluir os líderes do projeto como revisores para todos os seus pedidos de pull, ou especificar que um determinado número de pessoas deve revisar cada pedido de pull.
Você também pode exigir que cada solicitação pull esteja vinculada a um item de trabalho. Usando essa configuração, você pode rastrear desde um item de trabalho que contém uma solicitação de recurso até o código que implementa a alteração, até a implantação em seu ambiente de produção.
Criar um pull request
Você pode criar uma solicitação pull usando a interface da Web do GitHub. Você seleciona a ramificação de origem, onde fez as alterações, e a ramificação de destino, que geralmente é a ramificação principal do repositório.
Você pode criar uma solicitação pull usando a interface da Web do Azure DevOps. Você seleciona a ramificação de origem, onde fez as alterações, e a ramificação de destino, que geralmente é a ramificação principal do repositório.
Ao criar uma solicitação pull, você precisa dar um nome a ela. É uma boa prática tornar os nomes do seu pull request claros e compreensíveis. Essa prática ajuda os membros da sua equipe a entender o contexto do que estão sendo solicitados a revisar. Se eles tiverem diferentes áreas de especialização, um bom nome pode ajudá-los a encontrar solicitações pull onde possam contribuir com feedback significativo e ignorar as solicitações pull que não são relevantes.
Além disso, os nomes dos pull requests geralmente tornam-se parte do histórico do seu repositório Git, por isso é uma boa ideia torná-los compreensíveis para quem revisitar esse histórico.
Você também pode dar uma descrição aos pull requests. Você pode mencionar pessoas específicas ou fazer referência a problemas em suas descrições. Muitas equipes criam modelos padronizados para descrições de solicitação pull para que fique claro o que é cada alteração.
Você também pode dar uma descrição aos pull requests. Você pode mencionar pessoas específicas ou fazer referência a itens de trabalho em suas descrições. Muitas equipes criam modelos padronizados para descrições de solicitação pull para que fique claro o que é cada alteração.
Ao criar uma solicitação pull, você pode convidar pessoas para revisar as alterações.
Às vezes, você cria uma solicitação pull apenas para obter feedback de seus colegas. Nessas situações, você pode especificar que a solicitação pull é um rascunho . Os revisores saberão que você ainda está trabalhando nas alterações. Seus revisores ainda podem fornecer comentários, mas é claro que as alterações ainda não estão prontas para mesclagem. Quando estiver satisfeito com as alterações, pode remover o estado de rascunho.
Mesmo depois de criar um pull request, pode-se continuar a fazer alterações no código no seu ramo de funcionalidades. Essas alterações tornam-se parte do pull request.
Rever um pedido pull
Ao analisar uma solicitação pull, você pode ver todas as alterações. Você pode comentar toda a solicitação pull ou apenas partes específicas dos arquivos que foram alterados. O autor da solicitação pull pode responder aos comentários e outros revisores podem participar das discussões. Esses recursos de comentários tornam a colaboração em pull requests uma experiência interativa.
Ao analisar o código Bicep, procure estes elementos-chave:
- O arquivo pode ser implantado? Implante e teste o código Bicep antes que ele seja integrado. Certifique-se de que não há avisos do linter e que a implantação do Azure é bem-sucedida. Em um módulo futuro do Microsoft Learn, você aprenderá sobre abordagens para implantar e verificar automaticamente suas alterações.
- O código Bicep é claro e compreensível? É importante que a sua equipa toda compreenda o código Bicep. Ao revisar um arquivo Bicep em uma solicitação pull, certifique-se de entender exatamente para que serve cada alteração. As variáveis e parâmetros são bem nomeados? Os comentários foram usados para explicar alguma seção complexa do código?
- A alteração está completa? Se esta solicitação pull representar parte de um projeto mais amplo, certifique-se de que o seu ambiente funcionará quando essa alteração for integrada e implantada. Por exemplo, se a solicitação pull reconfigurar um recurso do Azure em preparação para uma alteração posterior, verifique se o recurso continua a funcionar corretamente durante todo o processo. Se a solicitação pull adicionar um novo recurso do Azure que ainda não é necessário, considere adicionar temporariamente uma condição para que o recurso não seja implantado até que se torne necessário.
- A mudança segue boas práticas do Bíceps? Noutros módulos do Microsoft Learn, aprendeste sobre os elementos de um bom código Bicep. Certifique-se de que o código revisado siga as mesmas práticas recomendadas.
- A alteração corresponde à descrição? É uma boa prática que os pull requests incluam um título descritivo. Muitas equipes também exigem que as solicitações pull incluam uma descrição da alteração e sua finalidade. Verifique se as alterações no seu código Bicep correspondem aos detalhes do pull request. Se o autor do pedido pull tiver vinculado a itens de trabalho ou problemas, verifique se as alterações no pedido pull atendem aos critérios de sucesso definidos pelo item de trabalho.
Concluir uma solicitação de pull
Depois que a solicitação pull for aprovada, ela poderá ser concluída. Isso significa que o conteúdo do pull request é mesclado na ramificação principal.
Em algumas equipes, o autor da solicitação pull também deve concluí-la. Esse processo ajuda a garantir que o autor controle quando a mesclagem acontece e possa estar disponível para monitorar quaisquer implantações automatizadas. Em outras equipes, os aprovadores concluem o pull request. Sua equipe deve decidir quem mescla solicitações pull e quando.
Em algumas equipes, o autor da solicitação pull também deve concluí-la. Esse processo ajuda a garantir que o autor controle quando a mesclagem acontece e possa estar disponível para monitorar quaisquer implantações automatizadas. Em outras equipes, os aprovadores concluem o pull request. Você pode até usar o Azure DevOps para concluir automaticamente uma solicitação pull quando ela atender aos critérios de aprovação. Sua equipe deve decidir quem mescla solicitações pull e quando.
O processo da sua equipa
Depois de começar a usar ramificações de funcionalidades e pull requests, o processo da sua equipa pode mudar para algo como o seguinte:
Um membro da equipe clona seu repositório compartilhado.
Eles fazem alterações locais em uma ramificação em sua própria cópia local do repositório.
Quando terminarem as alterações, enviarão a ramificação local para o repositório compartilhado.
Dentro do repositório compartilhado, eles criam uma solicitação pull para mesclar a ramificação para principal.
Outros membros da equipe analisam as alterações. Quando estiverem satisfeitos, aprovam o pedido de pull e ele é integrado na ramificação principal do repositório partilhado.
Eles excluem as ramificações no repositório compartilhado e em sua cópia local do repositório.
Em alguns cenários, o push do repositório remoto aciona um pipeline automatizado para verificar, testar e implantar o código. Você aprenderá mais sobre pipelines em outros módulos do Microsoft Learn.
O diagrama a seguir ilustra esse processo revisado.
