Políticas e configurações de branch

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

As políticas de ramificação ajudam as equipes a proteger suas importantes ramificações de desenvolvimento. As políticas impõem a qualidade de código e os padrões de gerenciamento de alterações da sua equipe. Este artigo descreve como definir e gerenciar políticas de branch. Para obter uma visão geral de todas as políticas e configurações de repositório e branch, consulte Configurações e políticas do repositório Git.

Um branch que tem as políticas necessárias configuradas não pode ser excluído e requer solicitações de pull (PRs) para todas as alterações.

Pré-requisitos

  • Para definir políticas de branch, você deve ser membro do grupo de segurança Administradores do Projeto ou ter permissões de políticas de Edição no nível do repositório. Para obter mais informações, consulte Definir permissões de repositório Git.

Configurar políticas de branch

Para gerenciar políticas de branch, selecioneBranches do Repos> para abrir a página Branches no portal da Web.

Captura de tela que mostra o item de menu Branches.

Você também pode acessar as configurações de política de branch com oNome> do Branch de Políticas de Branch de Políticas<>> deRepositório> deConfigurações> do Projeto.

Os branches que têm políticas exibem um ícone de política. Você pode selecionar o ícone para ir diretamente para as configurações de política do branch.

Para definir políticas de branch, localize o branch que você deseja gerenciar. Você pode navegar na lista ou pesquisar seu branch na caixa Nome do branch de pesquisa no canto superior direito.

Selecione o ícone Mais opções ao lado do branch e selecione Políticas de branch no menu de contexto.

Captura de tela que mostra Abrir as políticas de branch no menu de contexto.

Localize seu branch na página. Você pode navegar na lista ou pesquisar seu branch usando a caixa Pesquisar todos os branches no canto superior direito.

Captura de tela que mostra a página Branches.

Selecione o botão ... . Selecione Políticas de branch no menu de contexto.

Captura de tela que mostra Abrir as políticas de branch no menu de contexto.

Defina políticas na página de configurações do branch. Consulte as seções a seguir para obter descrições e instruções para cada tipo de política.

Configure suas políticas na página Políticas. Consulte as seções a seguir para obter descrições de cada tipo de política. Selecione Salvar alterações para aplicar sua nova configuração de política.

Captura de tela que mostra a guia Políticas.

Exigir um número mínimo de revisores

As revisões de código são importantes para projetos de desenvolvimento de software. Para garantir que as equipes revisem e aprovem PRs, você pode exigir aprovação de um número mínimo de revisores. A política básica exige que um número especificado de revisores aprove o código, sem rejeições.

Para definir a política, em Políticas de Branch, defina Exigir um número mínimo de revisores como Ativado. Insira o número necessário de revisores e selecione qualquer uma das seguintes opções:

Captura de tela que mostra a política Habilitar a política Exigir Revisões de Código.

  • Selecione Permitir que os solicitantes aprovem suas próprias alterações para permitir que o criador de uma PR vote em sua aprovação. Caso contrário, o criador ainda poderá votar Aprovar na PR, mas seu voto não contará para o número mínimo de revisores.

  • Selecione Proibir que o pusher mais recente aprove suas próprias alterações para impor a segregação de tarefas. Por padrão, qualquer pessoa com permissão push no branch de origem pode adicionar commits e votar na aprovação de PR. Selecionar essa opção significa que o voto do pusher mais recente não conta, mesmo que eles possam normalmente aprovar suas próprias alterações.

  • Selecione Permitir conclusão mesmo que alguns revisores votem para aguardar ou rejeitar para permitir a conclusão da PR, mesmo que alguns revisores votem contra a aprovação. O número mínimo de revisores ainda deve ser aprovado.

  • Em Quando novas alterações são enviadas por push:

    • Selecione Exigir pelo menos uma aprovação na última iteração para exigir pelo menos um voto de aprovação para a última alteração do branch de origem.
    • Selecione Redefinir todos os votos de aprovação (não redefine votos para rejeitar ou aguardar) para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou aguardar, sempre que o branch de origem for alterado,
    • Selecione Redefinir todos os votos do revisor de código para remover todos os votos do revisor sempre que o branch de origem for alterado, incluindo votos para aprovar, rejeitar ou aguardar.

