No exame AZ-400, a seção de controle de código-fonte pergunta como as equipes dividem, mesclam e protegem o código. Abrange critérios de escolha de estratégia de branching, configuração de políticas de Pull Request e diferenças entre plataformas de repositórios. Uma estratégia de branching errada pode desencadear uma crise no deploy; uma política de PR ausente pode deixar uma vulnerabilidade entrar na main. O controle de código-fonte é a base de todo pipeline DevOps.
Estratégias de Branching: O Projeto de Como as Equipes Colaboram
Imagine duas pessoas tentando pegar o mesmo livro na biblioteca ao mesmo tempo — sem um sistema de empréstimo claro, o conflito é inevitável. O código-fonte enfrenta o mesmo problema: quando vários desenvolvedores modificam o mesmo arquivo, os conflitos de merge se acumulam. Uma estratégia de branching é o sistema acordado pela equipe para minimizar essas colisões.
usa cinco tipos de branches: , , , e . Adequado para equipes com ciclos de lançamento definidos que mantêm várias versões ativas, como aplicativos móveis que suportam diferentes versões de SO. A desvantagem é a complexidade: muitos branches de longa duração dificultam CI/CD.
usa apenas e branches de curta duração. O desenvolvedor abre um Pull Request e mescla na main após revisão. Rápido e simples, ideal para equipes pequenas com deploys frequentes.
faz todos os desenvolvedores comitar diretamente na várias vezes ao dia. Os branches são tão efêmeros que conflitos de merge raramente se acumulam. O habilitador essencial são as Feature Flags: funcionalidades incompletas são entregues ocultas atrás de um toggle. No exame AZ-400, 'ciclo de lançamento rápido' ou 'integração profunda com CI' aponta para TBD.
é a estratégia interna da Microsoft — as equipes criam branches da main, fazem deploy a partir deles e aplicam hotfixes via cherry-pick. O próprio Azure DevOps usa essa abordagem.
| Estratégia | Branches | Cadência | Tamanho | |------------|----------|----------|---------| | GitFlow | Alta | Periódica | Médio–Grande | | GitHub Flow | Baixa | Contínua | Pequeno–Médio | | Trunk-Based | Mínima | Integração contínua | Qualquer | | Release Flow | Média | Por sprint | Grande |
Proteção de Branches: Manter a main Segura
Um cofre bancário combina fechadura, leitor biométrico e segurança — não depende de um único cadeado. O branch merece a mesma defesa. Se qualquer pessoa pode fazer push direto na main, um erro ou commit malicioso chega à produção imediatamente. A proteção de branches impõe condições que devem ser atendidas antes que qualquer PR seja mesclado.
No Azure Repos, define as regras para branches protegidos.
: N aprovações obrigatórias : pipeline deve passar antes da mesclagem : vinculação ao Azure Boards obrigatória : restringe a Squash, Rebase ou Merge commit Desativar para evitar autoaprovação
As do GitHub oferecem controles equivalentes.
: aprovação de revisores obrigatória : CI deve estar verde : limita push direto : apenas commits assinados com GPG
Ambas bloqueiam force-push e exclusão de branches protegidos por padrão.
Políticas de Pull Request e CODEOWNERS
Em um set de filmagem, o diretor não é a única autoridade — o diretor de fotografia cuida de cada enquadramento, o designer de som de cada detalhe auditivo. As revisões de código funcionam assim: ninguém revisa significativamente cada arquivo de um repositório grande. declara quem é responsável por cada parte do código.
Coloque um arquivo em (GitHub) ou na raiz do repositório (Azure DevOps) e mapeie caminhos para donos.
Quando um PR toca um caminho listado, os proprietários são adicionados automaticamente como revisores. Ativar impede a mesclagem sem sua aprovação. O Azure Repos oferece o mesmo via na Branch Policy.
A estratégia de mesclagem também importa para manter o histórico limpo.
: preserva todo o histórico do branch feature na main : comprime todos os commits em um único na main — escolher quando o histórico do PR é ruidoso : reaplica commits sobre a main, produzindo histórico linear
'Histórico de PR bagunçado' ou 'manter main limpa' no exame AZ-400 significa Squash merge.
Estrutura do Repositório e Arquivos Git
Um shopping reúne tudo sob o mesmo teto — conveniente mas complexo. Lojas especializadas são mais simples, mas exigem deslocamento. A estrutura de repositório apresenta o mesmo equilíbrio.
Um abriga todos os serviços e bibliotecas em um único repositório. Compartilhar código é imediato e builds podem ser coordenados em um único pipeline. A desvantagem é o crescimento do repositório e tempos de CI mais longos. Git LFS e sparse-checkout são essenciais para monorepos grandes.
O mantém cada serviço em seu próprio repositório. Autonomia alta e controle de acesso isolado, mas atualizar bibliotecas compartilhadas exige mudanças em cada repositório separadamente.
exclui builds, e do rastreamento Git. define o tratamento por tipo: normalização de quebras de linha () e roteamento Git LFS (). 'Ativos binários aumentando o repositório' no exame aponta para Git LFS e .
Azure Repos vs GitHub: Escolhendo pelo Ecossistema
Escolher entre iOS e Android depende do ecossistema: iOS conecta com outros dispositivos Apple, Android oferece mais opções de hardware. Azure Repos vs GitHub segue a mesma lógica.
| Aspecto | Azure Repos | GitHub | |---------|-------------|--------| | CI/CD nativo | Azure Pipelines | GitHub Actions | | Identidade | Azure AD, políticas de org | GitHub Org, SAML SSO | | On-premises | Azure DevOps Server | GitHub Enterprise Server | | Rastreamento | Azure Boards | GitHub Issues/Projects |
Azure Repos é natural para equipes que já usam Azure Pipelines, Azure Boards e Azure Artifacts. Os pontos fortes do GitHub são a comunidade open-source, GitHub Copilot e o GitHub Actions Marketplace. 'Manter ambiente Azure DevOps' favorece Azure Repos; 'contribuição open-source' ou 'GitHub Actions' favorece GitHub.
!Azure Repos vs GitHub
Resumo do Exame
"CI rápido, branch único, commits de curta duração" -- Trunk-Based Development "Múltiplas versões de lançamento, entrega programada" -- GitFlow "Forçar pipeline de build a passar antes de mesclar PR" -- Build Validation (Branch Policy) "Atribuir revisores automaticamente quando caminhos específicos mudam" -- CODEOWNERS "Comprimir histórico do PR em um único commit na main" -- Squash merge "Bloquear push direto à main no Azure Repos" -- Branch Policy número mínimo de revisores "Impedir force push no GitHub" -- Branch Protection Rule "Gerenciar arquivos binários em monorepo" -- Git LFS + .gitattributes "Excluir artefatos e arquivos de ambiente do rastreamento" -- .gitignore "Repositório integrado ao ecossistema Azure" -- Azure Repos "Contribuição open-source, GitHub Actions Marketplace" -- GitHub "Commits assinados com GPG em branches protegidos" -- Require signed commits
GitFlow = lançamentos periódicos com múltiplas versões, Trunk-Based = integração contínua em branch único, CODEOWNERS = atribuição automática de revisores por caminho.