Revisar e mesclar alterações do Bicep
Você aprendeu como usar branchs de recursos e como aplicar a proteção de branches 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 de pull, incluindo como criá-las e usá-las. Você também aprenderá como é possível usar solicitações de pull para revisar o código Bicep.
Solicitações de pull
Uma solicitação de pull é uma solicitação de você, o desenvolvedor de um recurso, para o mantenedor do branch principal. Você pede ao mantenedor para efetuar pull de suas alterações no branch principal do repositório.
Solicitações de pull e proteções de branch
Ao configurar as proteções de branch, você pode exigir que os proprietários do código revisem a solicitação de pull. Por exemplo, você pode incluir os clientes potenciais do projeto como revisores para todas as suas solicitações de pull ou pode especificar que um determinado número de pessoas deve examinar cada solicitação de pull.
Solicitações de pull e políticas de branch
Ao configurar as políticas de branch, você pode exigir que pessoas específicas ou um grupo de pessoas examinem a solicitação de pull. Por exemplo, você pode incluir os clientes potenciais do projeto como revisores para todas as suas solicitações de pull ou pode especificar que um determinado número de pessoas deve examinar cada solicitação de pull.
Você também pode exigir que cada solicitação de pull esteja vinculada a um item de trabalho. Usando essa configuração, você pode acompanhar a partir de um item de trabalho que contém uma solicitação de recurso para o código que implementa a alteração, toda a forma de implantação em seu ambiente de produção.
Criar uma solicitação de pull
Você pode criar uma solicitação de pull usando a interface da web do GitHub. Você seleciona o branch de origem, onde fez as alterações e o branch de destino, que geralmente é o branch principal do repositório.
Você pode criar uma solicitação de pull usando a interface da web do Azure DevOps. Você seleciona o branch de origem, onde fez as alterações e o branch de destino, que geralmente é o branch principal do repositório.
Ao criar uma solicitação de pull, você precisa dar um nome a ela. É uma boa prática fazer com que seus nomes de solicitação de pull sejam claros e compreensíveis. Essa prática ajuda os membros de sua equipe a entender o contexto do que eles estão sendo solicitados a revisar. Se eles tiverem diferentes áreas de especialização, um bom nome pode ajudá-los a encontrar solicitações de pull onde eles possam contribuir com feedback significativo e ignorar as solicitações de pull que não são relevantes.
Além disso, os nomes de solicitação pull geralmente se tornam parte do histórico do repositório Git, portanto, é uma boa ideia torná-los compreensíveis quando alguém analisa o histórico.
Você também pode fornecer uma descrição às solicitações pull. Você pode mencionar pessoas específicas ou consultar problemas em suas descrições. Muitas equipes criam modelos padronizados para descrições de solicitação de pull para que fique claro o que é cada alteração.
Você também pode fornecer uma descrição às solicitações pull. Você pode mencionar pessoas específicas ou consultar itens de trabalho em suas descrições. Muitas equipes criam modelos padronizados para descrições de solicitação de pull para que fique claro o que é cada alteração.
Ao criar uma solicitação de pull, você pode convidar pessoas para revisar as alterações.
Às vezes, você cria uma solicitação de pull apenas para obter comentários de seus colegas. Nessas situações, você pode especificar que a solicitação de pull seja um rascunho. Os revisores saberão que você ainda está trabalhando nas alterações. Os revisores ainda podem fornecer comentários, mas fica claro que as alterações ainda não estão prontas para mesclagem. Quando estiver satisfeito com as alterações, você poderá remover o status de rascunho.
Mesmo depois de ter criado uma solicitação de pull, você pode continuar fazendo alterações no código em seu branch de recursos. Essas alterações se tornam parte da solicitação de pull.
Revisar uma solicitação de pull
Ao examinar uma solicitação de pull, é possível conferir todas as alterações. Você pode comentar sobre toda a solicitação de pull ou apenas sobre partes específicas dos arquivos que foram alterados. O autor da solicitação de pull pode responder a comentários e outros revisores podem participar de discussões. Esses recursos de comentários tornam a colaboração em solicitações de pull uma experiência interativa.
Ao examinar o código Bicep, procure estes elementos principais:
- O arquivo é implantável? Implante e teste o código Bicep antes que ele seja mesclado. Certifique-se de que não haja avisos de linter e que a implantação do Azure seja bem-sucedida. Em um futuro módulo 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 em sua equipe entendam seu código Bicep. Ao examinar um arquivo Bicep em uma solicitação de pull, certifique-se de entender exatamente o que é cada alteração. As variáveis e parâmetros estão bem nomeados? Os comentários foram usados para explicar alguma seção complexa do código?
- A alteração foi concluída? Se essa solicitação de pull representar parte de um trabalho mais amplo, verifique se o seu ambiente funcionará quando essa alteração for mesclada e implantada. Por exemplo, se a solicitação de pull reconfigurar um recurso do Azure em preparação para uma alteração posterior, verifique se o recurso continua funcionando corretamente durante todo o processo. Se a solicitação de 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 alteração segue as boas práticas do Bicep? Em outros módulos do Microsoft Learn, você aprendeu sobre os elementos de um bom código Bicep. Verifique se o código que você revisa segue as mesmas práticas recomendadas.
- A alteração corresponde à descrição? Incluir um título descritivo é uma boa prática para as solicitações de pull. Muitas equipes também exigem que as solicitações de 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 de pull. Se o autor da solicitação de pull tiver sido vinculado a itens de trabalho ou problemas, verifique se as alterações na solicitação de pull atendem aos critérios de êxito que o item de trabalho definiu.
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 da solicitação de pull é mesclado no brand principal.
Em algumas equipes, o autor da solicitação de 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 a solicitação de pull. Sua equipe deve decidir quem mescla solicitações de pull e quando.
Em algumas equipes, o autor da solicitação de 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 a solicitação de pull. Você pode até usar o Azure DevOps para concluir automaticamente uma solicitação de pull quando ela atender aos critérios de aprovação. Sua equipe deve decidir quem mescla solicitações de pull e quando.
O processo da sua equipe
Depois que você começar a usar branchs de recursos e solicitações de pull, o processo de 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 uma cópia local própria do repositório.
Concluídas as alterações, a equipe efetua push do branch local para o repositório compartilhado.
No repositório compartilhado, eles criam uma solicitação de pull para mesclar o branch ao principal.
Outros membros da equipe revisam as alterações. Quando estiverem satisfeitos, eles aprovarão a solicitação de pull e ela será mesclada ao branch principal do repositório compartilhado.
Eles excluem os branches no repositório compartilhado e na cópia local do repositório.
Em alguns cenários, o envio por push para o repositório remoto dispara um pipeline automatizado para verificar, testar e implantar o código. Você aprenderá mais sobre pipelines outros módulos do Microsoft Learn.
O diagrama a seguir ilustra esse processo revisado.
