Torne sua próxima implantação repetível

Colete entradas identificáveis

Use uma aplicação que você possa compilar em um ambiente de não produção, acesso ao código-fonte e ao seu registro de artefatos, um schema de configuração versionado e um armazenamento externo de segredos. Mantenha um release funcional conhecido. Esses são insumos para sua automação; PrivacyNodes não fornece uma API de implantação ou executor de pipeline por meio deste site.

Fixe o artefato em vez de confiar em um rótulo mutável como latest. O Docker documenta a fixação por digest para identificar uma imagem base exata, com a necessidade de revisar atualizações deliberadamente. Reproducibilidade e patching são ambas responsabilidades: manter uma imagem vulnerável antiga para sempre não é um plano de manutenção.

Referência técnica: Boas práticas de build do Docker.

Escreva um registro de release antes de alterar o tráfego

Este é um formato de documento, não um script executável. Preencha os placeholders a partir do artefato revisado. Uma revisão de origem sozinha não descreve alterações de ambiente. Inclua a duração observada da migração, o comportamento esperado de lock, diferenças de configuração e o último artefato funcional.

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

Armazene o registro em algum lugar alcançável quando a aplicação estiver fora do ar. Referencie credenciais de recuperação protegidas sem incluir seus valores. Nomeie o mantenedor que pode interromper a promoção e o ponto após o qual o rollback planejado não é mais válido.

Separe a preparação da promoção

Compile e inspecione o artefato primeiro. Valide a configuração e as referências de segredos antes de iniciar o novo processo. Aplique apenas a etapa de schema revisada para este release. Inicie a nova versão no ambiente pretendido e verifique as dependências antes de mover o tráfego; evite combinar uma migração destrutiva não revisada com uma atualização comum de imagem.

Com o Compose, um contêiner iniciado não estabelece prontidão. Um health check significativo e condition: service_healthy podem tornar útil a espera por dependências, mas não podem verificar um fluxo de trabalho de cliente. A aplicação ainda deve lidar com uma dependência que fica indisponível após a inicialização.

Referência técnica: Ordem de inicialização do Docker Compose.

Verifique mais do que uma porta verde

Para a API de relatórios, verifique uma solicitação de teste autenticada, uma leitura no esquema pretendido, uma pequena exportação enfileirada e o acesso ao seu arquivo. Use um namespace de teste dedicado e suprima notificações de produção. Verifique se versões sobrepostas não podem duplicar acidentalmente o trabalho agendado.

Escreva as saídas esperadas antes da verificação: escopo de conta correto, o registro de exemplo esperado, uma exportação concluída e nenhum dado não autorizado entre contas. Registre as saídas reais e o tempo depois. Uma página inicial retornando HTTP 200 é insuficiente se um worker falhar repetidamente ou uma migração deixou a API lendo valores obsoletos.

Torne a decisão de recuperação explícita

Se o processo falhar ao iniciar, mantenha o tráfego na versão funcional. Se uma verificação de fluxo de trabalho falhar, interrompa a promoção e preserve evidências editadas. Um esquema aditivo compatível com o artefato antigo pode permitir o rollback da aplicação. Após uma transformação incompatível, o código antigo pode ser inseguro; siga o plano de correção progressiva ou recuperação de dados revisado.

Não repita uma migração com falha indefinidamente. Determine o que foi confirmado, se a nova tentativa é segura e se os usuários escreveram sob o novo esquema. O guia de migração desenvolve esse limite com uma alteração de coluna. Não trate a existência de um botão de rollback como prova de que os dados podem ser revertidos.

Deixe um registro que outro mantenedor possa seguir

Compare os identificadores do artefato e da configuração implantados com o registro planejado. Preserve verificações, tentativas falhas e a ação de recuperação escolhida. Mantenha o último artefato funcional sob uma política de retenção explícita; não o remova enquanto a validação estiver incompleta.

Um ensaio útil permite que outro mantenedor autorizado explique as entradas, repita as verificações e encontre instruções de recuperação sem vasculhar seu histórico de shell. Isso não prova tempo de inatividade zero ou sucesso futuro. Revisite-o quando o esquema, o comportamento do worker ou as dependências mudarem. Em seguida, restrinja as permissões da identidade de implantação.