Haz que tu próximo despliegue sea repetible

Reúna entradas identificables

Use una aplicación que pueda compilar en un entorno que no sea de producción, acceso al código fuente y a su registro de artefactos, un esquema de configuración versionado y un almacén de secretos externo. Mantenga un lanzamiento funcional conocido. Estas son entradas para su automatización; PrivacyNodes no proporciona una API de despliegue ni un ejecutor de pipelines a través de este sitio web.

Fije el artefacto en lugar de depender de una etiqueta mutable como latest. Docker documenta la fijación por digest para identificar una imagen base exacta, con la necesidad de revisar las actualizaciones de forma deliberada. La reproducibilidad y el parcheo son ambas responsabilidades: mantener una imagen vulnerable antigua para siempre no es un plan de mantenimiento.

Referencia técnica: Buenas prácticas de compilación de Docker.

Escriba un registro de lanzamiento antes de cambiar el tráfico

Este es un formato de documento, no un script ejecutable. Complete los marcadores de posición a partir del artefacto revisado. Una revisión del código fuente por sí sola no describe los cambios del entorno. Incluya la duración observada de la migración, el comportamiento esperado de bloqueo, las diferencias de configuración y el último artefacto 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

Guarde el registro en un lugar accesible cuando la aplicación esté caída. Referencie las credenciales de recuperación protegidas sin incluir sus valores. Nombre al mantenedor que puede detener la promoción y el punto tras el cual la reversión planificada ya no es válida.

Separe la preparación de la promoción

Compile e inspeccione primero el artefacto. Valide la configuración y las referencias de secretos antes de iniciar el nuevo proceso. Aplique solo el paso de esquema revisado para este lanzamiento. Inicie la nueva versión en el entorno previsto y compruebe las dependencias antes de mover el tráfico; evite combinar una migración destructiva no revisada con una actualización de imagen ordinaria.

Con Compose, un contenedor iniciado no establece la preparación. Una comprobación de estado significativa y condition: service_healthy pueden hacer útil la espera de dependencias, pero no pueden verificar un flujo de trabajo de cliente. La aplicación aún debe manejar que una dependencia deje de estar disponible después del inicio.

Referencia técnica: Orden de inicio de Docker Compose.

Verifique más que un puerto en verde

Para la API de informes, verifique una solicitud de prueba autenticada, una lectura contra el esquema previsto, una pequeña exportación en cola y el acceso a su archivo. Utilice un espacio de nombres de prueba dedicado y suprima las notificaciones de producción. Compruebe que las versiones superpuestas no puedan duplicar accidentalmente el trabajo programado.

Escriba las salidas esperadas antes de la comprobación: alcance de cuenta correcto, el registro de ejemplo esperado, una exportación completada y ningún dato no autorizado entre cuentas. Registre las salidas reales y los tiempos después. Una página de inicio que devuelve HTTP 200 es insuficiente si un worker falla repetidamente o una migración dejó a la API leyendo valores obsoletos.

Haga explícita la decisión de recuperación

Si el proceso no arranca, mantenga el tráfico en la versión que funciona. Si falla una comprobación de flujo de trabajo, detenga la promoción y conserve la evidencia censurada. Un esquema aditivo compatible con el artefacto antiguo puede permitir el rollback de la aplicación. Tras una transformación incompatible, el código antiguo puede ser inseguro; siga el plan de corrección hacia adelante o de recuperación de datos revisado.

No repita indefinidamente una migración que falla. Determine qué se confirmó, si el reintento es seguro y si los usuarios escribieron bajo el nuevo esquema. La guía de migración desarrolla este límite con un cambio de columna. No trate la existencia de un botón de rollback como prueba de que los datos se pueden revertir.

Deje un registro que otro mantenedor pueda seguir

Compare los identificadores del artefacto y la configuración desplegados con el registro previsto. Conserve las comprobaciones, los intentos fallidos y la acción de recuperación elegida. Mantenga el último artefacto funcional bajo una política de retención explícita; no lo elimine mientras la validación esté incompleta.

Un ensayo útil permite que otro mantenedor autorizado explique las entradas, repita las comprobaciones y encuentre las instrucciones de recuperación sin buscar en su historial de shell. No prueba cero tiempo de inactividad ni el éxito futuro. Revíselo cuando cambien el esquema, el comportamiento del worker o las dependencias. A continuación, acote los permisos de la identidad de despliegue.