Deploy de producción de Aquazaku

Deploy de producción de Aquazaku A workflow diagram generated by Archify. 01 / Git 02 / Vercel 03 / Railway 04 / Humano 05 / Supabase EX / Rollback Cambio Build + deploy Migración Verificar Merge main · PR aprobada · Git › Cambio Merge main PR aprobada Deploy web · app.aquazaku.com · Vercel › Build + deploy Deploy web app.aquazaku.com Build · Dockerfile · Railway › Build + deploy Build Dockerfile Deploy prod · CMD pnpm start · Railway › Migración Deploy prod CMD pnpm start migrate:prod · deliberado · Humano › Verificar · manual migrate:prod deliberado manual GRANTs OK · audit append-only · Supabase › Verificar GRANTs OK audit append-only Rollback · revert + nueva migration · Rollback › Verificar · owner: Mao Rollback revert + nueva migration owner: Mao push push server arriba falla revert Legend User UI Agent logic Policy Tool action Cloud service

El happy path

  • • El merge a main dispara Vercel y Railway en paralelo — web y api se redesplegan con la nueva imagen.
  • • El server arranca con el último código mergeado. Las migraciones NO son automáticas: las corre Mao a mano con pnpm db:migrate:prod después del deploy.

Por qué producción NO migra al arrancar

  • • ADR-0009 asume que dos instancias migrando a la vez se pisan — una migración a medias es peor que un deploy demorado.
  • • Con el startCommand vacío, el server arranca con el código mergeado aunque las tablas no existan. Los errores 500 se ven rápido desde el primer request; no se acumulan en silencio.

El rollback es forward-only

  • • Las migraciones son forward-only. git revert del código no deshace la migración ya aplicada — si la nueva migration creó una columna, revertir el código la deja huérfana.
  • • Para revertir: git revert del código + una nueva migration que deshaga el cambio. El dueño es Mao, no un cron automático.