Conceptos Básicos de Entrega

8 ejemplos para alinear la frecuencia de despliegue de Node.js con el riesgo de migración de la base de datos - 6 básicos y 2 intermedios.

Requisitos previos

• CI/CD con comprobaciones de PR y promoción de lanzamientos distintas (ver Conceptos Básicos de CI/CD)
• Migraciones en control de versiones (Prisma, Flyway o node-pg-migrate)
• Entorno de staging que refleje los tamaños del pool de producción
• Línea base DORA capturada (ver Métricas DORA para equipos de Node)

Ejemplos Básicos

1. Node Despliega Rápido; las Bases de Datos No

• Los contenedores Node sin estado son baratos de volver a desplegar
• Los cambios de esquema son el freno: planifica las migraciones antes de prometer despliegues diarios en producción
• Las feature flags desacoplan el despliegue de código de la exposición del comportamiento

Relacionado: Métricas DORA para equipos de Node - mide la salud de la entrega

2. Patrón de Migración de Expansión-Contracción

Expansión: Añade una columna anulable o una nueva tabla - despliega la API que escribe tanto lo antiguo como lo nuevo.

Contracción: Rellena los datos; cambia las lecturas a la nueva forma.

Eliminación: Elimina la columna antigua en un lanzamiento posterior después de que se cierre la ventana de reversión.

-- Expansión (despliegue 1)
ALTER TABLE orders ADD COLUMN status_v2 TEXT;
 
-- Contracción (despliegue 2) - la aplicación escribe status_v2, lee con COALESCE
-- Eliminación (despliegue 3)
ALTER TABLE orders DROP COLUMN status;

• Cada paso de expansión debe ser compatible con versiones anteriores de la imagen de la API
• Nunca elimines una columna que la versión anterior todavía lee

3. Pipeline de PR vs Pipeline de Lanzamiento

Pipeline de PR (cada push):
  lint → typecheck → pruebas unitarias → integración (Testcontainers)
 
Pipeline de lanzamiento (merge a main):
  construir imagen → escanear → desplegar staging → smoke → promoción manual/automática a producción

• El pipeline de PR prueba el código; el pipeline de lanzamiento prueba el artefacto
• Etiqueta las imágenes con gitSha, no con latest
• Bloquea el lanzamiento si la migración no se ha ejecutado en staging

4. Orden de Despliegue de API y Worker

Migración de expansión de esquema (staging + producción)
  → desplegar API (escribe nuevos campos, lee el fallback)
  → desplegar workers (procesa la nueva forma de trabajo)
  → trabajo de relleno (si es necesario)
  → desplegar API (lee solo los nuevos campos)
  → migración de contracción

• Los workers que van por detrás de la API son más seguros que los workers que van por delante de la API en cambios destructivos
• Pausa los workers durante estados intermedios incompatibles
• Documenta el orden en docs/deploy-order.md por servicio

5. Lista de Verificación de Riesgos de Migración

[ ] ¿Compatible con versiones anteriores de la imagen de la API N-1?
[ ] ¿Compatible con versiones anteriores de la imagen del worker N-1?
[ ] ¿Índice creado CONCURRENTLY (Postgres)?
[ ] ¿Tiempo de bloqueo estimado para ALTER?
[ ] ¿Ruta de reversión documentada (corrección hacia adelante vs deshacer)?
[ ] ¿Prueba de carga en staging después de la migración?

• ALTER TABLE en tablas grandes necesita una ventana de mantenimiento o una herramienta de esquema en línea
• Prisma migrate deploy en CI antes del despliegue de k8s

6. Flujo de Promoción de Entorno

rama de característica → PR → main → staging (automático) → producción (controlado)

• Staging utiliza un subconjunto de volumen de datos similar al de producción, no una base de datos vacía
• Las pruebas de humo acceden a /health/ready y a una ruta crítica de escritura/lectura
• La promoción a producción requiere un ticket de cambio para industrias reguladas

Ejemplos Intermedios

7. Acoplamiento de la Entrega al Presupuesto de Errores

Presupuesto de errores restante > 50% → cadencia de despliegue normal
Presupuesto de errores 20-50%         → los despliegues requieren aprobación del TL
Presupuesto de errores < 20%          → congelar despliegues de características; solo correcciones

• El consumo de SLO vincula la velocidad de entrega con la fiabilidad (ver SLOs y Presupuestos de Errores)
• Los equipos de Node a menudo despliegan demasiado rápido para la capacidad de migración de la base de datos; el presupuesto protege a ambos

8. Notas de Lanzamiento para Backend

## orders-api v2.14.0 (2026-07-09)
- Migración: 20260709_add_status_v2 (expansión, compatible con versiones anteriores)
- Orden de despliegue: migrar → API → workers
- Feature flag: new-checkout (desactivada por defecto)
- Reversión: deshacer el despliegue a v2.13.2; la migración es solo hacia adelante

• Soporte y PM leen esto; enlazar desde Slack #releases
• Las restricciones explícitas de reversión evitan sorpresas a las 3 a.m.

Preguntas Frecuentes

Relacionado

• Feature Flags - desacoplar el despliegue de la exposición
• Entrega Canary y Progresiva - promoción segura
• Métricas DORA para equipos de Node - métricas de entrega
• Conceptos Básicos de CI/CD - separación de pipelines
• Mejores Prácticas de Entrega Empresarial - lista de verificación condensada

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS Activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.