Saltar a contenido

ADR-0004 · Producción se despliega por tag v*, no por workflow_dispatch

  • Estado: aceptado
  • Decisores: hquintero
  • Fecha de la decisión: 2026-08-28

Contexto y problema

ADR-0003 estableció el workflow_dispatch manual como punto de control humano para producción, porque en ese momento se creía que las reglas de protección de los Environments no estaban disponibles en el plan de la organización. Eso resultó incorrecto (están disponibles en repos privados con plan Pro/Team), y el modelo tenía costos ya registrados como deuda: no queda registro legible de qué versión entró, es fácil creer que un push a main desplegó cuando no lo hizo, y disparar el workflow desde otra rama rompía el armado de tags de imagen.

Mientras tanto, la organización estandarizó el despliegue por tag en la guía CI/CD (actualizada 2026-08-28) y lo aplicó de punta a punta en el CMS. Este repo era el único que quedaba con el modelo viejo.

Opciones consideradas

  1. Tag v* semver sobre main como único disparador de producción (elegida — estándar vigente).
  2. Mantener el workflow_dispatch de ADR-0003.
  3. Desplegar en cada push a main — descartado desde siempre por riesgo.

Decisión

Producción se despliega solo con un tag v* (semver: v1.3.0) y con dos validaciones complementarias:

  • El Environment production tiene una deployment tag policy v*: GitHub rechaza cualquier otro ref antes de que el job arranque.
  • El job de build verifica con git merge-base --is-ancestor que el tag apunte a un commit alcanzable desde staging o desde main — la regla del Environment filtra por nombre y no puede saber de qué rama vino el commit; el merge-base sí. Se aceptan ambas ramas porque en la práctica los tags salen de staging (guía CI/CD 2026-08-28, tras el caso del storefront); un guard solo-main habría rechazado despliegues legítimos.

El acto deliberado de crear el tag reemplaza al click del dispatch: queda registrado con autor, fecha y nombre legible. El rollback preferido es redesplegar el tag anterior en el servidor (MEDUSA_TAG=v1.2.4 ./deploy.sh — la imagen ya está en GHCR); relanzar la corrida del tag también sirve, con la salvedad de que reconstruye y lee el secret vigente. El workflow_dispatch se retiró del workflow.

Consecuencias

Positivas

  • El registro de qué versión entró a producción es el historial de tags (git tag -l).
  • Rollback legible: «volvé a la v1.2.4», relanzando la corrida de ese tag.
  • Un tag puesto por error sobre una rama de feature falla en el guard con mensaje claro.
  • Alineado con el estándar de la organización (mismo modelo que el CMS).

Negativas / deuda asumida

  • Aparece un paso nuevo en el flujo (crear y pushear el tag) que el equipo debe incorporar.
  • Un push a main sigue sin desplegar nada — igual que antes; la confusión posible persiste hasta que el hábito del tag se asiente.
  • Sin required reviewers activos, quien taguea despliega: el control es el acto del tag, no una aprobación de segunda persona (activable en el Environment cuando haya separación de roles).