Microsoft AZ-400: Controle de Código-Fonte e Gerenciamento de Repositórios — Guia de estudos

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

As práticas modernas de DevOps dependem de um controle de código-fonte previsível e colaborativo e de um gerenciamento de repositórios disciplinado. O Azure Repos e o GitHub fornecem recursos complementares para controle de versão, aplicação de políticas, colaboração e segurança. O domínio de estratégias de branching, fluxos de trabalho de pull request, permissões, hooks, manipulação de arquivos grandes, padrões de migração, varredura de segurança e versionamento é essencial para pipelines de entrega resilientes e auditabilidade. O objetivo não é apenas armazenar código, mas criar um sistema de controles automatizado e aplicável que dimensione a produtividade da equipe sem sacrificar a qualidade.

Fundamentos de Controle de Código-Fonte no Azure Repos e GitHub

O Azure Repos suporta Git e Team Foundation Version Control (TFVC). O Git é distribuído, permite commits locais, branching fácil e fluxos de trabalho descentralizados. O TFVC é centralizado com versionamento no lado do servidor, check-outs bloqueados (opcional) e é adequado para soluções legadas com ativos binários muito grandes ou equipes treinadas em fluxos de trabalho centralizados. O desenvolvimento de novos projetos deve usar o Git como padrão; o TFVC continua viável quando o controle de alterações incremental e as permissões centrais são primordiais e o custo de migração é proibitivo.

Escolha uma estratégia de branching deliberadamente:

O desenvolvimento baseado em tronco (trunk-based) favorece um único branch main de longa duração com feature branches de vida muito curta e integração contínua. Isso acelera o fluxo, reduz a dívida de merges e é ideal para equipes de alta cadência com forte automação de testes.
O GitFlow usa branches develop e main (release) de longa duração, com branches de feature, release e hotfix. Ele é adequado para produtos com ciclos de lançamento formais (release trains) e necessidades de backporting, mas adiciona uma sobrecarga de coordenação.
O GitHub Flow é um modelo simplificado com um único branch main, branches de tópico de curta duração, implantação contínua e releases frequentes. É eficaz para serviços que são entregues continuamente.

Monorepo versus multi-repo é principalmente uma escolha organizacional e de ferramentas:

Monorepo consolida muitos componentes em um único repositório, facilitando alterações atômicas entre serviços, refatoração unificada e ferramentas compartilhadas. Ele pode sobrecarregar as operações do Git à medida que o histórico cresce. As técnicas de mitigação incluem sparse checkout, partial clone e filtros de caminho na CI para delimitar builds e testes.
Multi-repo isola os limites de propriedade, histórico e permissão, facilitando o versionamento e a retenção independentes. Ele pode aumentar a coordenação entre repositórios e o desvio de dependências (dependency drift); submódulos ou gerenciadores de dependência e orquestração de releases são críticos.

A propriedade e o roteamento de alterações se beneficiam de declarações de propriedade de código. O arquivo CODEOWNERS do GitHub mapeia caminhos para revisores obrigatórios automaticamente. No Azure Repos, use revisores obrigatórios baseados em caminho nas políticas de branch (e CODEOWNERS, quando habilitado) para rotear as revisões para as equipes de componentes. Complemente a propriedade com convenções de nomenclatura de branches, mensagens de commit claras (por exemplo, Conventional Commits) e templates de repositório para consistência.

Governança: Políticas, Permissões e Pull Requests

As políticas de branch (branch policies) no Azure Repos codificam os portões de qualidade (quality gates):

Revisores obrigatórios impõem uma contagem mínima de revisores e podem incluir indivíduos/grupos específicos ou revisores automáticos baseados em caminho. Exija a resolução de comentários para garantir que o feedback substantivo seja tratado antes do merge.
A validação de build exige que um ou mais pipelines de CI sejam aprovados antes do merge. Use filtros de caminho para evitar builds desnecessários e defina o acionamento automático em novas atualizações. Integre verificações externas por meio de políticas de status para varreduras de segurança ou testes de desempenho.
As estratégias de merge podem ser restringidas: Merge (no fast-forward) registra o histórico de merge; Squash condensa as alterações em um único commit, mantendo o histórico linear; Rebase e fast-forward reescreve o branch de tópico sobre o main para um histórico em linha reta; Rebase e merge reaplica os commits e preserva commits separados sem um commit de merge. Alinhe a estratégia com as necessidades de auditoria e as ferramentas downstream.
Verificações adicionais incluem itens de trabalho vinculados obrigatórios, um número mínimo de votos de aprovação e o bloqueio se houver comentários ativos ou revisores pendentes.

