Migrar una plataforma en producción de Symfony 5.4 a Symfony 8

Migrar una plataforma en producción de Symfony 5.4 a Symfony 8

Contexto

MasMusculo/MMfit es una plataforma de gestión de gimnasios construida sobre Symfony, usada a diario por gimnasios reales para gestionar altas, reservas y facturación. Corría sobre Symfony 5.4, una versión que se acercaba al fin de su soporte, sobre una base de código que había acumulado años de atajos típicos de un producto que creció más rápido que su propio tooling.

Saltar cuatro versiones mayores (5.4 → 6 → 7 → 8) en una base de código así, siendo el único desarrollador, con la plataforma en producción y uso diario, es un problema muy distinto a migrar un proyecto pequeño y bien testado.

El problema de saltarse versiones

La tentación con una base de código heredada es buscar la forma de saltar directamente de la 5.4 a la 8 y acabar cuanto antes. En la práctica eso casi siempre sale mal:

• Cada versión mayor de Symfony elimina APIs previamente marcadas como deprecadas. Si te saltas una versión, pierdes los avisos de deprecación que te habrían dicho exactamente qué arreglar antes de que se convirtiera en una rotura real.
• Los bundles de terceros raramente soportan más de una o dos versiones mayores por delante de la que fueron pensados, así que un salto grande obliga a sustituir varios bundles a la vez en lugar de uno en uno.
• Cuando algo se rompe tras un salto de cuatro versiones, no hay forma de saber cuál de las cuatro introdujo la regresión.

Estrategia: una versión mayor cada vez

El enfoque que de verdad funcionó fue deliberadamente poco espectacular:

1. Subir solo a la siguiente versión mayor, dejando todo lo demás igual.
2. Ejecutar la app en local y en staging, corregir cada aviso de deprecación que el propio Symfony reporta, y solo entonces continuar.
3. Pasar los tests de regresión existentes, más una revisión manual de los flujos críticos (altas, reservas, pagos) antes de cada despliegue.
4. Desplegar ese único salto de versión a producción, vigilar logs y seguimiento de errores unos días, y entonces empezar con la siguiente versión.

Es más lento que un único salto grande, pero cada paso es lo bastante pequeño como para entenderlo y revertirlo si algo falla, y la plataforma nunca tuvo que caerse por ello.

Lecciones aprendidas

• Los avisos de deprecación son una lista de tareas, no ruido. Tratar cada aviso como algo que arreglar antes de la siguiente subida convirtió una migración de por sí arriesgada en una lista de comprobación predecible.
• El código heredado con poca cobertura de tests necesita una red de seguridad humana. Donde todavía no había tests automáticos, una breve lista manual de los flujos críticos de la plataforma detectó problemas que de otro modo habrían llegado a gimnasios reales.
• Hacerlo como único desarrollador es tanto un problema de planificación como técnico. Espaciar las cuatro subidas en el tiempo, en vez de intentar agruparlas, mantuvo cada cambio revisable y la plataforma estable durante todo el proceso.

El resultado: MasMusculo/MMfit corre hoy sobre Symfony 8, migrado sin tiempo de inactividad y sin regresiones reportadas por los gimnasios que la usan a diario.