APRENDER. PRATICAR. EVOLUIR.Definir o requisito e o momento da decisão
Uma release fictícia tem dois requisitos diferentes: a janela de mudança tem de estar aberta antes da criação e a aplicação tem de estar pronta antes de receber tráfego. O primeiro valor pode ser conhecido no plano; o segundo pode depender de uma observação posterior. Para cada requisito, regista a origem do valor, quando fica disponível, o comportamento em caso de falha e quem decide uma exceção. Esta tabela torna visível um erro comum: escolher um mecanismo pelo nome, sem verificar se bloqueia a ação pretendida. Os exercícios seguintes usam dados locais pending e ready; não fazem uma sondagem de saúde de um serviço real.
Testar uma precondição conhecida
No primeiro laboratório, a variável window_open tem default=false. O recurso terraform_data.gate inclui lifecycle com uma precondition cuja condition é var.window_open e cuja mensagem explica que a janela do exercício está fechada. O plan terminou com código 1 e não criou ficheiro de state. A observação mostra uma rejeição antes da criação, não um rollback. Num projeto, uma mensagem útil deve indicar o requisito e a ação de correção, sem revelar segredos. Se o valor necessário ainda fosse desconhecido, a equipa teria de registar a avaliação adiada; não poderia classificar o requisito como cumprido só porque a fase de planeamento terminou.
Ler um resultado ainda desconhecido
No segundo laboratório, terraform_data.producer recebe input="pending" e a postcondition exige self.output == "ready". Um consumer usa producer.output. Antes da primeira criação, o plano JSON mostrou output em after_unknown; o plano foi guardado com sucesso. O relatório da equipa deve escrever “pendente de avaliação”, não “aprovado” nem “ausente”. Esta distinção interessa a quem produz dashboards a partir do JSON: ler apenas after perde informação. Pede ao formando que desenhe a dependência producer→consumer e identifique a primeira fase em que a comparação pode ser decidida. O valor configurado como input e o output ainda calculado têm papéis diferentes no plano observado.
Inspecionar o que ficou depois da falha
Ao aplicar o plano guardado, a postcondition falhou e o comando terminou com código 1. O state continha producer com output=pending; consumer não tinha sido criado. Assim, a falha bloqueou o dependente e deixou uma alteração anterior persistente. Num incidente real, conserva logs, contexto da execução e observação atual antes de retomar. Confirma recursos e associações, identifica a causa do requisito falhado e revê o novo plano completo. Restaurar um state antigo não desfaz infraestrutura. Também não convém remover a condição para obter um resultado verde sem tratar a exigência que ela representa. O gestor deve comunicar o estado parcial e a próxima decisão, em vez de prometer uma reversão que não observou.
Separar aviso de autorização de promoção
O terceiro laboratório usa um check que compara signal.output com ready. O recurso recebeu pending; o apply terminou com código 0, apresentou aviso de falha da assertion e deixou o recurso no state. Isto permite uma pergunta de operação: a regra do exercício exige ready=true antes de abrir tráfego; que parte da pipeline aplica essa regra? Um aviso guardado num log não é esse controlo. Mantém a promoção pendente e obtém a evidência necessária ou uma exceção autorizada quando a política a permitir. Um check local também descreve uma observação naquele momento. Um resultado de manhã não comprova a situação à tarde sem nova observação ou monitorização efetivamente configurada.
Exercício de passagem à operação e resumo
Entrega ao colega três registos: precondition conhecida com plan=1 e sem criação; postcondition adiada com apply=1 e produtor persistente; check falso com apply=0 e aviso. Pede-lhe que explique o que aconteceu, o que ainda falta e quem deve decidir o próximo passo. O runner local guarda estas observações, a versão e o hash do artefacto em evidence.json. Os resultados não validam providers cloud, importação, locking remoto ou recuperação de bases de dados. Antes de transportar o padrão para uma aplicação real, acrescenta esses testes no ambiente autorizado. Resumo: desconhecido não é aprovado; falha não garante reversão; sucesso do comando não substitui aceitação funcional. Relaciona esta aula com planos, segredos, observabilidade e incidentes.
Plan=0 com output desconhecido; apply=1 após criar producer; consumer bloqueado pela postcondition.
Armadilhas comuns
Unknown como aprovado; erro como rollback; check como bloqueio; log antigo como prontidão atual.
Tópicos relacionados: Planos e validação · Módulos e identidade · Adoção e recuperação
Escolhe o controlo pela ação e pelo momento em que a condição pode ser avaliada.
Referência: Validate your configuration · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed