Implementar restrições de mesclagem em branches

Concluído

As restrições de mesclagem de ramificação em sistemas de controle de versão hospedados pelo Azure DevOps e pelo GitHub são essenciais para controlar a qualidade do código, facilitar a colaboração e melhorar a estabilidade em projetos de desenvolvimento de software. Elas ajudam as organizações a impor revisões de código, validar a conclusão bem-sucedida de testes automatizados e impedir pushes forçados para ramificações designadas. Essas restrições ajudam a manter a integridade da base de código, impedir alterações acidentais e garantir que somente alterações verificadas e aprovadas sejam mescladas em branches de produção.

Os conceitos gerais sobre as restrições de mesclagem de branches são independentes de plataforma. Embora sua implementação difere um pouco entre o Azure DevOps e o GitHub, também há muitas semelhanças, fornecendo, em sua maioria, paridade de recursos entre eles.

Azure DevOps

No Azure DevOps, você pode implementar restrições de mesclagem de ramificação usando políticas baseadas em proteção de branch.

Para implementar a proteção de branch, navegue até o repositório no portal do Azure DevOps e selecione o branch ao qual você deseja aplicar restrições de mesclagem. Como alternativa, você pode definir o escopo da proteção para os branches atuais e futuros que correspondem a um padrão especificado. Como parte da configuração de proteção, você pode aplicar as seguintes políticas de branch:

• Exigir um número mínimo de revisores: garante que as alterações não possam ser mescladas sem o número necessário de aprovações.
• Verificar se há itens de trabalho vinculados: incentiva a rastreabilidade verificando itens vinculados em solicitações de pull
• Verifique se há resolução de comentários: verifica se todos os comentários foram resolvidos em solicitações de pull
• Limitar tipos de mesclagem: controla o histórico do branch limitando os tipos disponíveis de mesclagem quando as solicitações de pull são concluídas. Isso inclui a opção de habilitar ou desabilitar seletivamente os seguintes tipos de mesclagem:
  • Mesclagem básica (sem avanço rápido): preserva a história exatamente como aconteceu durante o desenvolvimento.
  • Rebase e avanço rápido: cria um histórico linear reproduzindo as confirmações do branch de origem no destino sem uma confirmação de mesclagem.
  • squash merge: Cria um histórico linear ao condensar os commits do branch de origem em um único novo commit no branch de destino.
  • Fazer rebase com um commit de mesclagem: Cria um histórico semi-linear ao reproduzir os commits do branch de origem no destino e, em seguida, criar um commit de mesclagem.

Opcionalmente, você pode configurar as seguintes restrições:

• Validação de compilação: valida o código por meio da pré-mesclagem e construção das alterações de pull request.
• Verificações de status: exigem que outros serviços publiquem um status bem-sucedido para concluir solicitações de pull. As verificações de status são tarefas automatizadas disparadas durante o processo de solicitação de pull para verificar determinados critérios antes de permitir que a solicitação de pull seja mesclada no branch de destino. No Azure DevOps, as verificações de status são associadas a pipelines de build e pipelines de lançamento.
• incluir automaticamente revisores: designar revisores de código para incluir automaticamente quando solicitações de pull alterarem determinadas áreas de código.

Você também tem a opção de bloquear um branch, deixando-o efetivamente somente para leitura.

Observe que o Azure DevOps fornece duas opções para ignorar os requisitos de política para um repositório. Para implementá-los, você precisa alterar a configuração de segurança padrão do repositório definindo as permissões para executar as seguintes ações para Permitir:

• Ignorar políticas ao concluir solicitações de pull.
• Ignorar políticas ao realizar um push.

É essencial garantir que essas permissões sejam concedidas somente a indivíduos designados que entendam as implicações dessas ações sobre a conformidade com os padrões organizacionais e possam exercer um bom julgamento em relação ao seu uso.

GitHub

No GitHub, você pode implementar restrições de integração de branches usando regras de proteção de branches. As regras de proteção de branch definem se os colaboradores podem excluir ou forçar push para o branch e definir requisitos para quaisquer pushes para o branch, como passar verificações de status ou um histórico de confirmação linear. Assim como no Azure DevOps, você pode aplicá-los a ramificações específicas com base na correspondência de padrão de nome.

Para implementar regras de proteção de ramificação, navegue até o repositório na interface web do GitHub, na guia Configurações e, na navegação, selecione o item de menu Branches. Isso permitirá que você acesse a configuração das regras de Proteção de Ramificação. Como parte da configuração de proteção, você pode aplicar as seguintes regras:

• Exigir uma solicitação de pull antes da mesclagem: requer que os colaboradores enviem solicitações de pull para revisão e aprovação antes de mesclar suas alterações.
• Exigir que as verificações de status sejam aprovadas antes da mesclagem: designa verificações de status que devem ser aprovadas antes de permitir mesclagens. Quando habilitado, os commits devem primeiro ser enviados por push para outro branch e, em seguida, mesclados ou enviados diretamente para um branch que corresponda a esta regra, depois que as verificações de status tiverem sido concluídas com sucesso.
• Exigir resolução de conversa antes da mesclagem: garante que todas as discussões e comentários relacionados a alterações de código sejam resolvidos antes de mesclar solicitações de pull.
• Exigir confirmações assinadas: mandatos que confirmam envio por push para branches protegidos são assinados com assinaturas verificadas, aumentando a segurança e garantindo a autenticidade das contribuições de código.
• Exigir histórico linear: impede confirmações de mesclagem em branches protegidos, impondo um histórico linear, o que facilita o controle e, se necessário, inverte as alterações. Isso significa efetivamente que todas as solicitações de pull devem usar uma mesclagem de squash ou uma mesclagem de rebase.
• Exigir que as implantações tenham êxito antes da mesclagem: determina que as alterações propostas nas solicitações de pull sejam completamente testadas e validadas antes de serem integradas à base de código.
• Branch de bloqueio: assim como seu equivalente no Azure DevOps, restringe o acesso de gravação ao branch, tornando-o somente leitura.
• Não permitir a ignorância das configurações acima: elimina a possibilidade de as outras regras serem ignoradas por administradores e usuários que receberam a permissão para ignorar as proteções de branch.
• Permitir pushes de força: permitir que os usuários com privilégios de push forcem as alterações por push. Assim como acontece com o Azure DevOps, isso significa apenas como uma medida de emergência.
• Permitir exclusões: permite que usuários com privilégios de push excluam branches protegidas. Embora essa flexibilidade possa simplificar o gerenciamento de branch, ela também representa um risco de exclusões de branch acidentais ou mal-intencionadas e deve ser cuidadosamente controlada para evitar a perda de dados e manter a integridade do repositório.