Os pull requests orquestram a conversa de integração:

PRs em rascunho (Draft PRs) sinalizam trabalho em andamento e bloqueiam a conclusão até serem marcados como prontos. Incentive o feedback antecipado sem acionar as políticas prematuramente.
O Auto-complete faz o merge automaticamente assim que todas as políticas são aprovadas, reduzindo a latência de coordenação e aumentando o fluxo.
A opção de contornar políticas (Bypass policies) existe para situações de emergência ou contas de automação. Restrinja isso com a permissão “Bypass policies when completing pull requests” e audite por meio de aprovações e gerenciamento de mudanças.
Templates de PR padronizam o contexto: evidências de teste, notas de risco, etapas de implantação e plano de roll-back. No Azure Repos, coloque o pull_request_template.md na raiz do repositório ou em .azuredevops/. Forneça checklists para segurança, desempenho e documentação.

Permissões e branches protegidos são sua última linha de defesa:

Use os grupos RBAC do Azure DevOps (Project Administrators, Contributors, Readers) e permissões de repositório refinadas (Create branch, Create tag, Contribute, Force push, Manage permissions, Bypass policies). Prefira aplicar allow/deny em grupos em vez de indivíduos.
Proteja os branches main e de release negando Force push e Delete, limitando a permissão Contribute apenas para merges de PR e habilitando políticas de branch que exigem builds e revisões. Considere usar o “Lock” para congelar temporariamente as alterações.
Use permissões no nível do branch para restringir quem pode criar ou concluir PRs em branches sensíveis e separe as responsabilidades entre desenvolvedores e gerentes de release.

Automação, Hooks, Arquivos Grandes e Segurança

Os hooks do Git reforçam a qualidade nas pontas do processo:

Hooks de pre-commit aplicam localmente linting, formatação, verificação de segredos e testes unitários antes que um desenvolvedor registre um commit. Mantenha-os rápidos e determinísticos.
Hooks de pre-push bloqueiam o push de código que falha em testes de integração ou verificações de política. Forneça scripts de hook para toda a equipe por meio de ferramentas (por exemplo, Husky para JavaScript) e documente a adesão opcional (opt-in).
Hooks do lado do servidor (server-side) em serviços gerenciados diferem: o GitHub suporta webhooks de servidor e verificações de status obrigatórias (required status checks); o Azure DevOps Services não permite hooks personalizados do lado do servidor, mas suporta políticas de branch (branch policies), validações de build, service hooks e verificações de status de sistemas externos. No Azure DevOps Server (on-prem), os hooks de servidor são possíveis.

O Large File Storage (Git LFS) armazena binários grandes fora do banco de dados de objetos do Git, mantendo o repositório com bom desempenho:

Rastreie padrões com

undefined

ou tipos de arquivos binários específicos. Commite o arquivo .gitattributes para que todos os contribuidores apliquem o LFS de forma consistente.

Migre o histórico executando

undefined

com filtros de caminho para reescrever binários grandes como ponteiros. Coordene com a equipe e pause os pushes; faça force-push com cautela e atualize os clones.

Gerencie a largura de banda evitando o “smudging” desnecessário. Use

undefined

e execute

undefined

seletivamente. Faça cache do LFS na CI e considere usar repositórios de artefatos para binários que não precisam residir no Git.

A garantia de segurança deve seguir a abordagem shift-left e ser baseada em políticas:

O GitHub Advanced Security (GHAS) oferece varredura de segredos (secret scanning), incluindo proteção de push (push protection), varredura de código (code scanning) com CodeQL e revisão de dependências (dependency review) para detectar credenciais expostas, vulnerabilidades de código e riscos na cadeia de suprimentos (supply-chain). Aplique-os como verificações obrigatórias em PRs. Para o Azure Repos, use o Advanced Security for Azure DevOps para obter varredura de segredos, SAST via CodeQL e insights de dependência semelhantes.
A varredura de segredos (secret scanning) deve ser configurada para bloquear pushes com segredos de alta confiança e alertar os responsáveis pela segurança. Suporte detectores personalizados para padrões específicos da organização.
A varredura de código com CodeQL (CodeQL code scanning) deve ser executada nos gatilhos (triggers)