Marque a caixa Exigir Revisões de Código

  • Se os solicitantes puderem aprovar suas próprias alterações não estiver selecionado, o criador da solicitação de pull ainda poderá votar Aprovar em sua solicitação de pull, mas seu voto não contará para o número mínimo de revisores.
  • Se algum revisor rejeitar as alterações, a solicitação de pull não poderá ser concluída, a menos que você selecione Permitir conclusão, mesmo que alguns revisores votem para aguardar ou rejeitar.
  • Você pode redefinir os votos do revisor de código quando novas alterações são enviadas por push para o branch de origem. Selecione Redefinir votos do revisor de código quando houver novas alterações.

Se todas as outras políticas forem aprovadas, o criador poderá concluir a PR quando o número necessário de revisores a aprovar.

Verificar se há itens de trabalho vinculados

Para o acompanhamento de gerenciamento de itens de trabalho, você pode exigir associações entre PRs e itens de trabalho. A vinculação de itens de trabalho fornece mais contexto para alterações e garante que as atualizações passem pelo processo de acompanhamento de itens de trabalho.

Para definir a política, em Políticas de Branch, defina Verificar itens de trabalho vinculados como Ativado. Essa configuração exige que os itens de trabalho sejam vinculados a uma PR para que a PR seja mesclada. Torne a configuração Opcional para avisar quando não há itens de trabalho vinculados, mas permitir a conclusão da solicitação de pull.

Captura de tela da exigência de itens de trabalho vinculados em solicitações de pull.

Exigir itens de trabalho vinculados em suas solicitações de pull

Verificar a resolução de comentários

A política Verificar resolução de comentários verifica se todos os comentários de PR foram resolvidos.

Configure uma política de resolução de comentários para seu branch definindo Verificar resolução de comentários comoAtivado. Em seguida, selecione se deseja tornar a política Obrigatória ou Opcional.

Verificar a resolução de comentários

Para obter mais informações sobre como trabalhar com comentários de solicitação de pull, consulte Examinar solicitações de pull.

Configure uma política de resolução de comentários para seu branch selecionando Verificar se há resolução de comentários.

Verificar a resolução de comentários

Para obter mais informações sobre como trabalhar com comentários de solicitação de pull, consulte Examinar solicitações de pull.

Limitar tipos de mesclagem

Azure Repos tem várias estratégias de mesclagem e, por padrão, todas elas são permitidas. Você pode manter um histórico de branch consistente impondo uma estratégia de mesclagem para conclusão de PR.

Defina Limitar tipos de mesclagem como Ativado para limitar quais tipos de mesclagem permitir em seu repositório.

Limitar tipos de mesclagem

  • A mesclagem básica (sem avanço rápido) cria uma confirmação de mesclagem no destino cujos pais são os branches de destino e de origem.
  • A mesclagem squash cria um histórico linear com um único commit no branch de destino com as alterações do branch de origem. Saiba mais sobre combinação por squash mesclagem e como ela afeta o histórico de ramificações.
  • A rebase e o avanço rápido criam um histórico linear reproduzindo confirmações de origem no branch de destino sem confirmação de mesclagem.
  • A rebase com commit de mesclagem reproduz os commits de origem no destino e também cria uma confirmação de mesclagem.

Observação

Esse recurso está disponível para Azure DevOps Server 2020 e versões posteriores.

Impor uma estratégia de mesclagem

Mantenha um histórico de branch consistente impondo uma estratégia de mesclagem quando uma solicitação de pull for concluída. Selecione Impor uma estratégia de mesclagem e escolha uma opção para exigir que as solicitações de pull se mesclem usando essa estratégia.

Definir requisitos de mesclagem

  • Nenhuma mesclagem de avanço rápido – essa opção mescla o histórico de commit do branch de origem quando a solicitação de pull é fechada e cria um commit de mesclagem no branch de destino.
  • Mesclagem de squash – conclua todas as solicitações de pull com uma mesclagem de combinação por squash, criando um único commit no branch de destino com as alterações do branch de origem. Saiba mais sobre combinação por squash mesclagem e como ela afeta seu histórico de ramificação.

Validação de build

