85 lines
4.8 KiB
Markdown
85 lines
4.8 KiB
Markdown
# Sincronizar migraciones de Supabase (dev + prod)
|
|
|
|
## Contexto
|
|
|
|
El repo tiene 37 archivos de migración en `supabase/migrations/`, el más reciente del
|
|
2026-07-22. La última verificación documentada de que ambas bases estaban al día es
|
|
`docs/plans/2026-06-08-supabase-dev-prod-finalization.md`, que confirma **9 migraciones
|
|
aplicadas y verificadas en ambas DBs** a esa fecha. Desde entonces se agregaron ~28
|
|
migraciones nuevas que probablemente nunca se empujaron a uno o ambos proyectos remotos
|
|
(streaks, ranking config, bonus settings, admin update policy, etc.). El objetivo es
|
|
detectar el gap real por ambiente y aplicarlo, sin asumir que "aplicar todo a ambos" es
|
|
seguro.
|
|
|
|
## Hallazgos clave (ya verificados, solo lectura)
|
|
|
|
- **Supabase CLI no está instalado globalmente**, pero `npx supabase@latest` funciona sin
|
|
instalación previa (resuelve a la v2.110.0).
|
|
- **Ya hay sesión autenticada**: `SUPABASE_ACCESS_TOKEN` está exportado en `~/.bashrc`, por
|
|
lo que `npx supabase projects list` ya respondió sin pedir login.
|
|
- **Dos proyectos remotos** (org `vercel_icfg_9zFCFZDSC4E6wody0k7rBxCB`):
|
|
| Ambiente | Nombre | project-ref |
|
|
|---|---|---|
|
|
| Production | `supabase-gfiber-prod` | `hwxkegbdnbrzvekrqxbd` |
|
|
| Preview/Dev | `supabase-gfiber-dev` | `vshcimexazocttjmyrqy` |
|
|
- El link local actual (`supabase/.temp/project-ref`) apunta a **prod** (`hwxkegbdnbrzvekrqxbd`,
|
|
`linked: true`); dev aparece `linked: false`. Habrá que re-linkear entre pasos.
|
|
- ⚠️ **Existen migraciones intencionalmente divergentes entre ambientes** — no todas las
|
|
migraciones deben aplicarse a ambos proyectos:
|
|
- `20260611210000_rollback_attendance_status_prod.sql` — deshace una migración anterior
|
|
**solo en prod** (prod seguía usando los códigos viejos de asistencia).
|
|
- `20260615120000_simplify_attendance_codes_dev.sql` — simplifica los códigos de
|
|
asistencia **solo en dev** ("DEV ONLY... Production is NOT touched", literal en el
|
|
comentario del archivo).
|
|
|
|
Un `supabase db push` ciego a ambos proyectos rompería este estado divergente a
|
|
propósito. Confirmé por grep que son las únicas dos migraciones con este marcador
|
|
(`_dev`/`_prod` en el nombre o comentario "DEV ONLY/PROD ONLY").
|
|
|
|
## Plan de ejecución
|
|
|
|
1. **Diagnóstico por ambiente** (solo lectura, no destructivo):
|
|
- `npx supabase link --project-ref hwxkegbdnbrzvekrqxbd` (si no sigue linkeado) y
|
|
`npx supabase migration list` → lista de migraciones locales vs. aplicadas en **prod**.
|
|
- `npx supabase link --project-ref vshcimexazocttjmyrqy` y `npx supabase migration list`
|
|
→ lo mismo para **dev**.
|
|
- Esto requiere el password de la DB de cada proyecto (`SUPABASE_DB_PASSWORD` está en
|
|
`.env` para dev; para prod habrá que sacarlo del vault de 1Password "GFiber Pilot
|
|
Extension" o de `vercel env pull --environment=production`, como se hizo en el plan de
|
|
finalización de junio).
|
|
- Registrar qué migraciones aparecen como "pendientes" en cada proyecto.
|
|
|
|
2. **Filtrar las migraciones dev/prod-only del diff genérico**:
|
|
- Si `20260611210000_rollback_attendance_status_prod.sql` aparece pendiente en **dev**,
|
|
no aplicarla ahí (es intencional que dev no la tenga).
|
|
- Si `20260615120000_simplify_attendance_codes_dev.sql` aparece pendiente en **prod**,
|
|
no aplicarla ahí (es intencional que prod no la tenga).
|
|
- Todas las demás migraciones pendientes (streaks, ranking config, bonus settings, etc.)
|
|
se tratan como gap real a cerrar en el proyecto donde falten.
|
|
|
|
3. **Aplicar el gap real**:
|
|
- `npx supabase db push --project-ref <ref>` en cada proyecto que tenga migraciones
|
|
pendientes reales (excluyendo las dev/prod-only según el paso 2).
|
|
- Confirmar con un segundo `migration list` que ambos remotos quedan con el estado
|
|
esperado (idéntico salvo las dos migraciones intencionalmente divergentes).
|
|
|
|
4. **Dejar el link local en un estado conocido** al terminar (documentar a cuál de los dos
|
|
quedó linkeado `supabase/.temp/project-ref`, ya que ambos comandos de push lo van
|
|
reescribiendo).
|
|
|
|
## Verificación
|
|
|
|
- `npx supabase migration list --project-ref hwxkegbdnbrzvekrqxbd` y
|
|
`... --project-ref vshcimexazocttjmyrqy` después del push, comparando que ambas listas
|
|
coincidan salvo las dos migraciones marcadas como divergentes a propósito.
|
|
- Smoke check opcional: revisar en el dashboard de cada proyecto (Table Editor) que las
|
|
tablas nuevas esperadas (`agent_streaks`, `ranking_config`, etc.) existan donde
|
|
correspondan.
|
|
|
|
## Nota de ejecución
|
|
|
|
Este trabajo (CLI de Supabase, migraciones de schema) cae dentro del scope del agente
|
|
`vercel-helper` según `CLAUDE.md`. Se recomienda delegarle la ejecución de los pasos 1-4
|
|
con este contexto ya resuelto (refs de proyecto, y la lista de migraciones dev/prod-only a
|
|
excluir), en vez de correr los comandos manualmente en la sesión principal.
|