O exame AZ-400 faz uma pergunta central na seção de colaboração: qual ferramenta conecta a equipe com o menor esforço operacional? O código pode funcionar perfeitamente, mas sem documentação um novo integrante perde dias se orientando. Um deploy bem-sucedido que ninguém sabe retrasa a validação. A regra é simples: use os aplicativos oficiais primeiro e escreva código personalizado só quando necessário.
Escolhendo entre Project Wiki e Published Wiki
Imagine entrar em uma empresa sem nenhum documento de integração, onde cada dúvida vira uma thread no chat. O Azure DevOps Wiki existe para evitar isso, e o exame verifica qual das suas duas variantes você escolheria.
é mais rápido: o Azure DevOps cria um repositório Git dedicado automaticamente. exige que arquivos Markdown sejam confirmados em um repositório do Azure Repos existente antes de ativá-la. Essa pré-condição é a armadilha mais frequente no exame.
| Atributo | Project Wiki | Published Wiki | |----------|-------------|----------------| | Repositório | Repo Git dedicado criado automaticamente | Conectado a um repo do Repos existente | | Início | Imediato | Arquivos Markdown devem ser confirmados primeiro | | Modelo de contribuição | Editor exclusivo de Wiki | Fluxo de trabalho de PR padrão |
Quando o cenário exige contribuições via PR e histórico completo do Git, escolha Published Wiki e confirme os arquivos Markdown primeiro.
A ordem de navegação é controlada por arquivos , um por pasta. Como esse arquivo vive no Git, pipelines podem automatizá-lo. O arrastar e soltar da interface reescreve o mesmo arquivo internamente.
Markdown e Mermaid — Controle de versão de documentos como texto
Com documentação em Word, o Git não gera diff útil e edições simultâneas viram conflito de merge. O Markdown resolve isso: é texto puro, e o Git rastreia cada mudança de linha. GitHub e Azure DevOps renderizam os automaticamente como HTML.
O mesmo vale para diagramas. PNG ou exportação do Visio torna impossível ver o que mudou em um PR. O Mermaid expressa diagramas em sintaxe de texto e é renderizado nativamente pelo GitHub e pelo Azure DevOps Wiki sem plugins. Basta um bloco de código em um arquivo .
Guia de seleção do tipo de diagrama:
Fluxo de processo e ramificações de decisão → Ordenação de mensagens entre sistemas → Transições de estado e estados compostos → Estrutura de classes e herança →
Para publicar Markdown como site estático no GitHub Pages, o Jekyll é a opção nativa: só precisa de e arquivos Markdown, e um push aciona o deploy. Hugo e Gatsby exigem pipeline próprio no GitHub Actions, logo são errados quando o cenário diz .
Service Hooks e GitHub Webhooks — Enviando eventos para sistemas externos
Imagine um deploy falhando às duas da manhã e ninguém descobrindo até o standup. Sem mecanismo de entrega de eventos, é exatamente isso que acontece. Azure DevOps e GitHub oferecem formas de enviar eventos a sistemas externos no momento em que ocorrem.
é o recurso nativo de entrega de eventos do Azure DevOps, configurável pela interface de Project Settings sem código. Suporta mais de trinta tipos de eventos e destinos como Jenkins, Slack, Teams e endpoints HTTP.
| Cenário | Escolha | |---------|----------| | Azure Repos → acionar build no Jenkins | Service Hook with Jenkins | | Azure DevOps → sistema interno personalizado | Service Hooks Web Hooks | | GitHub → serviço externo legado, sem polling | GitHub Webhook |
envia e-mail para pessoas, não para sistemas automatizados. Jenkins não recebe HTTP por e-mail, então assinaturas de e-mail nunca são resposta correta para integração de build. O exame costuma colocar Email Subscription ao lado de Service Hook como distrator.
Quando um alerta do Azure Monitor precisa de transformação de payload antes de chegar a um sistema externo, crie um Logic App e referencie seu endpoint em um Action group. Sem código. Para lógica complexa, use Function App.
Integração com Teams — Aplicativos oficiais em primeiro lugar
Imagine a equipe usando o Microsoft Teams, mas abrindo o portal do Azure DevOps toda vez que precisa ver o status de um pipeline. O aplicativo oficial certo elimina esse atrito. Sempre que um cenário combinar com , o aplicativo oficial é a primeira resposta.
| Aplicativo | Origem | O que entrega | |------------|--------|---------------| | Azure DevOps for Teams | Eventos do Azure DevOps | Atualizações de PR e status de itens de trabalho por canal | | Azure Pipelines for Teams | Azure Pipelines | Assinaturas de sucesso e falha de build e release | | Azure Boards app for Teams | Azure Boards | Notificações de mudança de estado de itens de trabalho | | Microsoft Teams for GitHub | GitHub | PR, issues e resultados de execução de workflows em tempo real |
Quando todos os eventos inundam um canal, adicione um filtro à assinatura existente via . O exame distingue — baixa sobrecarga — de — alta sobrecarga e resposta errada.
Integração Boards–GitHub — O primeiro passo que todos esquecem
Imagine um desenvolvedor fazendo merge de um PR no GitHub enquanto o gerente no Azure Boards não sabe que o item de trabalho está concluído. Alguém atualiza os dois sistemas manualmente. A integração Boards–GitHub elimina esse trabalho duplicado.
A forma oficial é o , instalado pelo GitHub Marketplace. Com ele, digitar em um commit ou PR cria um link bidirecional automaticamente. A autenticação é OAuth.
OAuth versus métodos de autenticação alternativos:
OAuth → autorização delegada de aplicação web (Azure Boards ↔ GitHub) Chave SSH → acesso ao repositório remoto para git clone e push Identidade gerenciada → autenticação entre recursos do Azure, não pode vincular diretamente ao GitHub
Em um modelo ChatOps, o Teams ou Slack torna-se o plano de controle: comandos como e acionam pipelines sem sair da janela de chat. Discussões de PR e revisões de código também são ferramentas de colaboração por si só.
Resumo do Exame
Pré-requisito do Published Wiki -- confirmar arquivos Markdown no Azure Repos primeiro Automatização da ordem de navegação da Wiki -- editar o arquivo PR do GitHub + documentação versionada com Git -- Markdown Diagramas baseados em texto com renderização nativa do GitHub -- Mermaid Visualização de estados compostos -- Mermaid GitHub Pages + Markdown, sem infraestrutura adicional -- Jekyll Azure Repos → acionar build no Jenkins, sem código -- Service Hook with Jenkins Integração com sistema automatizado em vez de e-mail -- Service Hooks (não Email Subscription) GitHub → notificações no Teams, sem código personalizado -- Microsoft Teams for GitHub app Falhas do Azure Pipelines → Teams -- Azure Pipelines for Teams Reduzir ruído de notificações no Teams -- adicionar um Subscription filter Primeiro passo do PR do GitHub ↔ Azure Boards -- instalar Azure Boards app for GitHub (OAuth) Transformação de payload + webhook externo, sem código -- Logic App + Action group