undefined

, fazendo o upload dos resultados SARIF como verificações de status. Ajuste os pacotes de consulta (query packs) para reduzir o ruído e garantir a cobertura em caminhos críticos.

A revisão de dependências (dependency review) expõe mudanças de versão e avisos de segurança conhecidos durante a revisão de PRs; use isso para SLAs de remediação e governança de licenças.

Migração, Versionamento e Gerenciamento de Release

Migrar do TFVC para o Git exige uma estratégia e ferramentas alinhadas à tolerância ao risco:

Para uma migração de alta fidelidade com histórico profundo e vinculação de itens de trabalho, use o git-tfs para clonar os caminhos do TFVC para o Git, preservando os changesets e mapeando os usuários. Particione por aplicação ou branch para manter os repositórios Git gerenciáveis. Limpe binários grandes com o LFS durante ou após a migração.
Para uma migração leve do estado atual, use a ferramenta de Importação do Azure DevOps para iniciar um novo repositório Git a partir do TFVC (ou de outro host Git), opcionalmente limitando o histórico. Isso reduz a duração e o risco, mas sacrifica a granularidade histórica profunda.
Preserve a rastreabilidade migrando tags/labels, mapeando branches do TFVC para branches do Git e mantendo um espelho somente leitura do TFVC para auditoria. Valide com um piloto, congele o código-fonte durante a transição (cutover) e execute uma matriz de verificação (builds, testes e deploy).

Adote o versionamento semântico para clareza e automação:

