Partilhar via

Políticas e definições de ramos

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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

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

Pré-requisitos

  • Para definir políticas de ramificação, seja membro do grupo de segurança Administradores de Projeto ou tenha permissões de edição de políticas a nível de repositório. Para obter mais informações, consulte Definir permissões do repositório Git.

  • Se pretender usar os comandos az repos policy da CLI do Azure DevOps para gerir políticas de branches, siga os passos em Introdução ao Azure DevOps CLI.

  • Para definir políticas de branches, seja membro do grupo de segurança Administradores de Projeto ou tenha permissões de Editar políticas ao nível do repositório. Para obter mais informações, consulte Definir permissões do repositório Git.

Configurar políticas de filial

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

Captura de ecrã que mostra o item de menu Branches.

Você também pode acessar as definições de políticas de ramo através de Configurações do Projeto>Repositório>Políticas>Políticas de Ramo><>.

As ramificações 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 da filial.

Para definir políticas de filial, localize a ramificação que você deseja gerenciar. Você pode navegar na lista ou pesquisar o nome da sua filial na caixa Pesquisar nome da filial no canto superior direito.

Selecione o ícone Mais opções ao lado da ramificação e, em seguida, selecione Políticas de ramificação no menu de contexto.

Captura de ecrã que mostra como abrir as políticas de ramificação a partir do menu de contexto.

Configure políticas na página de configurações da filial. 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 analisem e aprovem RPs, você pode exigir a aprovação de um número mínimo de revisores. A política básica requer que um número especificado de revisores aprove o código, sem rejeições.

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

Captura de tela que mostra a política de Exigir revisões de código.

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

  • Selecione Impedir que o autor da última alteração aprove as suas próprias mudanças para impor a segregação de deveres. Por padrão, qualquer pessoa com permissão push na ramificação de origem pode tanto adicionar commits quanto votar na aprovação de PR. Selecionar esta opção significa que o voto do empurrador mais recente não conta, mesmo que ele possa 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 do pedido de revisão, mesmo que alguns revisores votem contra a aprovação. O número mínimo de revisores ainda deve dar a sua aprovação.

  • Em Quando novas alterações são empurradas:
    • 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 de ramificação de origem.
    • Selecione Redefinir todos os votos de aprovação (não redefine votos para rejeitar ou esperar) para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou esperar, sempre que a ramificação de origem mudar.
    • Selecione Redefinir todos os votos do revisor de código para remover todos os votos do revisor sempre que a ramificação de origem for alterada, incluindo votos para aprovar, rejeitar ou aguardar.
  • Em Quando novas alterações são feitas:
    • 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 de ramificação de origem. A aprovação do usuário não é contada em relação a nenhuma iteração anterior não aprovada enviada por esse usuário. Como resultado, é necessária uma nova aprovação na última iteração que seja efetuada por outro utilizador. Exigir pelo menos uma aprovação em cada iteração está disponível no Azure DevOps Server 2022.1 e superior.
    • 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 de ramificação de origem.
    • Selecione Redefinir todos os votos de aprovação (não redefine votos para rejeitar ou esperar) para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou esperar, sempre que a ramificação de origem mudar.
    • Selecione Redefinir todos os votos do revisor de código para remover todos os votos do revisor sempre que a ramificação de origem for alterada, 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 aprovarem.

Verificar itens de trabalho vinculados

Para o acompanhamento do gerenciamento de itens de trabalho, você pode exigir associações entre RPs 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 controle de itens de trabalho.

Para definir a política, em Políticas de Filial, defina Verificar itens de trabalho vinculados como Ativado. Esta configuração requer que os itens de trabalho sejam vinculados a um PR para que o PR seja integrado. Torne a configuração Opcional para avisar quando não houver itens de trabalho vinculados, mas permita a conclusão da solicitação pull.

Captura de tela mostrando a necessidade de itens de trabalho vinculados em solicitações pull.

Verificar a resolução de comentários

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

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

Captura de ecrã de Verificar a resolução de comentários.

Para obter mais informações sobre como trabalhar com comentários de pull request, consulte Review pull requests.

Limitar tipos de fusão

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 ramificação consistente impondo uma estratégia de fusão para a conclusão de PR.

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

