APRENDER. PRATICAR. EVOLUIR.Três estados que o plano deve distinguir
O laboratório cria versões numa diretoria temporária e inicia processos Python reais. Cada worker lê a configuração uma vez e recebe pedidos por pipes. A versão v1 calcula dez vezes um mais dois, devolvendo 12. Trocar o apontador current para v2 altera a seleção em disco, mas o processo antigo conserva v1. Uma nova instância lê a configuração v2 e devolve 22. Regista separadamente artefacto presente, seleção atual e configuração carregada. Esta distinção ajuda numa mudança de middleware em que copiar um ficheiro não implica recarga. O comportamento de WebSphere, de um service manager ou de outro produto deve ser confirmado na respetiva versão; o worker pedagógico não define esses contratos.
Validar o documento e o conjunto revisto
O preflight executa o worker com uma opção de validação. Um JSON incompleto é rejeitado com código 2; um documento legível cujo fee é texto é rejeitado com código 3. Estes códigos pertencem ao guião e não são normas operacionais. Noutro passo, acrescentar uma nova linha mantém o documento válido, mas altera o hash. A regra fictícia compara hashes de código e configuração e o destino, pelo que impede essa promoção até reconciliar o conteúdo. A validade do documento não equivale a identidade dos bytes, e nenhuma dessas verificações autentica o aprovador. Para o pedido de mudança, conserva o conjunto avaliado e explica qualquer desvio antes de usar evidência produzida para outro conteúdo.
Substituição local e fronteiras da atomicidade
O guião cria um symlink temporário e substitui current com os.replace no mesmo filesystem. Depois resolve a seleção uma vez para iniciar código e configuração a partir do mesmo diretório. A operação local não atualiza a memória de processos já iniciados, não encaminha tráfego e não coordena vários nós. Também não torna imutáveis os ficheiros do diretório selecionado. Se outro ator puder alterá-los entre verificação e uso, existe uma condição que o guião sequencial não protege. Num plano real, identifica quem pode modificar os artefactos, como se controla concorrência e como se observam estados mistos. O ensaio não inclui falha de energia, nem permite concluir durabilidade após crash a partir de uma substituição bem-sucedida.
Observar arranque falhado sem perder o estado anterior
Num teste negativo, o guião ignora deliberadamente o preflight e seleciona configuração inválida. O novo processo termina com código 2, enquanto uma instância v1 já existente continua a devolver 12. É um estado misto: seleção em disco nova, arranque falhado e execução anterior ainda funcional. Antes de repetir comandos, identifica estes factos e aplica as condições de recuperação. Terminar a instância saudável sem substituta confirmada pode aumentar impacto. O laboratório controla os seus cinco subprocessos e aguarda a conclusão de todos antes de remover a diretoria temporária. Não para serviços existentes. Numa mudança real, o plano precisa de tratar trabalho em curso, acesso, capacidade e responsabilidade pela decisão de manter ou retirar cada instância.
python3 content/labs/change-runtime/run.py --output /tmp/dr-change-runtime.json
# Compare pointerDoesNotReloadProcess and newProcessLoadsCandidate.
# The worker reads configuration once at startup; no implicit reload.current muda para v2; o processo antigo continua a devolver v1 e 12, enquanto uma nova instância devolve v2 e 22.
Armadilhas comuns
Tratar um exit code como deployment completo, usar o nome da versão como identidade ou presumir recarga automática após alterar ficheiros.
Tópicos relacionados: Identidade e autorização · Recuperação e handover
O estado efetivo depende do contrato de carregamento do processo; valida separadamente os ficheiros e o comportamento da instância.
Referência: Release Engineering · DR Change Management 2026.1; independent technical curriculum