Despliegues¶

Responde: ¿cómo se pone un cambio en producción sin romper nada, y en qué orden?

Despliegue explica dónde corre cada pieza y qué la pone ahí. Esta página es el procedimiento: qué mirar antes, en qué orden, y qué hacer cuando sale mal.

La regla que explica casi todo¶

El frontend y el backend se despliegan por separado, y el orden importa. Son dos repositorios, dos pipelines y dos plataformas, y nada los coordina: cada uno despliega a producción al mergear a su rama principal, sin saber del otro.

Hay un tercer actor que no tiene pipeline: la base de datos. Las migraciones las aplica una persona a mano.

Un cambio que toca los tres —y los cambios de permisos tocan los tres— tiene un único orden correcto, y equivocarse deja la aplicación rota para todos los usuarios hasta que alguien lo note.

Qué pasa si se despliega al revés¶

Conviene tener presente la forma del fallo, porque es la que se repite.

Si el frontend llega a producción antes que la migración que su versión necesita —por ejemplo, la que introduce identificadores de permiso más finos—, el frontend pide permisos que la base todavía no tiene. La sección de administración queda inaccesible para todos los roles, incluido el de mayor privilegio: el filtrado de navegación no hace excepciones.

La salida es aplicar la migración contra producción sin esperar el despliegue del backend, y alcanza porque el endpoint que le dice al frontend qué permisos tiene el usuario lee los permisos en vivo de la base, no del mapa compilado en el binario. Ese mapa solo lo usa la verificación interna, así que el binario anterior sigue sirviendo sin regresión y empieza a devolver los identificadores nuevos.

Tres cosas que conviene tener a mano:

El orden correcto¶

flowchart LR
  A["1 · Auditar<br/>los datos"] --> B["2 · Aplicar la<br/>migración"]
  B --> C["3 · Desplegar<br/>el backend"]
  C --> D["4 · Desplegar<br/>el frontend"]
  D --> E["5 · Verificar"]

  classDef man fill:#c0392b,stroke:#7b241c,color:#fff
  classDef auto fill:#1168bd,stroke:#0b4884,color:#fff
  class A,B man
  class C,D,E auto

En rojo, lo que hace una persona.

La regla general: el proveedor antes que el consumidor. La base provee al backend, y el backend al frontend. Desplegar un consumidor que exige algo que su proveedor todavía no da es exactamente el incidente de arriba.

Para revertir, el orden se invierte: frontend, backend, y recién después la migración. Y revertir una migración no siempre es posible sin pérdida: hay que mirar su reverso antes de asumirlo.

Antes de desplegar¶

Cómo revertir¶

Que las dos primeras sean inmediatas y la tercera no es, otra vez, la razón del orden.

Desplegar el backend no corta las peticiones en vuelo¶

Ante la señal de terminación la API deja de aceptar conexiones y espera hasta 8 s a que terminen las requests en curso; Cloud Run da 10 s entre la señal y el corte.

Tiene un límite: una conexión que nunca queda inactiva, como el flujo en vivo de logs, se corta al vencer el plazo. Para la ingesta no hay pérdida de datos en ningún caso, porque el Edge reintenta y la idempotencia evita duplicados.

El supuesto que hay que reconfirmar¶

El procedimiento de arriba —aplicar una migración directamente contra producción para destrabar un incidente— se apoya en que producción funciona como entorno de prueba: sin usuarios reales que dependan de su disponibilidad ni de sus datos.

Eso hay que reconfirmarlo cada vez, porque el sistema avanza hacia el traspaso a un cliente. Si ya hay datos de planta que importan, hace falta como mínimo un respaldo previo verificado, que hoy no existe (pendiente).

Lo que falta¶

Relacionado¶

• Despliegue — dónde corre cada pieza
• Configuración y secretos — qué variable vive en qué plataforma
• SYS-ADR-006 — por qué estas plataformas