Exercitar a colaboração do Azure Repos com solicitações de pull
Os problemas de código encontrados mais cedo são mais fáceis e baratos de corrigir. Portanto, as equipes de desenvolvimento se esforçam para implementar verificações de qualidade de código o mais cedo possível no processo de desenvolvimento.
Como o nome sugere, as políticas de ramo fornecem um conjunto de políticas prontas para uso que podem ser aplicadas aos ramos no servidor.
Todas as alterações que estão sendo enviadas por push para os branches do servidor precisam seguir essas políticas antes que as alterações possam ser aceitas.
As políticas são uma ótima maneira de impor a qualidade do código da sua equipe e os padrões de gerenciamento de alterações. Nesta receita, você aprenderá a configurar políticas de ramos em seu ramo principal.
Preparando-se
As políticas de branch prontas para uso incluem várias políticas, como validação de build e imposição de uma estratégia de mesclagem. Vamos nos concentrar apenas nas políticas de branch necessárias para configurar um fluxo de trabalho de revisão de código nesta receita.
Como fazer isso
Abra a visualização de ramificações para o repositório Git myWebApp no portal da equipe Parts-Unlimited. Selecione o ramo principal e, no menu de contexto suspenso, escolha políticas de ramificação:
No modo de exibição de políticas, ele apresenta políticas prontas para uso. Defina o número mínimo de revisores como 1:
A opção Permitir que os solicitantes aprovem suas próprias alterações permite que o remetente aprove suas alterações automaticamente.
Embora isso possa ser aceitável para equipes maduras, em geral, deve ser evitado.
Use a política de revisão com a política de resolução de comentários. Ele permite que você imponha que os comentários de revisão de código sejam resolvidos antes que as alterações sejam aceitas. O solicitante pode considerar o feedback do comentário e criar um novo item de trabalho para endereçar as alterações. Ele pelo menos garante que os comentários de revisão de código não sejam perdidos com a aceitação do código no branch principal:
Um requisito instiga uma alteração de código no projeto de equipe. Se o item de trabalho que acionou a tarefa não estiver vinculado à alteração, fica difícil entender por que ele foi realizado ao longo do tempo. É especialmente útil ao revisar o histórico de alterações. Configure a política Verificar itens de trabalho vinculados para bloquear alterações que não têm um item de trabalho vinculado a eles:
Selecione a opção para incluir automaticamente revisores quando uma solicitação de pull é gerada automaticamente. Você pode mapear quais revisores são adicionados com base na área do código que está sendo alterado:
Como funciona
Com as políticas de ramo em vigor, o ramo principal agora está totalmente protegido.
A única maneira de enviar alterações por push para o branch principal é primeiro fazer as alterações em outro branch e, em seguida, gerar uma solicitação de pull para disparar o fluxo de trabalho de aceitação de alterações.
Escolha criar uma nova ramificação de uma das histórias de usuário existentes no hub de itens de trabalho.
Ao criar uma nova ramificação de um item de trabalho, esse item de trabalho é automaticamente vinculado ao branch.
Opcionalmente, você pode incluir mais de um item de trabalho com uma ramificação como parte do fluxo de trabalho de criação:
Adicione um prefixo ao nome ao criar o branch, para que ele seja organizado dentro de uma pasta.
No exemplo anterior, o branch será colocado na pasta. É uma ótima maneira de organizar branches em ambientes ocupados.
Com o branch recém-criado selecionado no portal da Web, edite o arquivo HomeController.cs para incluir o snippet de código a seguir e confirmar as alterações no branch.
Na imagem abaixo, você verá que pode confirmar diretamente as alterações depois de editar o arquivo clicando no botão de confirmação.
O controle de caminho de arquivo no portal da equipe dá suporte à pesquisa.
Comece a digitar o caminho do arquivo para ver todos os arquivos no repositório Git nesse diretório, começando com essas letras aparecendo na lista suspensa de resultados da pesquisa do caminho do arquivo.
O editor de código no portal da Web tem vários novos recursos no Servidor do Azure DevOps, como suporte para correspondência de colchetes e alternância de espaço em branco.
Você pode carregar a paleta de comandos pressionando-a. Entre muitas outras novas opções, agora você pode alternar a visibilidade do arquivo usando um mini-mapa de arquivo, recolher e expandir, além de realizar outras operações padrão.
Para enviar essas alterações por push do novo branch para o branch principal, crie uma solicitação de pull na visualização de solicitação de pull.
Selecione o novo ramo como a origem e o ramo principal como o destino.
O novo formulário de solicitação de pull dá suporte a markdown, para que você possa adicionar a descrição usando a sintaxe markdown.
A janela de descrição também dá suporte a @ menções e # para vincular itens de trabalho:
A solicitação de pull é criada; a página de visão geral resume as alterações e o status das políticas.
A guia Arquivos mostra uma lista de alterações e a diferença entre as versões anterior e atual.
Todas as atualizações enviadas por push para os arquivos de código serão exibidas na guia Atualizações e uma lista de todas as confirmações é mostrada na guia Confirmações:
Abra a guia Arquivos: essa exibição dá suporte a comentários de código no nível da linha, no nível do arquivo e no geral.
Os comentários dão suporte a @ para menções e # para vincular itens de trabalho, e o texto dá suporte à sintaxe markdown:
Os comentários de código são preservados no fluxo de trabalho de pull request; os comentários de código suportam múltiplas iterações de revisões e funcionam bem com respostas aninhadas.
A política do revisor permite um fluxo de trabalho de revisão de código como parte da aceitação da alteração.
É uma excelente maneira de a equipe colaborar em quaisquer alterações de código enviadas por push para o branch principal.
Quando o número necessário de revisores aprova o pull request, ele pode ser concluído.
Você também pode marcar o pull request para conclusão automática após sua revisão. Ele preenche automaticamente os pull requests depois que todas as políticas tiverem sido satisfeitas com êxito.
Há mais
Você já esteve em um estado em que um ramo foi excluído acidentalmente? Não pode ser fácil descobrir o que aconteceu.
O Azure DevOps Server agora dá suporte à pesquisa de ramificações excluídas. Ele ajuda você a entender quem o excluiu e quando. A interface também permite recriar o ramo.
As ramificações excluídas só serão mostradas se você pesquisá-las pelo nome exato, para eliminar o ruído dos resultados da pesquisa.
Para pesquisar uma ramificação excluída, insira o nome completo da ramificação na caixa de pesquisa da ramificação. Ele retornará quaisquer branches existentes que correspondam a esse texto.
Você também verá uma opção para pesquisar uma correspondência exata na lista de branches excluídos.
Se uma correspondência for encontrada, você verá quem a deletou e quando. Você também pode restaurar o ramo. Restaurar a ramificação irá recriá-la no commit em que foi apontada por último.
No entanto, ele não restaurará políticas e permissões.