Exercício – Azure Repos colaborando com pull requests
Os problemas de código encontrados antecipadamente são mais fáceis e mais baratos de corrigir. Portanto, as equipes de desenvolvimento se esforçam para efetuar push das verificações de qualidade de código o mais antecipadamente possível no processo de desenvolvimento.
Como o nome sugere, as políticas de branch lhe oferecem um conjunto de políticas prontas para uso, que podem ser aplicadas aos branches no servidor.
Todas as alterações que estão sendo enviadas por push para os branches do servidor precisam seguir essas políticas para serem aceitas.
As políticas são uma ótima forma 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 branch em seu branch 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
Abra a exibição de branches do repositório Git myWebApp no portal de equipe com partes ilimitadas. Selecione o branch principal e, no menu de contexto suspenso, escolha Políticas de branch:
Na exibição de políticas, 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 próprias alterações.
Embora isso possa ser aceitável para equipes experientes, em geral, deve ser evitado.
Use a política de revisão com a política de resolução de comentários. Ela permite impor que os comentários de revisão de código sejam resolvidos para que as alterações sejam aceitas. O solicitante pode extrair a informação do comentário e criar um item de trabalho e resolver as alterações. Isso garante, pelo menos, que os comentários da revisão de código não sejam perdidos na 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 disparado não estiver vinculado à alteração, ficará difícil entender por que ele foi feito com o passar do tempo. Isso é 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 tenham um item de trabalho vinculado a elas:
Selecione a opção para incluir revisores automaticamente quando uma solicitação de pull for gerada automaticamente. Você pode mapear quais revisores são adicionados com base na área do código que está sendo alterada:
Como ele funciona
Com as políticas de branch em vigor, o branch principal agora está totalmente protegido.
A única forma de efetuar push de alterações no branch principal é fazer primeiro 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 um branch com base em uma das histórias de usuário existentes no hub de itens de trabalho.
Ao criar um branch com base em um item de trabalho, o item de trabalho será vinculado automaticamente ao branch.
Opcionalmente, você pode incluir mais de um item de trabalho com um branch como parte do fluxo de trabalho de criação:
Ao criar o branch, coloque um prefixo no nome da pasta em que o branch será colocado.
No exemplo anterior, o branch entrará na pasta. Essa é uma ótima forma de organizar branches em ambientes com bastante trabalho.
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 fazer commit das alterações no branch.
Na imagem abaixo, você verá que pode fazer commit diretamente das alterações depois de editar o arquivo clicando no botão de commit.
O controle do caminho do arquivo no portal da equipe dá suporte à pesquisa.
Comece digitando o caminho do arquivo para ver todos os arquivos em seu repositório Git nesse diretório, começando com as letras que aparecem no menu suspenso de resultados da pesquisa do caminho de arquivo.
O editor de código no portal da Web tem vários recursos novos no Azure DevOps Server, como suporte para correspondência entre colchetes e alternância de espaço em branco.
Você pode carregar a paleta de comandos pressionando-a. Entre as diversas novas opções, agora você pode alternar o arquivo usando um minimapa do arquivo, recolher e expandir e outras operações padrão.
Para efetuar push dessas alterações do novo branch para o branch principal, crie uma solicitação de pull na exibição de solicitação de pull.
Selecione o novo branch como a origem e o principal como o branch de destino.
O novo formulário de solicitação de pull é compatível com markdown, portanto você pode 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 anteriores e atuais.
Todas as atualizações enviadas por push aos arquivos de código serão exibidas na guia Atualizações e uma lista de todos os commits será mostrada na guia Commits:
Abra a guia Arquivos: essa exibição dá suporte a comentários de código no nível de linha, no nível do arquivo e no geral.
Os comentários são compatíveis com @ para menções e # para vincular itens de trabalho e o texto dá suporte à sintaxe markdown:
Os comentários de código são persistentes no fluxo de trabalho da solicitação de pull; os comentários de código dão suporte a várias iterações de revisões e funcionam bem com respostas aninhadas.
A política do revisor possibilita um fluxo de trabalho de revisão de código como parte da aceitação de alterações.
É uma excelente maneira da equipe colaborar nas alterações de código enviadas por push para o branch principal.
Quando o número necessário de revisores aprova a solicitação de pull, ela pode ser concluída.
Você também pode marcar a solicitação de pull para conclusão automática após a revisão. As solicitações de pull são concluídas automaticamente depois que todas as políticas são compiladas com êxito.
E tem mais
Você já passou por uma situação em que um branch foi excluído acidentalmente? É difícil pensar no que aconteceu.
O Azure DevOps Server agora dá suporte à pesquisa de branches excluídos. Ele ajuda você a entender quem o excluiu e quando. A interface também permite recriar o branch.
Os branches excluídos só serão mostrados se você pesquisá-los pelo nome exato para evitar o ruído dos resultados da pesquisa.
Para pesquisar por uma ramificação excluída, digite o nome completo da ramificação na caixa de pesquisa de ramificação. Isso retornará todas as ramificações existentes que correspondem a esse texto.
Você também verá uma opção para pesquisar uma combinação exata na lista de branches excluídos.
Se uma correspondência for encontrada, você verá quem a excluiu e quando. Você também pode restaurar o branch. Restaurar a ramificação a recriará na confirmação para a qual ela foi apontada pela última vez.
No entanto, isso não restaurará políticas e permissões.