Organizando o fluxo de desenvolvimento: Ajustes para garantir a movimentação correta entre novas features entre as branches dos ambientes

No Azure DevOps, a restrição direta de que uma branch X só pode receber PR se já passou por outra branch Y (por exemplo: PR de hotfix indo direto para prod, mas exigindo que primeiro passe por desenv) não é uma configuração nativa simples de "marcar uma caixinha".

No entanto, o Azure DevOps possui mecanismos robustos para garantir esse fluxo através de Branch Policies (Políticas de Ramificação), Branch Folders e Build/Validation Pipelines.

Aqui estão as duas principais formas de implementar essa validação:

Abordagem 1: Usando Build Validation com verificação de histórico (Recomendado)

Você pode configurar uma política de validação de compilação/merge que verifica se o commit que está indo para prod já existe na branch desenv.

1.Acesse as Configurações do Repositório:Repositórios.
Branches">
No Azure DevOps, vá em Repos > Branches, localize a sua branch prod, clique nos três pontos (...) e selecione Branch policies.

2.Adicione uma Build Validation:Build Validation.
Role até a seção Build validation e clique no botão + para adicionar uma nova política de build.

3.Crie um Pipeline de Verificação:Pipeline YAML.
Selecione um pipeline (ou crie um novo script YAML) que será executado automaticamente toda vez que um PR for aberto para prod.

4.Adicione o Script de Validação:Script Bash/PowerShell.
No seu pipeline de validação, adicione um comando para checar se a branch de origem contém os commits de desenv ou se o merge já foi feito lá. Por exemplo, no bash:

Bash
# Verifica se a branch desenv é ancestral da branch de origem do PR ou se o commit já existe em desenv
git fetch origin desenv
git merge-base --is-ancestor origin/desenv HEAD || (echo "Erro: O código precisa ser integrado em 'desenv' antes de ir para 'prod'." && exit 1)
Como verificar se funcionou: Tente abrir um PR direto de uma branch de feature para prod sem passar por desenv. O pipeline de validação falhará e bloqueará o botão de "Complete".

Abordagem 2: Fluxo de Branches em Cascata (Git Flow / Branch Control)

Se o seu cenário for o Git Flow tradicional (onde correções urgentes em prod depois precisam voltar para desenv ou vice-versa), a melhor prática de arquitetura do Azure DevOps é usar restrições de permissão ou a política de Branch Control.

  • Bloqueio de Merge Direto: Você pode restringir quem pode dar merge em prod através de permissões avançadas na branch (negando a permissão Contribute ou Bypass policies para desenvolvedores comuns, permitindo apenas para Tech Leads/Service Accounts).

  • Branch Folders: Organizar as branches por pastas (release/*, features/*) ajuda a aplicar políticas em lote.

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Procêmica: A Linguagem Silenciosa do Espaço

Imagem
Você já se sentiu desconfortável em um ambiente lotado, ou percebeu como a disposição das mesas em um restaurante pode influenciar a conversa? Se sim, você já experimentou a procêmica em ação. A procêmica, ou a "linguagem silenciosa do espaço", é um campo de estudo fascinante que explora como usamos o espaço físico ao nosso redor para nos comunicar e interagir. O ABC da Procêmica Distância Interpessoal: Pense na "bolha" invisível que carregamos conosco. O tamanho dessa bolha varia dependendo de quem estamos interagindo e do contexto. Um abraço apertado de um amigo próximo é bem diferente de um aperto de mão formal em uma entrevista de emprego, certo? Territorialidade: Já viu alguém "marcando" seu lugar na biblioteca com uma mochila? Isso é territorialidade em ação! Todos nós temos uma necessidade inata de reivindicar e controlar nosso próprio espaço, seja um canto aconchegante em casa ou uma mesa favorita no café. Orientação: A maneira como nos posicion...
Leia mais

Roadmap do Programador Iniciante: Do Zero ao Primeiro Código

  Fase 1: A Fundação (O Alicerce do Conhecimento) O foco aqui é aprender como o computador "pensa" e não necessariamente em qual linguagem. Passo Tópico Chave O que Aprender Duração Estimada 1.1 Objetivo e Área Defina por que e o que quer construir (Web, Mobile, Jogos, Dados, etc.). 1-2 Dias 1.2 Lógica de Programação A base de tudo. Pensamento algorítmico, variáveis, tipos de dados, operadores, estruturas de controle (If/Else), laços de repetição (For/While). 2-4 Semanas 1.3 Ferramentas Iniciais Instale um editor de código (VS Code é muito popular) e entenda o que é e como funciona um ambiente de desenvolvimento (IDE). 1 Semana Fase 2: O Primeiro Idioma (A Linguagem de Iniciação) Escolha uma linguagem para aplicar a lógica que você aprendeu. A recomendação é começar com Python ou JavaScript por serem amigáveis para iniciantes e muito populares. Passo Tópico Chave O que Aprender Duração Estimada 2.1 Sintaxe Básica Entenda como a sua linguagem escolhida se expressa (como fa...
Leia mais

Usenet: A Rede de Usuários Que Plantou as Sementes da Internet Moderna

Imagem
A Usenet, abreviação de User Network (Rede de Usuários), é uma das redes de computadores mais antigas e um importante precursor da Internet como a conhecemos hoje, especialmente dos fóruns de discussão e comunidades online. Aqui está a história da Usenet: 1. Criação e Primórdios (1979 - Início dos Anos 80) 1979: O Nascimento: A Usenet foi concebida no final de 1979 por dois estudantes da Universidade Duke, Tom Truscott e Jim Ellis , com a ajuda de Steve Bellovin . O objetivo era criar uma forma de comunicação e troca de informações entre computadores de universidades que não faziam parte da ARPANET (a rede de pesquisa militar que foi a precursora direta da Internet, mas era restrita). "A ARPANET dos Pobres": A Usenet era uma alternativa mais acessível à ARPANET, utilizando linhas telefônicas discadas e o protocolo UUCP ( Unix-to-Unix Copy Protocol ), que facilitava a cópia de arquivos entre computadores Unix. Mecanismo de Funcionamento: Em vez de ser uma rede contínua, ...
Leia mais