Você pode definir uma política que exige que as alterações de PR sejam criadas com êxito antes que a PR possa ser concluída. As políticas de build reduzem as quebras e mantêm os resultados do teste aprovados. As políticas de build ajudam mesmo se você estiver usando a CI ( integração contínua ) em seus branches de desenvolvimento para detectar problemas antecipadamente.

Uma política de validação de build enfileira um novo build quando uma nova PR é criada ou as alterações são enviadas por push para uma PR existente direcionada ao branch. A política de build avalia os resultados do build para determinar se a PR pode ser concluída.

Importante

Antes de especificar uma política de validação de build, você deve ter um pipeline de build. Se você não tiver um pipeline, consulte Criar um pipeline de build. Escolha o tipo de build que corresponde ao tipo de projeto.

Para adicionar uma política de validação de build

  1. Selecione o + botão ao lado de Validação de build.

    Captura de tela que mostra o botão Adicionar ao lado de Validação de build.

  2. Preencha o formulário Definir política de build :

    Configurações de política de build

    • Selecione o Pipeline de build.

    • Opcionalmente, defina um filtro Demarcador. Saiba mais sobre filtros de caminho em políticas de branch.

    • Em Gatilho, selecione Automático (sempre que o branch de origem for atualizado) ou Manual.

    • Em Requisito de política, selecione Obrigatório ou Opcional. Se você escolher Obrigatório, os builds deverão ser concluídos com êxito para concluir as PRs. Escolha Opcional para fornecer uma notificação da falha de build, mas ainda permitir a conclusão de PRs.

    • Defina uma expiração de build para garantir que as atualizações no branch protegido não interrompa as alterações para PRs abertas.

      • Imediatamente quando <o nome> do branch é atualizado: essa opção define a política de build de PR status com falha sempre que o branch é atualizado e requeu um build. Essa configuração garante que a PR altere o build com êxito, mesmo que o branch protegido seja alterado.

        Essa opção é melhor para equipes cujos branches importantes têm poucas alterações. As equipes que trabalham em branches de desenvolvimento ocupados podem achar perturbador esperar por um build sempre que o branch for atualizado.

      • Após <n> horas se <o nome> do branch tiver sido atualizado: essa opção expirará a política atual status quando o branch protegido for atualizado se o build de passagem for mais antigo do que o limite inserido. Essa opção é um comprometimento entre sempre ou nunca exigir um build quando o branch protegido for atualizado. Essa opção reduz o número de builds quando o branch protegido tem atualizações frequentes.

      • Nunca: Atualizações ao branch protegido não altere o status de política. Esse valor reduz o número de builds, mas pode causar problemas ao concluir PRs que não foram atualizadas recentemente.

    • Insira um Nome de exibição opcional para esta política de build. Esse nome identifica a política na página Políticas de branch. Se você não especificar um nome de exibição, a política usará o nome do pipeline de build.

  3. Clique em Salvar.

Quando o proprietário da PR efetua push de alterações que são compilá-las com êxito, a política status é atualizada.

Se você tiver uma política de build imediatamente quando <o nome> do branch for atualizado ou Após <n> horas se <o nome> do branch tiver sido atualizado, a política status será atualizada quando o branch protegido for atualizado, se o build anterior não for mais válido.

Observação

Esse recurso está disponível para Azure DevOps Server 2020 e versões posteriores.

Defina uma política que exige alterações em uma solicitação de pull para compilar com êxito com o branch protegido antes que a solicitação de pull possa ser concluída. As políticas de build reduzem as quebras e mantêm os resultados do teste aprovados. As políticas de build ajudam mesmo se você estiver usando a CI ( integração contínua ) em seus branches de desenvolvimento para detectar problemas antecipadamente.

Se uma política de validação de build estiver habilitada, um novo build será enfileirado quando uma nova solicitação de pull for criada ou se as alterações forem enviadas por push para uma solicitação de pull existente direcionada ao branch. Em seguida, a política de build avalia os resultados do build para determinar se a solicitação de pull pode ser concluída.

Importante

Antes de especificar uma política de validação de build, você deve ter uma definição de build. Se você não tiver uma, consulte Criar uma definição de build e escolha o tipo de build que corresponde ao tipo de projeto.

Adicionar política de build

