APRENDER. PRATICAR. EVOLUIR.1. Partir de uma pergunta operacional concreta
Durante um incidente fictício, RUN pergunta que versão chegou a produção e que pedido a justificava. A resposta não deve depender de alguém recordar o nome da release. Desenha as relações entre work item, alteração de código, execução de build, artefacto e deployment no destino. Cada relação precisa de uma referência recuperável. O topo atual de uma branch pode ser posterior ao build; o nome da release pode ter sido reutilizado. No exercício, duas equipas usam o mesmo nome, mas reconstruíram o pacote em momentos diferentes. O gestor pede a referência efetivamente consumida e a execução que a produziu. Esta cadeia apoia investigação e decisão de recuperação. Não demonstra, sozinha, que o conteúdo era correto, que a autorização era válida ou que o serviço cumpriu os critérios funcionais.
2. Criar ligações observáveis entre Boards e GitHub
A integração configurada ainda precisa de referências nos campos suportados. Uma menção AB# na descrição do PR pode criar a ligação ao work item; colocá-la apenas no título ou num comentário não tem o mesmo efeito. O exercício usa um número fictício e pede que se confirme a ligação no destino. Se estiver ausente, começa por verificar configuração, localização da referência e permissões relevantes, preservando o histórico da tentativa. Distingue também ligação de transição de estado. Integrar numa branch de release diferente da default não satisfaz a condição documentada para a transição automática. Evita fechar o ticket apenas para tornar o dashboard favorável. O estado deve representar a regra de conclusão acordada e a evidência disponível. Uma relação de rastreabilidade não substitui a aceitação da alteração.
3. Usar a evidência adequada à tecnologia da pipeline
Ao migrar Classic releases para YAML, não pressuponhas que todos os controlos de interface conservam a mesma função. O controlo Deployment no work item depende da integração de release clássica e não suporta stages YAML. No cenário, o campo vazio leva a uma conclusão errada de que a mudança não chegou ao destino. Para YAML, consulta o histórico dos environments visados por deployment jobs e segue a execução relevante. Confirma também o artefacto consumido e a observação da aplicação. Um deployment registado descreve uma execução; um ensaio funcional descreve o resultado do serviço. Podem ser necessárias ambas as evidências. Atualiza o runbook de suporte quando mudares de tecnologia, incluindo onde encontrar informação, que permissões são necessárias e como investigar uma lacuna sem repetir imediatamente a alteração.
4. Rever notas geradas antes do handover
Notas geradas a partir de Git ajudam a reunir alterações, mas dependem do intervalo de comparação e de filtros. Uma label excluída pode retirar do texto um PR que continua presente no pacote. No exercício, maintenance esconde uma mudança de configuração relevante para RUN. Revê os limites da comparação, o conteúdo incluído e o impacto operacional que precisa de explicação humana. Documenta passos manuais, efeitos nos dados e limitações quando existirem. A nota deve apontar para a versão entregue, sem prometer que a geração automática verificou a aplicação. Também conserva a evidência necessária durante o período acordado: apagar uma execução pode remover os seus pipeline artifacts. O plano de retenção deve permitir investigar e recuperar as versões relevantes, respeitando as regras de dados aplicáveis ao projeto fictício.
5. Definir a população antes de comparar métricas
Um gráfico de tempos representa itens selecionados por equipa, tipo, filtros e período. Antes de anunciar melhoria, confirma que comparas trabalho suficientemente semelhante e que os estados foram atualizados de forma coerente. No exemplo, defeitos urgentes pequenos são comparados com features grandes do trimestre anterior. A diferença observada pode refletir composição da amostra. O relatório deve apresentar essa limitação, contagens e a pergunta que a métrica ajuda a responder. Outro gráfico mostra média baixa nos itens concluídos, enquanto trabalho antigo continua aberto. A média não incorpora automaticamente esse risco. Acrescenta observação da idade e dos bloqueios do trabalho pendente. Não transformes um valor descritivo numa promessa individual de entrega. Usa-o para investigar o processo e discutir decisões com quem conhece as restrições de execução.
6. Investigar acumulação antes de iniciar mais trabalho
Num modelo fictício sem reaberturas, cancelamentos ou mudança de âmbito, a fila começa com onze itens. Entram oito e saem cinco por dia. Ao fim de quatro dias, existem vinte e três itens à espera. A conta descreve acumulação; não prova que falta uma pessoa específica nem que todos os itens têm o mesmo esforço. Um diagrama de fluxo cumulativo ajuda a observar distribuição por estados e alterações ao longo do tempo, desde que o quadro represente o trabalho real. O PM deve investigar bloqueios, critérios de validação, dependências e capacidade com os responsáveis. Aumentar entradas sem compreender a restrição pode aumentar espera. Se houver itens urgentes, explicita a decisão de prioridade e os efeitos sobre os restantes, em vez de esconder a fila através de mudanças artificiais de estado.
7. Tratar notificações como um percurso com falhas
Um service hook pode ficar restringido após falhas e perder eventos novos durante probation. Ver eventos recentes depois de recuperar não demonstra que o intervalo anterior ficou completo. Compara o sistema de origem com o consumidor e define como reconstruir lacunas de forma controlada. Noutro exemplo, um recetor GitHub faz um relatório demorado antes de responder. Separa receção validada de processamento, usando uma fila adequada para preservar o trabalho aceite. Um reenvio pode representar a mesma entrega, pelo que o consumidor precisa de reconhecer a identidade e evitar efeitos duplicados. Esta decisão de desenho não é uma promessa de processamento exatamente uma vez. Regista também tipo e ação do evento, resultado da validação e falhas de processamento. A equipa de suporte precisa de distinguir ausência de evento, falha de transporte e falha no consumidor.
8. Ensaiar a investigação que RUN terá de executar
Entrega à equipa um incidente fictício com uma referência de deployment, um artefacto e um work item. Pede que identifique a versão, encontre a evidência e explique se consegue decidir uma recuperação. O modelo Python abaixo só compara campos de registos fornecidos: não autentica a origem, não consulta Azure ou GitHub e não verifica bytes de um pacote. Uma correspondência no modelo significa coerência dessas relações, não aceitação funcional. Introduz depois uma referência errada e observa se o aluno a deteta sem consultar o nome da release. Esta progressão vai da cadeia correta para uma lacuna concreta e, finalmente, para a decisão durante incidente. Na prática, regista o que falta no handover, quem corrige e que ensaio demonstra autonomia. O objetivo é tornar a investigação repetível também fora de horas.
# Fictional record-consistency model; no API calls, authentication or byte verification.
def consistent(change, build, artifact, deployment):
required = [(change, ("id", "commit", "target")),
(build, ("id", "commit")),
(artifact, ("id", "buildId")),
(deployment, ("artifactId", "target", "status"))]
if any(not record.get(key) for record, keys in required for key in keys):
return False
return (change["commit"] == build["commit"]
and artifact["buildId"] == build["id"]
and deployment["artifactId"] == artifact["id"]
and deployment["target"] == change["target"]
and deployment["status"] == "succeeded")
change = {"id": "CH-42", "commit": "commit-A", "target": "prod"}
build = {"id": "build-17", "commit": "commit-A"}
artifact = {"id": "artifact-A", "buildId": "build-17"}
deploy = {"artifactId": "artifact-A", "target": "prod", "status": "succeeded"}
assert consistent(change, build, artifact, deploy)
assert not consistent(change, {**build, "commit": "commit-B"}, artifact, deploy)
assert not consistent(change, build, {**artifact, "buildId": "build-18"}, deploy)
assert not consistent(change, build, artifact, {**deploy, "artifactId": "artifact-B"})
assert not consistent(change, build, artifact, {**deploy, "target": "qa"})
assert not consistent(change, build, artifact, {**deploy, "status": "failed"})
assert not consistent(change, build, artifact, {**deploy, "artifactId": ""})
assert consistent(change, build, artifact, {**deploy, "releaseName": "another-label"})
print("eight fictional traceability checks passed")
Duas releases chamadas October-Fix usam artefactos diferentes. O exercício compara change.commit, build.commit, artifact.buildId e deployment.artifactId para identificar a ligação incorreta. Os identificadores são fictícios.
Armadilhas comuns
Confundir PR ligado com mudança aceite; tratar campo clássico vazio como prova sobre YAML; comparar populações diferentes; ignorar trabalho aberto; aceitar recuperação de notificações como reconstrução do histórico.
Tópicos relacionados: Proveniência de artefactos · Gestão de incidentes · Métricas de fluxo · Integração por eventos
A rastreabilidade precisa de relações recuperáveis e a medição precisa de uma população definida. Verifica o que foi entregue e o que ainda falta, antes de decidir a próxima alteração.
Referência: Link GitHub commits and pull requests to Azure Boards work items · AZ-400 objectives 2026-07-27