Captura de ecrã de Limitar tipos de mesclagem.

  • A mesclagem básica (sem avanço rápido) cria um commit de mesclagem na ramificação de destino cujos pais são as ramificações de destino e de origem.
  • Squash merge cria um histórico linear com um único commit na ramificação de destino com as alterações da ramificação de origem. Saiba mais sobre a fusão de squash e como ela afeta o histórico do ramo.
  • Rebasear e avançar rapidamente cria um histórico linear reproduzindo confirmações de origem na ramificação de destino sem confirmação de mesclagem.
  • Rebase com confirmação de mesclagem reaplica as confirmações da origem no destino e também cria uma confirmação de mesclagem.

Validação de compilação

Você pode definir uma política que exija que as alterações de RP sejam compiladas com êxito antes que a RP possa ser concluída. Crie políticas, reduza as interrupções e mantenha os resultados do teste aprovados. As políticas de criação podem ser úteis mesmo que se esteja a usar integração contínua (CI) nos ramos de desenvolvimento para detetar problemas antecipadamente.

Uma política de validação de compilação enfileira uma nova compilação quando um novo pull request é criado ou alterações são enviadas para um pull request existente que tenha como destino o ramo. A política de compilação avalia os resultados da compilação para determinar se a RP pode ser concluída.

Importante

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

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

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

    Captura de ecrã que mostra o botão Adicionar ao lado de Validação de compilação.

  2. Preencha o formulário Definir política de compilação:

    Captura de ecrã das definições de políticas de compilação.

    • Selecione o pipeline de construção.

    • Opcionalmente, defina um filtro de caminho. Saiba mais sobre filtros de caminhos nas políticas de ramo.

    • Em Gatilho, selecione Automático (sempre que a ramificação de origem for atualizada) ou Manual.

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

    • Defina uma expiração de compilação para garantir que as atualizações para sua ramificação protegida não interrompam as alterações para PRs abertas.

      • Imediatamente quando <o nome> da ramificação é atualizado: esta opção define o status da política de compilação de RP como falhando sempre que a ramificação é atualizada e coloca novamente uma compilação na fila. Essa configuração garante que as alterações de PR sejam construídas com êxito, mesmo que a ramificação protegida seja alterada.

        Esta opção é melhor para equipas cujas ramificações importantes têm poucas alterações. As equipas que trabalham em ramificações de desenvolvimento movimentadas podem achar perturbador esperar por uma compilação sempre que a ramificação é atualizada.

      • Após <n> horas se <o nome> da ramificação tiver sido atualizado: esta opção expira o estado atual da política quando a ramificação protegida é atualizada se o build aprovado for mais antigo do que o limite inserido. Esta opção representa um comprometimento entre exigir sempre ou nunca uma compilação quando a ramificação protegida é atualizada. Essa opção reduz o número de compilações quando sua ramificação protegida tem atualizações frequentes.

      • Nunca: as atualizações da ramificação protegida não alteram o status da política. Esse valor reduz o número de compilações, 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 compilação. Esse nome identifica a política na página Políticas de ramificações. Se você não especificar um nome para exibição, a política usará o nome do pipeline de compilação.

  3. Selecione Guardar.

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

Se tiver uma política de compilação assim que <o nome da ramificação> for atualizado ou após <n> horas se <o nome da ramificação> tiver sido atualizado, o estado da política é atualizado quando a ramificação protegida for atualizada, se a compilação anterior já não for válida.

Verificações de status

Os serviços externos podem usar a API de status de RP para postar status detalhado em seus RPs. A política de filial para serviços adicionais permite que esses serviços externos participem do fluxo de trabalho de RP e estabeleçam requisitos de política.

Captura de ecrã de Exigir a aprovação de serviços externos.

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

Incluir automaticamente revisores de código

Você pode adicionar automaticamente revisores a pull requests que alterem arquivos em diretórios e arquivos específicos ou a todos os pull requests 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 o ecrã 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 quiser adicionar revisores automaticamente, mas não exigir a aprovação deles para concluir a solicitação pull.

      Ou selecione Obrigatório se as solicitações 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 especificado aprovará as alterações.

    • Especifique os arquivos e pastas que necessitam dos revisores incluídos automaticamente. Deixe este campo em branco para exigir revisores para todas as pull requests no branch.

    • Selecione Permitir que os requerentes aprovem as suas próprias alterações se os proprietários do pull request puderem votar para aprovar os seus próprios pull requests para cumprir esta política.

    • Você pode especificar uma mensagem do feed de atividades que aparece no pull request.

  3. Selecione Guardar.

