ADR-0002 · Migraciones y bootstrap dentro de start.sh, al arrancar el contenedor¶
- Estado: aceptado
- Decisores: no registrado en el repositorio (reconstruido del código y de los planes de deploy)
- Fecha de la decisión: no registrada;
start.shya tiene esta forma antes del pipeline de CI/CD (2026-06-17)
Contexto y problema¶
La imagen es la misma para staging y producción y el despliegue se reduce a docker compose up.
Hacía falta garantizar que el schema estuviera migrado antes de servir tráfico, sin agregar pasos
manuales al despliegue ni un job aparte en el pipeline.
Opciones consideradas¶
- Ejecutar
medusa db:migrate(másseedy creación del usuario admin) dentro destart.sh, que es elCMDde la imagen (elegida). - Migración one-shot desde
deploy.shantes de levantar los contenedores (docker compose run --rm … db:migrate) — propuesta en el plan de split server/worker, no implementada.
Decisión¶
start.sh ejecuta en cada arranque: npx medusa db:migrate → npm run seed (con || echo para
tolerar el fallo) → npx medusa user … (con || true) → npm run start. Ningún paso del pipeline
migra la base: alcanza con que el contenedor arranque.
Consecuencias¶
Positivas¶
- El despliegue no tiene pasos manuales de base de datos; un rollback por tag también reaplica lo que la imagen vieja espera.
- Un ambiente nuevo se levanta solo, sin bootstrap manual.
Negativas / deuda asumida¶
- Las migraciones se aplican solas al levantar el contenedor, así que el
pg_dumpprevio dedeploy.shes la única red de seguridad: el rollback de código a una versión anterior a un cambio de schema exige restaurar la base. npm run seedcorre en cada arranque de producción; el propio plan de upgrade lo marca como algo a quitar.start.shcrea un usuario admin con credenciales hardcodeadas en el archivo versionado. Es una fuga real de credenciales del repositorio y está pendiente de resolver: rotar la clave y mover el paso fuera del arranque.- Bloquea el split server/worker: con dos contenedores de la misma imagen, ambos correrían las migraciones en paralelo.