APRENDER. PRATICAR. EVOLUIR.Ligar o plano ao estado que será alterado
Uma entrega que inclui a base de dados precisa de identificar mais do que a versão da aplicação. Regista o artefacto de esquema, as propriedades de publicação, o destino e o estado que serviu de base ao plano. DeployReport descreve alterações propostas; DriftReport descreve diferenças em relação ao registo de uma base registada. Nenhum dos dois prova que a alteração foi executada. Um script SQL revisto também deixa de ser evidência suficiente se o destino mudou de forma relevante desde a análise. No exercício, D4 foi analisado contra S0, mas uma tentativa deixou S1 e confirmou uma regra. A próxima decisão começa por observar S1 e os efeitos aplicados. Não uses o resultado failed do pipeline para substituir essa observação nem para concluir que o destino continua em S0.
Interpretar proteções sem lhes atribuir garantias adicionais
BlockOnPossibleDataLoss pode interromper uma alteração de esquema mesmo numa tabela vazia. Desativá-lo não transforma valores incompatíveis nem demonstra que a alteração seja aceite. Analisa o risco identificado e o tratamento dos dados antes de escolher a propriedade. As opções de remoção também têm âmbito: DoNotDropObjectTypes=Tables protege um tipo de objeto, não apenas Archive. Se TempImport deve desaparecer, a exceção abrangente não expressa a intenção completa. Revê o plano resultante e separa a decisão de retenção da limpeza autorizada. IncludeTransactionalScripts usa transações onde possível, sem incluir automaticamente instruções enviadas por outro passo a um parceiro. Para Azure SQL Database, não uses BackupDatabaseBeforeChanges como prova de recuperação, pois a opção não se aplica. O plano precisa de um mecanismo e evidência adequados ao serviço e à janela disponível.
Rever os scripts que ficam fora do modelo
Um pre-script executa antes do plano, mas o plano já foi calculado antes dessa execução. Alterar o esquema no pre-script pode por isso invalidar pressupostos da comparação. Os scripts pré e pós-deployment estão no dacpac, mas não são compilados nem validados com o modelo de objetos. Um build bem sucedido não substitui a sua revisão. No exemplo da regra R7, o post-script faz um INSERT com chave única; a segunda execução encontra uma linha já existente. Define o resultado esperado se a linha não existir, se já tiver o valor correto ou se tiver um valor diferente. Um IF de existência pode evitar duplicação e ainda ocultar uma divergência de valor. O procedimento deve observar e reconciliar esse estado, mantendo evidência da decisão e das alterações autorizadas.
Escolher uma estratégia de migrações verificável
Um script EF não idempotente parte de um estado de migrações conhecido. Se M2 é a última aplicada e o objetivo é M4, o intervalo começa em M2. Um script idempotente num provider suportado consulta o histórico para aplicar as migrações em falta. Esse histórico não deteta automaticamente uma coluna removida manualmente depois de M4. Os bundles facilitam transporte e execução; um bundle self-contained adequado ao runtime pode dispensar SDK e fontes no agente. Contudo, não substitui SQL revisto quando essa é uma condição da entrega. Mantém correspondência entre artefacto, script e inputs aceites. Define ambiente e ligação de destino explicitamente e disponibiliza os ficheiros não secretos que o contexto lê. Um nome de job Production não demonstra que o processo recebeu configuração de produção.
Separar serialização, compatibilidade e recuperação
O lock de migração de EF Core 9 e posteriores protege a execução concorrente de migrações. Não demonstra que uma instância antiga continue a funcionar enquanto o esquema muda. Ensaiar coexistência de versões, controlar privilégios de alteração e ordenar dependências continuam a ser decisões da equipa. Uma aplicação não deve receber permissões adicionais apenas porque o arranque consegue executar uma migração. Avalia um passo separado quando revisão e disponibilidade o exigem. Também distingue Down de restauro de dados: recriar uma coluna vazia não repõe valores removidos. No caso de falha parcial, identifica commits, regras consumidas e efeitos externos antes de repetir. Uma continuação revista pode ser adequada, tal como uma recuperação autorizada; ambas precisam de demonstrar o estado pretendido e os dados que têm de ser preservados.
Ler o estado de rollout da revisão pretendida
Em Kubernetes, Available pode continuar verdadeiro graças aos Pods antigos enquanto a revisão nova não progride. Lê as condições juntamente com réplicas atualizadas, identidade do template e resultados funcionais. ProgressDeadlineExceeded não faz rollback automático pelo controlador Deployment. A decisão de recuperação precisa de ser explícita. Para três réplicas e limites de 25%, maxUnavailable arredonda para zero e maxSurge para um. Se não há capacidade adicional, não contes com remover primeiro um Pod saudável para criar espaço. minReadySeconds exige readiness sustentada antes de contar a réplica como disponível. Alterar apenas uma anotação exterior a spec.template não inicia uma nova revisão. Finalmente, confirma retenção de histórico: um número de revisão cujo ReplicaSet foi removido não permite recuperar o template por rollout undo sem outra definição preservada.
Validar a decisão efetiva das feature flags
Uma flag enabled=true com filtros de audiência e janela temporal precisa de requirement_type=All se ambos forem obrigatórios. Any, que é a predefinição do esquema Microsoft, permite um filtro verdadeiro. No targeting, uma exclusão prevalece sobre pertença a um ring habilitado. Usa casos de fronteira para verificar o comportamento pretendido, incluindo utilizador excluído e pedido fora da janela. Se duas componentes do mesmo pedido têm de conservar a primeira decisão, o snapshot fornece consistência nesse âmbito; não congela o valor entre todas as instâncias. Confirma ainda quais as flags carregadas: UseFeatureFlags sem parâmetros seleciona flags sem label. Um filtro production para key-values normais não demonstra seleção da flag com essa label. Antes de atribuir o resultado aos filtros, verifica se o provider carregou a definição correta.
Decidir promoção com evidência por instância
No exemplo, a revisão nova excedeu a deadline e uma instância inativa conserva FeesV2 ligada, apesar da alteração no portal. O middleware documentado atualiza configuração em resposta a pedidos e respeita o intervalo de refresh; o pedido que desencadeia a atualização assíncrona ainda pode ver valores anteriores. Não apresentes a gravação no portal como confirmação em todas as instâncias. Mantém a exposição contida, investiga progresso e confirma a configuração efetivamente carregada e avaliada. Usa os registos fictícios abaixo para escrever uma decisão em três partes: critério, evidência observada e trabalho em falta. Explica uma alternativa aceitável e a condição para adiar. O exercício não executa SQL, Kubernetes ou Azure; serve para praticar interpretação. Um ensaio real deve identificar versões, configuração, identidades e resultados, sem transformar um exemplo de curso em procedimento interno do banco.
{
"exercise": "fictional-delivery-review",
"database": {
"approvedPlanTargetState": "S0",
"observedTargetState": "S1",
"schemaChangeCommitted": true,
"ruleR7Committed": true,
"postScriptResult": "failed"
},
"deployment": {
"intendedRevision": 8,
"availableOldPods": 3,
"availableNewPods": 0,
"conditions": {
"Available": true,
"Progressing": false,
"reason": "ProgressDeadlineExceeded"
}
},
"featureFlag": {
"id": "FeesV2",
"portalEnabled": false,
"instanceAObservedEnabled": false,
"instanceBObservedEnabled": true,
"instanceBRefreshMode": "request-driven",
"instanceBHasReceivedNewRequest": false
},
"acceptance": {
"requiresApplicableReviewedDatabasePlan": true,
"requiresNewRevisionStable": true,
"requiresFlagOffOnEveryInstance": true,
"approvedException": false
}
}Uma regra SQL ficou committed antes de uma falha; noutra etapa, Pods antigos mantêm disponibilidade enquanto a nova revisão falha e uma flag conserva estado anterior.
Armadilhas comuns
Tratar um plano como execução, falha como rollback, disponibilidade antiga como aceitação do candidato e gravação no portal como propagação concluída.
Tópicos relacionados: Evidência de pipelines e identidade do artefacto · Compatibilidade de versões e continuidade de serviço · Migrações, recuperação e passagem a RUN
Cada decisão deve usar evidência do estado atual e do candidato pretendido. Proteções técnicas têm âmbito e não substituem compatibilidade, recuperação e critérios de aceitação.
Referência: SqlPackage deploy report and drift report · AZ-400 objectives 2026-07-27