Escolha Adicionar política de build e configure suas opções em Adicionar política de build.

Configurações de política de build

  1. Selecione a definição compilar.

  2. Escolha o tipo de Gatilho. Selecione Automático (sempre que o branch de origem for atualizado) ou Manual.

  3. Selecione o Requisito de política. Se você escolher Obrigatório, as compilações deverão ser concluídas com êxito para concluir as solicitações de pull. Escolha Opcional para fornecer uma notificação da falha de build, mas ainda permitir a conclusão das solicitações de pull.

  4. Defina uma expiração de build para garantir que as atualizações em seu branch protegido não interrompa as alterações para solicitações de pull abertas.

    • Imediatamente quando branch name é atualizado: essa opção define a política de build status em uma solicitação de pull para falha quando o branch protegido é atualizado. Requeira um build para atualizar o status de build. Essa configuração garante que as alterações nas solicitações de pull sejam compiladas com êxito, mesmo quando o branch protegido é alterado. Essa opção é melhor para equipes que têm branches importantes com um volume menor de alterações. As equipes que trabalham em branches de desenvolvimento ocupados podem achar perturbador aguardar a conclusão de um build sempre que o branch protegido for atualizado.
    • Após n horas se branch name tiver sido atualizado: essa opção expirará a política atual status quando o branch protegido for atualizado se o build de passagem for mais antigo do que o limite inserido. Essa opção é um comprometimento entre sempre exigir um build quando o branch protegido é atualizado e nunca exigir um. Essa opção é excelente para reduzir o número de builds quando o branch protegido tem atualizações frequentes.
    • Nunca: Atualizações para o branch protegido não altere o status de política. Esse valor reduz o número de builds para seu branch. Isso pode causar problemas ao fechar solicitações de pull que não foram atualizadas recentemente.

  5. Insira um nome de exibição opcional para esta política de build. Esse nome identifica a política na página Políticas de branch . Se você não especificar um nome de exibição, a política usará o nome da definição de build.

  6. Clique em Salvar.

Quando o proprietário envia por push as alterações criadas com êxito, a status de política é atualizada. Se você tiver uma política de build atualizada imediatamente quando branch name for atualizada ou Após n horas, se branch name tiver sido escolhida, a política status será atualizada quando o branch protegido for atualizado se o build mais recente não for mais válido.

Verificações de status

Os serviços externos podem usar a API de Status de PR para postar status detalhadas em seus PRs. A política de branch para serviços adicionais permite que esses serviços de terceiros participem do fluxo de trabalho de PR e estabeleçam requisitos de política.

Exigir que os serviços externos aprovem

Para obter instruções sobre como configurar essa política, consulte Configurar uma política de branch para um serviço externo.

Exigir aprovação de serviços externos

Os serviços externos podem usar a API de Status de PR para postar status detalhadas em seus PRs. A política de branch para serviços adicionais traz a capacidade desses serviços de terceiros participarem do fluxo de trabalho de PR e estabelecerem requisitos de política.

Exigir que os serviços externos aprovem

Para obter instruções sobre como configurar essa política, consulte Configurar uma política de branch para um serviço externo.

Incluir revisores de código automaticamente

Você pode adicionar revisores automaticamente a solicitações de pull que alteram arquivos em diretórios e arquivos específicos ou a todas as solicitações de pull em um repositório.

  1. Selecione o + botão ao lado de Revisores incluídos automaticamente.

    Captura de tela que mostra Adicionar revisores necessários.

  2. Preencha a tela Adicionar nova política de revisor .

    Captura de tela que mostra a tela Adicionar nova política de revisor.

    • Adicione pessoas e grupos aos Revisores.

    • Selecione Opcional se você quiser adicionar revisores automaticamente, mas não exigir sua aprovação para concluir a solicitação de pull.

      Ou selecione Obrigatório se as solicitações de pull não puderem ser concluídas até:

      • Cada indivíduo adicionado como revisor aprova as alterações.
      • Pelo menos uma pessoa em cada grupo adicionado como revisor aprova as alterações.
      • Se apenas um grupo for necessário, o número mínimo de membros especificados aprovará as alterações.

    • Especifique os arquivos e pastas que exigem os revisores incluídos automaticamente. Deixe esse campo em branco para exigir os revisores de todas as solicitações de pull no branch.

    • Selecione Permitir que os solicitantes aprovem suas próprias alterações se os proprietários de pull request puderem votar para aprovar suas próprias solicitações de pull para atender a essa política.

    • Você pode especificar uma mensagem do feed de atividades que aparece na solicitação de pull.

  3. Clique em Salvar.

