Wiki / Documentación interna / Plataforma

CI/CD, Vercel y Supabase

GitHub Actions en cada PR, Vercel para el hosting, Supabase CLI para todo lo relativo a base de datos y Auth.

Flujo habitual de una funcionalidad

Rama y PR

Implementar, verificar en local (typecheck, lint, format, tests, build), commit, push, gh pr create.

CI en GitHub Actions

Lint/tipos/tests unitarios, tests de RLS (pgTAP), auditoría de dependencias, escaneo de secretos, build + Playwright, y el propio deploy de preview de Vercel.

Merge

gh pr merge --squash --delete-branch, con todos los checks en verde.

Migración a producción

npx supabase db push --linked --include-all — manual, el CI no lo hace solo. El flag --include-all hace falta a menudo porque las marcas de tiempo de las migraciones de ramas paralelas no siempre quedan en orden cronológico estricto.

Deploy de producción

Normalmente automático al fusionar a main vía la integración de Vercel con GitHub. Cuando falla o se queda en cola, redeploy manual con npx vercel --prod --yes.

Gap conocido: el CI no aplica migraciones a producción por sí solo. Un PR fusionado con una migración nueva no llega de verdad a producción hasta que alguien ejecuta db push --linked a mano.

Configuración de Supabase Auth: supabase config push

supabase/config.toml declara el Send Email Hook, las URLs de redirección permitidas, etc. — pero esto no se sincroniza con el proyecto en la nube automáticamente, a diferencia de las migraciones SQL. Hace falta ejecutar explícitamente: 

npx supabase config push

Esto empuja todo el archivo (no solo Auth), no tiene modo de vista previa (--dry-run) en la versión actual de la CLI. El 19/09/2026 se descubrió que este comando nunca se había ejecutado desde que se activó el Send Email Hook — el secreto configurado en Supabase llevaba tiempo desincronizado del real. Detalle completo en Incidencias resueltas.

Vercel: cosas a tener en cuenta

  • Los deployments de preview están protegidos por login de Vercel — no se pueden inspeccionar sin autenticarse en ese panel.
  • Cambiar una variable de entorno en Vercel no afecta a una función ya desplegada: hace falta un redeploy nuevo para que la recoja.
  • El plan usado limita a 1 build a la vez por cuenta — si algo se queda "Queued" mucho más de lo normal (varios minutos sin pasar a "Building"), suele ser un despliegue anterior atascado bloqueando la cola; cancelarlo con vercel remove <url> suele destrabarlo.
  • El runtime de las funciones corre en UTC, no en hora de España — cualquier fecha formateada en servidor sin especificar timeZone: "Europe/Madrid" se ve con 1-2 horas de menos.