Políticas e configurações de branch

  • Artigo
  • 46 minutos para o fim da leitura

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

As políticas de branch ajudam as equipes a proteger seus importantes ramos 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 as 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 PRs (solicitações de pull) para todas as alterações.

Pré-requisitos

  • Para definir políticas de branch, você deve ser membro do grupo de segurança Project Administradores 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.

  • Se você quiser usar Azure DevOps comandos de política do az repos da CLI para gerenciar políticas de branch, siga as etapas em Introdução com Azure DevOps CLI.

  • Para definir políticas de branch, você deve ser membro do grupo de segurança Project Administradores 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, selecione Repos>Branches para abrir a página Branches no portal da Web.

Screenshot that shows the Branches menu item.

Você também pode acessar as configurações de política de branch com Project Configurações>RepositoryPoliciesBranch>>PoliciesBranch><Name>.

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 pela lista ou pesquisar sua ramificação na caixa de nome do branch de pesquisa no canto superior direito.

Selecione o ícone Mais opções ao lado da ramificação e selecione políticas do Branch no menu de contexto.

Screenshot that shows Open the branch policies from the context menu.

Localize seu branch na página. Você pode navegar pela lista ou pesquisar sua ramificação usando a caixa Pesquisar todas as ramificações no canto superior direito.

Screenshot that shows the Branches page.

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

Screenshot that shows Open the branch policies from the context menu.

Configure 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.

Screenshot that shows the Policies tab.

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 a 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:

Screenshot that shows the Enable the Require Code Reviews policy.

  • 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 Aprovação 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 por push no branch de origem pode adicionar confirmações 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 aprovar.

  • 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 mudar,
    • 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.

Check the Require Code Reviews box

  • Se os Solicitantes puderem aprovar suas próprias alterações não estiverem selecionados, 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 a 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 forem 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.

Screenshot of requiring linked work items in pull requests.

Require linked work items in your pull requests

Verificar a resolução de comentários

A política de verificação de 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 se há resolução de comentários como Ativada. Em seguida, selecione se deseja tornar a política necessária ou opcional.

Check for comment resolution

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 a resolução de comentários.

Check for comment resolution

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 aplicando uma estratégia de mesclagem para conclusão de PR.

Defina os tipos de mesclagem Limite como On para limitar quais tipos de mesclagem permitir em seu repositório.

Limit merge types

  • 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 de squash cria um histórico linear com uma única confirmação no branch de destino com as alterações do branch de origem. Saiba mais sobre a mesclagem de squash e como ela afeta o histórico de ramificações.
  • A rebase e o avanço rápido criam um histórico linear reproduzindo as confirmações de origem no branch de destino sem confirmação de mesclagem.
  • A rebase com a confirmação de mesclagem reproduza as confirmações 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.

Set merge requirements

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

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 que tem como destino o 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 da validação de build.

    Screenshot that shows the Add button next to Build validation.

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

    Build policy settings

    • Selecione o pipeline de build.

    • Opcionalmente, defina um filtro Path. 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.

    • No requisito política, selecione Obrigatório ou Opcional. Se você escolher Obrigatório, os builds deverão ser concluídos com êxito para concluir 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 do branch protegido não interrompa as alterações para PRs abertas.

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

        Essa opção é melhor para equipes cujas ramificações importantes têm poucas alterações. Teams trabalhando em ramificações de desenvolvimento ocupadas podem achar perturbador esperar por um build sempre que a ramificação for atualizada.

      • Após <n> horas, se <o nome> do branch tiver sido atualizado: essa opção expirará o status da política atual quando o branch protegido for atualizado se o build de passagem for mais antigo 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: as atualizações do branch protegido não alteram o status da política. Esse valor reduz o número de builds, mas pode causar problemas ao concluir PRs que não foram atualizados recentemente.

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

  3. Selecione Salvar.

Quando o proprietário da PR envia por push as alterações que são compiladas com êxito, o status da política é atualizado.

Se você tiver um nome> de branch imediatamente quando <for atualizado ou após <n> horas se <o nome> do branch tiver sido atualizado, o status da política será atualizado 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.

Add build policy

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

Build policy settings

  1. Selecione a definição de Build.

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

  3. Selecione o requisito política. Se você escolher Obrigatório, os builds deverão ser concluídos 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 do branch protegido não interrompa as alterações para solicitações de pull abertas.

    • Imediatamente quando branch name é atualizada: essa opção define o status da política de build em uma solicitação de pull para falhar quando o branch protegido é atualizado. Requeia 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 for alterado. Essa opção é melhor para equipes que têm ramificações importantes com um volume menor de alterações. Teams trabalhando em ramificações de desenvolvimento ocupadas podem achar perturbador aguardar a conclusão de um build sempre que a ramificação protegida for atualizada.
    • Após n horas, se branch name tiver sido atualizado: essa opção expirará o status da política atual quando o branch protegido for atualizado se o build de passagem for mais antigo do que o limite inserido. Essa opção é um compromisso 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: as atualizações do branch protegido não alteram o status da política. Esse valor reduz o número de builds para o 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 essa política de build. Esse nome identifica a política na página de políticas do Branch . Se você não especificar um nome de exibição, a política usará o nome de definição de build.

  6. Selecione Salvar.

Quando o proprietário envia por push alterações que são criadas com êxito, o status da política é atualizado. 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 de build atualizada, o status da política será atualizado 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 o status detalhado em suas 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.

Require external services to approve

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 o status detalhado em suas PRs. A política de branch para serviços adicionais traz a capacidade para que esses serviços de terceiros participem do fluxo de trabalho de PR e estabeleçam requisitos de política.

Require external services to approve

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

Incluir automaticamente revisores de código

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

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

    Screenshot that shows Add required reviewers.

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

    Screenshot that shows the Add new reviewer policy screen.

    • 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 que você especificar 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 para todas as solicitações de pull no branch.

    • Selecione Permitir que os solicitantes aprovem suas próprias alterações se os proprietários de solicitações de pull 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. Selecione 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.

Enter the path and required reviewers

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.

Add automatic reviewers

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.

Required reviewers are automatically added

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.

Pull request status shows that reviewers have approved

Ignorar políticas de branch

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

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 se aplica somente à conclusão da solicitação de pull. Os usuários com essa permissão podem concluir solicitações de pull mesmo se as solicitações de pull não atenderem às políticas.

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

Screenshot showing bypass policy enforcement permissions.

Para obter mais informações sobre como gerenciar essas permissões, consulte as 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 se o conjunto atual de políticas de branch não estiver satisfeito.
  • 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 compatível.

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 e curingas. Exemplos:

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

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

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

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

  • /WebApp/*;!/WebApp/Tests/* inclui todos os arquivos, /WebApp exceto arquivos em /WebApp/Tests
  • !/WebApp/Tests/* especifica nenhum arquivo, já que nada está incluído primeiro

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

P & R

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

Você não pode enviar alterações por push 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 assim 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 são reavaliadas no servidor quando os proprietários de solicitação de pull pressionam as alterações e quando os revisores votam. Se uma política disparar um build, o status de build 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 para / frente e barras invertidas \. 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 adicionar o grupo como revisor. Qualquer membro do grupo pode aprovar para atender ao requisito de política.

Tenho permissões de política de bypass. Por que ainda vejo falhas de política no status da 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, o status da política relatada é apenas consultivo. Se o usuário com permissões de bypass aprovar, o status da 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á definida"?

A política Exigir um número mínimo de revisores e a política de revisores incluída 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 automaticamentepermitem 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 .