Use o SemVer 2.0.0: MAJOR.MINOR.PATCH com pré-lançamento (pre-release) opcional (ex: -rc.1) e metadados de build (+build.45). Faça o tag das releases com tags anotadas (git tag -a v1.4.2 -m “Release 1.4.2”) e assine as tags para auditoria.
Automatize os incrementos de versão no CI/CD:
- Derive a versão a partir dos commits com Conventional Commits e uma ferramenta de release (ex: GitVersion ou semantic-release) para calcular a próxima versão com base nos tipos e escopos dos commits.
- Atualize os números de build e as versões dos pacotes automaticamente; falhe o build se ocorrerem desvios de versão (version drift) ou conflitos de tag.
Alinhe o versionamento com a estratégia de branching:
- Trunk-based: a branch main está sempre pronta para release; crie tags de release a partir da main; use branches de release de curta duração apenas para estabilização.
- GitFlow: branches release/* carregam uma versão minor congelada; crie a branch hotfix/* a partir da main para patches urgentes; faça o merge de volta para develop e main e crie a tag na conclusão do merge.
- GitHub Flow: faça o tag da main no deploy; use tags de pré-release para canaries.

Integre a automação de release com as políticas de repositório: exija builds bem-sucedidos (green builds) com pipelines de release, bloqueie merges sem changelogs atualizados gerados a partir dos commits e exija commits/tags assinados em ambientes regulados.

Cenário de Problema Prático

A Starbucks precisa consolidar várias aplicações legadas gerenciadas no TFVC para o Azure Repos Git, estabelecendo governança uniforme, varredura de segurança e fluxos de trabalho escaláveis tanto para serviços quanto para aplicativos móveis.

Escolher a topologia de repositório e a estratégia de branching

Ação: Adotar o desenvolvimento baseado em trunk (trunk-based) com um monorepo para bibliotecas compartilhadas e alguns repositórios de serviço focados para serviços lançados de forma independente. Habilitar o sparse checkout para o monorepo em scripts de onboarding de desenvolvedores.
Por quê: O trunk-based reduz a dívida de merge e acelera a integração; o monorepo centraliza o código compartilhado e permite refatorações atômicas, enquanto o sparse checkout evita a sobrecarga do histórico completo e da árvore de trabalho (working tree) para equipes que tocam apenas em subconjuntos.

Migrar projetos do TFVC para o Git com preservação do histórico onde isso agrega valor

Ação: Usar o git-tfs para migrar as bases de código principais da web e mobile com histórico completo, mapeando os caminhos de ativos grandes para o Git LFS durante a migração. Para utilitários pequenos, usar a ferramenta de Importação do Azure DevOps para trazer apenas o estado atual.
Por quê: O git-tfs preserva a rastreabilidade crítica para as aplicações principais (flagship apps); o uso seletivo da ferramenta de Importação acelera as migrações de baixo risco e reduz a duração do projeto.

Estabelecer branches protegidas e políticas de branch

Ação: Proteger as branches main e release/* com a negação de Force push/Delete; exigir dois revisores, resolver todos os comentários, vincular um item de trabalho e passar na validação de build com filtros de caminho (path filters). Restringir os merges para Squash nos repositórios de serviço e para Rebase com fast-forward no monorepo para manter um histórico linear. Desabilitar a opção “Ignorar políticas” (Bypass policies) exceto para um pequeno grupo de engenharia de release.
Por quê: A política como código (Policy-as-code) fortalece os portões de qualidade (quality gates) e a auditabilidade. As estratégias de merge refletem as preferências da equipe: o Squash simplifica o revert e o cherry-pick para os serviços; o histórico linear no monorepo acelera as operações de blame e bisect.

Padronizar a prática de pull requests

Ação: Adicionar o arquivo pull_request_template.md em .azuredevops/ com seções para risco, evidência de teste, impacto no desempenho e rollback. Incentivar o uso de Draft PRs desde o início; habilitar o Auto-complete em todos os PRs. Configurar revisores obrigatórios baseados em caminho (path-based) para emular a propriedade do código (code ownership) e adicionar o arquivo CODEOWNERS para repositórios hospedados no GitHub.
Por quê: Os templates elevam o nível mínimo da qualidade da revisão; os Draft PRs promovem a colaboração antecipada; o Auto-complete elimina o tempo ocioso; o roteamento por propriedade (ownership routing) direciona os revisores certos para os diffs certos.

Implementar hooks e gates de CI

Ação: Distribuir hooks de pre-commit/pre-push através das ferramentas do repositório para impor linting, verificação de segredos e testes unitários; manter a execução rápida. Usar a validação de build do Azure Pipelines como a imposição canônica e adicionar verificações de status (status checks) de scanners de segurança. Evitar hooks personalizados do lado do servidor; usar service hooks para notificar sistemas externos.
Por quê: Os hooks locais detectam problemas cedo sem bloquear a colaboração; a imposição do lado do servidor no Azure DevOps é melhor alcançada com políticas de branch e verificações de status para confiabilidade e auditoria.

Gerenciar ativos grandes com Git LFS

Ação: Rastrear padrões de binários (imagens, ativos de design, mídia de teste) com git lfs track; migrar binários legados com git lfs migrate import. Configurar o CI para definir GIT_LFS_SKIP_SMUDGE=1 e buscar seletivamente para reduzir a largura de banda; fazer cache dos artefatos LFS nos agentes de build.
Por quê: Mantém os repositórios rápidos e evita o uso excessivo de rede, ao mesmo tempo que mantém builds reproduzíveis.

Integrar o Advanced Security

Ação: Habilitar o GitHub Advanced Security em repositórios GitHub e o Advanced Security for Azure DevOps no Azure Repos. Ativar a varredura de segredos com proteção de push, executar o CodeQL em PRs e diariamente (nightly), e habilitar as verificações de revisão de dependência. Bloquear a conclusão de PRs em caso de descobertas de alta severidade.
Por quê: Desloca a segurança para a esquerda (shifts security left), prevenindo que vazamentos de credenciais e padrões exploráveis entrem na branch main, com insights acionáveis durante a revisão.

Automatizar o versionamento semântico e o tagueamento

Ação: Usar o GitVersion no Azure Pipelines para calcular o SemVer a partir do histórico de branches e commits; assinar e enviar (push) tags anotadas nos pipelines de release; gerar notas de release a partir dos Conventional Commits. Usar branches release/* apenas para estabilização; fazer hotfix a partir da main tagueada.
Por quê: Versões determinísticas e automatizadas melhoram a rastreabilidade e a reprodutibilidade do deploy, e tags assinadas dão suporte à conformidade (compliance).

Esta sequência reduz o risco da migração, impõe qualidade e segurança consistentes e otimiza a entrega — alinhando precisamente o gerenciamento de repositórios com operações de DevOps escaláveis.

Todos os domínios · Pipelines de CI →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →