Revisar e mesclar alterações do Bíceps
Você aprendeu como usar ramificações de recursos e como aplicar proteção de ramificação para garantir que as alterações sejam revisadas antes de serem mescladas. 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 solicitações pull para revisar o código Bicep.
Pedidos Pull
Uma solicitação pull é uma solicitação sua, desenvolvedora de um recurso, para o mantenedor da ramificação 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, você pode incluir os leads do projeto como revisores para todas as suas solicitações pull ou pode especificar que um determinado número de pessoas deve revisar cada solicitação 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, você pode incluir os leads do projeto como revisores para todas as suas solicitações pull ou pode especificar que um determinado número de pessoas deve revisar cada solicitação 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 pedido Pull
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 de solicitação pull geralmente se tornam parte do histórico do seu repositório Git, por isso é uma boa ideia torná-los compreensíveis quando alguém olhar para trás no 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 uma solicitação pull, você pode continuar fazendo alterações no código em sua ramificação de recurso. Essas alterações tornam-se parte da solicitação pull.
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 solicitações pull 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 mesclado. Certifique-se de que não há avisos linter e que a implantação do Azure seja 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 todos na sua equipa compreendam o seu 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 essa solicitação pull representar parte de uma parte mais ampla do trabalho, certifique-se de que seu ambiente funcionará quando essa alteração for mesclada 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 se uma condição deve ser adicionada temporariamente para que o recurso não seja implantado até que seja necessário.
- A mudança segue boas práticas do Bíceps? Em outros módulos do Microsoft Learn, você aprendeu 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 para solicitações pull incluir 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 da solicitação pull. Se o autor da solicitação pull tiver vinculado a itens de trabalho ou problemas, verifique se as alterações na solicitação pull atendem aos critérios de sucesso que o item de trabalho definiu.
Concluir um pull request
Depois que a solicitação pull for aprovada, ela poderá ser concluída. Isso significa que o conteúdo da solicitação pull é 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 recursos e solicitações pull, o processo da sua equipe 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 a principal.
Outros membros da equipe analisam as alterações. Quando estiverem satisfeitos, aprovam a solicitação pull e ela é mesclada à ramificação principal do repositório compartilhado.
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.