Observação

Esse recurso está disponível para Azure DevOps Server 2020 e versões posteriores.

Selecione revisores para diretórios e arquivos específicos em seu repositório.

Insira o caminho e os revisores necessários

Esses revisores são adicionados automaticamente a solicitações de pull que alteram arquivos ao longo desses caminhos. Você também pode especificar uma mensagem do feed de atividades.

Adicionar revisores automáticos

Se você selecionar Obrigatório, a solicitação de pull não poderá ser concluída até:

  • Cada usuário adicionado como revisor para o caminho aprova as alterações.
  • Pelo menos uma pessoa em cada grupo adicionado ao caminho aprova as alterações.
  • O número de revisores especificados para cada grupo adicionado ao caminho aprova as alterações.

Revisores necessários são adicionados automaticamente

Selecione Opcional se você quiser adicionar revisores automaticamente, mas não exigir sua aprovação para concluir a solicitação de pull.

Você pode selecionar Solicitantes que podem aprovar suas próprias alterações.

Quando todos os revisores necessários aprovarem o código, você poderá concluir a solicitação de pull.

A status de solicitação de pull mostra que os revisores aprovaram

Ignorar políticas de branch

Em alguns casos, talvez seja necessário ignorar os requisitos de política. As permissões de bypass permitem enviar alterações por push diretamente a um branch ou concluir solicitações de pull que não satisfazem as políticas de branch. Você pode conceder permissões de bypass a um usuário ou grupo. Você pode definir o escopo de permissões de bypass para um projeto inteiro, um repositório ou um único branch.

Duas permissões permitem que os usuários ignorem a política de branch de maneiras diferentes:

  • Ignorar políticas ao concluir solicitações de pull só se aplica à conclusão da solicitação de pull. Os usuários com essa permissão podem concluir solicitações de pull mesmo que as solicitações de pull não satisfaçam as políticas.

  • Ignorar políticas ao enviar por push se aplica a pushes de repositórios locais e edições feitas na Web. Os usuários com essa permissão podem enviar alterações diretamente para branches protegidos sem atender aos requisitos de política.

Captura de tela mostrando permissões de imposição de política de bypass.

Para obter mais informações sobre como gerenciar essas permissões, consulte Permissões do Git.

No TFS 2015 até o TFS 2018 Atualização 2, a permissão Isenta de imposição de política permite que os usuários com essa permissão executem as seguintes ações:

  • Ao concluir uma solicitação de pull, opt-in para substituir políticas e concluir uma solicitação de pull mesmo que o conjunto atual de políticas de branch não seja atendido.
  • Envie por push diretamente para um branch mesmo que esse branch tenha políticas de branch definidas. Observe que quando um usuário com essa permissão faz um push que substituiria a política de branch, o push ignora automaticamente a política de branch sem nenhuma etapa de aceitação ou aviso.

Importante

Tenha cuidado ao conceder a capacidade de ignorar políticas, especialmente nos níveis de repositório e projeto. As políticas são uma pedra angular do gerenciamento de código-fonte seguro e em conformidade.

Filtros de caminho

Várias políticas de branch oferecem filtros de caminho. Se um filtro de caminho for definido, a política se aplicará somente aos arquivos que correspondem ao filtro de caminho. Deixar esse campo em branco significa que a política se aplica a todos os arquivos no branch.

