Deploy sin downtime: cómo actualizamos sin que nadie lo note

El código pasa por staging primero. Los smoke tests se ejecutan contra la versión nueva con datos de staging. Si algo falla, el deploy no avanza.

Cuando staging pasa, el deploy a producción usa PM2 con reload graceful: los workers existentes terminan de procesar sus requests antes de apagarse. Los workers nuevos arrancan y empiezan a aceptar tráfico nuevo.

Durante ese proceso, hay un periodo corto donde conviven workers con la versión vieja y workers con la versión nueva. Para la mayoría de los cambios, eso es invisible para el usuario.

Las migraciones son el caso más delicado. Cambiar el schema de una base de datos en producción puede romper la aplicación si no está coordinado con el código.

Nuestra regla es que las migraciones deben ser backwards-compatible con la versión de código anterior. Primero el schema change (agregar columna, crear tabla). Después el código que lo usa. Si algo sale mal en el código, el schema change ya está aplicado y no hay que revertirlo.

Deployar los viernes. Deployar sin staging. Deployar cambios que tocan el schema de autenticación sin revisión manual.

El downtime planeado es aceptable en casos extremos. El downtime no planeado es siempre un fallo de proceso.