Ignorar políticas de branches

Em alguns casos, talvez seja necessário ignorar os requisitos da política. As permissões de bypass permitem-lhe enviar alterações diretamente para uma ramificação, ou concluir pedidos de pull que não satisfaçam as políticas de ramificação. 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 uma única ramificação.

Duas permissões permitem que os usuários ignorem a política de ramificação de maneiras diferentes:

  • As políticas de exceção ao concluir pull requests aplicam-se apenas à conclusão do pull request. Os usuários com essa permissão podem concluir solicitações pull mesmo que as solicitações pull não satisfaçam as políticas.

  • As políticas de bypass ao fazer push aplicam-se aos pushes feitos a partir de repositórios locais e edições feitas na web. Os usuários com essa permissão podem enviar as alterações diretamente para filiais protegidas sem atender aos requisitos da política.

Captura de ecrã mostrando permissões para contornar a aplicação de políticas.

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

Importante

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

Filtros de caminho

Várias políticas de ramificação oferecem filtros de caminho. Se um filtro de caminho for definido, a política se aplicará somente a arquivos que correspondam ao filtro de caminho. Deixar esse campo em branco significa que a política se aplica a todos os arquivos na ramificação.

Você pode especificar caminhos absolutos (o caminho deve começar por / ou caracteres universais) e caracteres universais. 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 ! são excluídos se de outra forma seriam incluídos. Exemplo:

  • /WebApp/*;!/WebApp/Tests/* inclui todos os arquivos em /WebApp exceto arquivos em /WebApp/Tests
  • !/WebApp/Tests/* não especifica nenhum arquivo, uma vez que nada é 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 filiais que têm políticas de filiais?

Não é possível enviar alterações diretamente para filiais com políticas de ramificação necessárias, a menos que tenha permissões para ignorar políticas de ramificação. As alterações nessas ramificações só podem ser feitas por meio de pull requests. Você pode enviar as alterações diretamente para ramificações que tenham políticas de ramificação opcionais , se elas não tiverem políticas de ramificação necessárias.

O que é o preenchimento automático?

Os pedidos de pull em ramificações com políticas de ramificação configuradas têm o botão Definir conclusão automática. Selecione esta opção para concluir automaticamente o pull request assim que cumprir todas as políticas. O preenchimento automático é útil quando você não espera problemas com suas alterações.

Quando são verificadas as condições da política da sucursal?

As políticas de filial são reavaliadas no servidor quando os proprietários da solicitação pull enviam alterações e quando os revisores votam. Se uma política acionar uma compilação, o status da compilação será definido como aguardando até que a compilação seja concluída.

Posso usar definições de compilação XAML em políticas de ramificação?

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

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

Os asteriscos * únicos correspondem a qualquer número de caracteres, incluindo barras / para a frente e barras \para trás. Os pontos de interrogação ? coincidem com 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 repo.
  • */.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 filial 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 então aprovar para atender ao requisito da política.

Tenho permissões de política para contornar. Porque ainda vejo falhas de política no status do pull request?

As políticas configuradas são sempre avaliadas quanto a alterações de pull request. Para utilizadores que têm permissões para desviar políticas, o estado da política reportada é apenas indicativo. Se o utilizador com permissões de bypass aprovar, o estado de falha não bloqueará a conclusão do pedido de pull.

Por que não consigo concluir os meus próprios pull requests quando "Permitir que os solicitantes aprovem as suas próprias alterações está configurada"?

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 pull tem as seguintes políticas definidas:

  • Exigir um número mínimo de revisores requer pelo menos um avaliador.
  • Os revisores incluídos automaticamente exigem que você ou uma equipe na qual você esteja como revisor.
  • Os revisores incluídos automaticamente tem a opção Permitir que os solicitantes aprovem as suas próprias alterações ativada.
  • Exigir um número mínimo de revisores não tem Permitir que os solicitantes aprovem suas próprias alterações habilitado.

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

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

O que acontece quando um caminho nos filtros de caminhos não começa com / ou com um carácter curinga?

O caminho nos filtros de caminho que não começa com / ou com um curinga não tem efeito e o filtro de caminho é avaliado como se esse caminho não tivesse sido especificado. Esse caminho não pode corresponder ao / caminho absoluto do arquivo com o qual começa.