Você pode especificar caminhos absolutos (o caminho deve iniciar por / ou um curinga) e curingas. Exemplos:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Você pode especificar vários caminhos usando ; como separador. Exemplo:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Os caminhos prefixados com ! serão excluídos se forem incluídos de outra forma. Exemplo:

  • /WebApp/*;!/WebApp/Tests/* inclui todos os arquivos em /WebApp , exceto arquivos em /WebApp/Tests
  • !/WebApp/Tests/* não especifica arquivos, já que nada é incluído primeiro

A ordem dos filtros é significativa. Os filtros são aplicados da esquerda para a direita.

P & R

Posso enviar alterações diretamente para branches que têm políticas de branch?

Você não pode enviar alterações diretamente para branches que tenham políticas de branch necessárias , a menos que você tenha permissões para ignorar as políticas de branch. As alterações nesses branches só podem ser feitas por meio de solicitações de pull. Você pode enviar alterações por push diretamente para branches que têm políticas de branch opcionais , se elas não tiverem políticas de branch necessárias.

O que é preenchimento automático?

As solicitações de pull em branches com políticas de branch configuradas têm o botão Definir preenchimento automático . Selecione essa opção para concluir automaticamente a solicitação de pull depois que ela atender a todas as políticas. O preenchimento automático é útil quando você não espera problemas com suas alterações.

Quando as condições de política de branch são verificadas?

As políticas de branch reavaliam no servidor quando os proprietários da solicitação de pull efetuam push das alterações e quando os revisores votam. Se uma política disparar um build, o build status será configurado como aguardando até que o build seja concluído.

Posso usar definições de build XAML em políticas de branch?

Não, você não pode usar definições de build XAML em políticas de branch.

Quais caracteres curinga posso usar para revisores de código necessários?

Os asteriscos únicos correspondem a qualquer número de caracteres * , incluindo barras / de avanço e barras traseiras \. Os pontos de interrogação ? correspondem a qualquer caractere único.

Exemplos:

  • *.sql corresponde a todos os arquivos com a extensão .sql .
  • /ConsoleApplication/* corresponde a todos os arquivos na pasta chamada ConsoleApplication.
  • /.gitattributes corresponde ao arquivo .gitattributes na raiz do repositório.
  • */.gitignore corresponde a qualquer arquivo .gitignore no repositório.

Os caminhos do revisor de código necessários diferenciam maiúsculas de minúsculas?

Não, as políticas de branch não diferenciam maiúsculas de minúsculas.

Como posso configurar vários usuários como revisores necessários, mas exigir que apenas um deles aprove?

Você pode adicionar os usuários a um grupo e, em seguida, adicionar o grupo como um revisor. Qualquer membro do grupo pode aprovar para atender ao requisito de política.

Eu tenho permissões de política de bypass. Por que ainda vejo falhas de política no status de solicitação de pull?

As políticas configuradas são sempre avaliadas para alterações de solicitação de pull. Para usuários que têm permissões de política de bypass, a política relatada status é apenas consultoria. Se o usuário com permissões de bypass aprovar, o status de falha não bloqueará a conclusão da solicitação de pull.

Por que não consigo concluir minhas próprias solicitações de pull quando "Permitir que os solicitantes aprovem suas próprias alterações está definido"?

Tanto a política Exigir um número mínimo de revisores quanto a política Revisores incluídos automaticamente têm opções para Permitir que os solicitantes aprovem suas próprias alterações. Em cada política, a configuração se aplica somente a essa política. A configuração não afeta a outra política.

Por exemplo, sua solicitação de pull tem as seguintes políticas definidas:

  • Exigir um número mínimo de revisores requer pelo menos um revisor.
  • Revisores incluídos automaticamente exigem que você ou uma equipe em que você esteja como revisor.
  • Os revisores incluídos automaticamentetêm Permitir que os solicitantes aprovem suas próprias alterações habilitadas.
  • Exigir um número mínimo de revisores não tem Permitir que os solicitantes aprovem suas próprias alterações habilitadas.

Nesse caso, sua aprovação atende aos revisores incluídos automaticamente, mas não Requer um número mínimo de revisores, portanto, você não pode concluir a solicitação de pull.

Também pode haver outras políticas, como Proibir que o pusher mais recente aprove suas próprias alterações, que impedem que você aprove suas próprias alterações mesmo se Permitir que os solicitantes aprovem suas próprias alterações esteja definida.

O que acontece quando o caminho nos filtros de caminho não começa com / nem com curinga?

O caminho nos filtros de caminho que não começam com / nem com um curinga não terá efeito e o filtro de caminho será avaliado como se esse caminho não fosse especificado. Isso ocorre porque esse caminho não pode corresponder ao / caminho de arquivo absoluto que começa com.