Entregar sin un salto de fe
Construye un camino de lanzamiento repetible y planifica que el código y los datos cambien a velocidades distintas.
AL TERMINAR, PODRÁS
- Distinguir integración, entrega y despliegue continuos
- Diseñar un lanzamiento por etapas reversible
- Planificar una migración de base de datos compatible
Descripción del diagrama: Construir → Staging; Staging → Canario 5%; Canario 5% → Todos (sano); Canario 5% → Staging (revertir); Ampliar esquema → Reducir esquema (código viejo y nuevo funcionan)
Construye una vez, promueve a propósito
La integración continua (CI) da retroalimentación automática y frecuente cuando se combinan cambios.
La entrega continua (continuous delivery) mantiene los cambios listos para lanzarse; el despliegue continuo (continuous deployment) lanza automáticamente los cambios que pasan las comprobaciones elegidas. Un pipeline (cadena automatizada) debería producir un artefacto rastreable con dependencias conocidas y ejecutar las comprobaciones adecuadas para el cambio. Promueve el mismo artefacto construido a través de los entornos en lugar de reconstruirlo cada vez desde un estado ambiguo.
Registra qué versión está en ejecución y cómo inspeccionar su salud. Un pipeline que pasa reduce la incertidumbre, pero no elimina la necesidad de observar el comportamiento real.
Expón un poco antes de exponer a todos
Un lanzamiento por etapas limita la población afectada inicialmente por un cambio.
Un canary (versión canaria) puede recibir una pequeña parte del tráfico mientras comparas señales relevantes con una línea base. Elige las condiciones de parada de antemano: más fallas, más latencia, más antigüedad en la cola o un invariante violado. Los feature flags (interruptores de funcionalidad) pueden separar el despliegue de la exposición de una funcionalidad, pero agregan estados que hay que probar y limpiar.
Un rollback (reversión) solo sirve cuando la versión anterior sigue siendo compatible con los datos y los efectos externos que produjo la nueva.
Los datos sobreviven a un despliegue
Para un cambio de esquema, usa una secuencia de expandir y contraer (expand and contract): agrega una estructura compatible, despliega código que pueda convivir con ambas, migra los datos, cambia el uso y elimina la estructura obsoleta cuando ya no queden lectores ni escritores antiguos.
Durante un lanzamiento pueden seguir activos trabajos de Relay de larga duración y workers antiguos. Tenlos en cuenta de forma explícita. Los rellenados grandes (backfills) necesitan límites de velocidad, poder reanudarse y visibilidad del progreso.
Una migración destructiva no se revierte solo con volver a desplegar el código anterior, así que verifica los respaldos y los procedimientos de recuperación antes de depender de ellos.
ERROR FRECUENTE
Decir que un lanzamiento es reversible porque el código puede volver atrás ignora los cambios de esquema, los efectos secundarios externos y los cuerpos de trabajos encolados.
INTÉNTALO TÚ
Planifica un lanzamiento que agregue un tenant_id obligatorio a los trabajos existentes sin romper los workers antiguos. Identifica las etapas compatibles y cuándo se pueden eliminar las suposiciones sobre el campo antiguo.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Crea una lista de verificación de lanzamiento de Relay con un artefacto rastreable, señales para el lanzamiento por etapas y un plan de recuperación específico para la migración.