Compartilhar via

Políticas e configurações de branch

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

As políticas de branch ajudam as equipes a proteger seus importantes branches 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 dos repositórios e branches, consulte Configurações e políticas do repositório Git.

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

Pré-requisitos

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

Configurar políticas de branch

Para gerenciar políticas de filiais, selecione Repos>Branches 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 o Configurações de Projeto> Políticas>de Repositório > Política do Branch ><Nome Branch>.

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 branch na caixa de Pesquisar o nome da branch 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.

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.

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 relações públicas vote em sua aprovação. Caso contrário, o criador ainda poderá votar Aprovar a 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 direitos. 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 se alguns revisores votarem 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 em cada iteração para exigir pelo menos um voto de aprovação para a última alteração do branch de origem. A aprovação do usuário não é considerada em relação a nenhuma iteração anterior não aprovada enviada por ele. Como resultado, outra aprovação da última iteração deve ser feita por outro usuário. O recurso Exigir pelo menos uma aprovação em cada iteração está disponível no Azure DevOps Server 2022.1 e versões superiores.
    • 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.

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 do item de trabalho.

Para definir a política, em Políticas de Branch, defina Verificar se há itens de trabalho vinculados como Ativados. Essa configuração exige que os itens de trabalho sejam vinculados a uma PR para que a PR mescle. 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 necessidade de itens de trabalho vinculados em solicitações de pull.

Verificar a resolução de comentários

A política Verificar se a 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.

Captura de tela de Verificar 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

O 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 o Limite de tipos de mesclagem como Ativado para limitar quais tipos de mesclagem permitir em seu repositório.

Captura de tela de 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 uma única confirmação no branch de destino com as alterações do branch de origem. Saiba mais sobre a mesclagem squash e como ela afeta o histórico de ramificações.
  • Trocar base e encaminhar criam um histórico linear reproduzindo commits de origem no branch de destino sem confirmação de mesclagem.
  • Trocar base com mesclagem commit repete as commits de origem no destino e também cria uma confirmação de mesclagem.

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 integração contínua (CI) 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.

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

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

    Captura de tela de Criar configurações de política.

    • Selecionar 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.

    • Sob o 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 PRs. Escolha Opcional para fornecer uma notificação da falha de build, mas ainda permitir que as PRs preencham.

    • Defina um vencimento 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 o status da política de build de PR para falha sempre que o branch é atualizado e reenfileira um build. Essa configuração garante que as alterações de PR sejam compiladas com êxito mesmo se o branch protegido for alterado.

        Essa opção é melhor para equipes cujos branches importantes têm poucas alterações. As equipes que trabalham em branches de desenvolvimento ocupadas 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á 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 ou nunca exigir um build quando o branch protegido é atualizado. Essa opção reduz o número de builds quando o branch protegido tem atualizações frequentes.

      • Nunca: as atualizações para o 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. Clique em Salvar.

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

Se você tiver um Imediatamente quando <nome de branch> 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.

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 externos participem do fluxo de trabalho de PR e estabeleçam requisitos de política.

Captura de tela de Exigir aprovação de serviços externos.

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

Inclua 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 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 da solicitação 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. Clique em Salvar.

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 atendem às 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 se aplica apenas à 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 atendam às políticas.

  • Ignorar políticas ao enviar por push aplica-se 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 as permissões do Git.

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 base 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 (o caminho deve começar por / ou um caractere curinga) e caractere curinga. 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, /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.

Perguntas e Respostas

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

Você não pode enviar alterações por push diretamente para branches com 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?

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 da política de branch são verificadas?

As políticas de branch são reavaliadas no servidor quando os proprietários da 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 / e barras inversa\. 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ário 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 grupoe, em seguida, adicionar o grupo como um 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 consultoria. 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"?

Tanto a política Exige um número mínimo de revisores e a política de 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.
  • Os revisores incluídos automaticamente exigem que você ou uma equipe em que você esteja como revisor.
  • Os revisores incluídos automaticamente têm Permitir que os solicitantes aprovem suas próprias alterações habilitado.
  • Exigir um número mínimo de revisores não Permite que os solicitantes aprovem suas próprias alterações habilitadas.

Nesse caso, sua aprovação atende aos revisores incluídos automaticamente, mas nãoRequer um número mínimo de revisores , deste modo, 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 um curinga?

O caminho nos filtros de caminho que não começa com / nem com um curinga não terá efeito e o filtro de caminho será avaliado como se esse caminho não tivesse sido especificado. Essa caminho não pode corresponder ao / com que o caminho absoluto do arquivo começa.

  • Last updated on