N.º 038 sin filtro, sin manual, sin PR BOGOTÁ · 2026·08·03
sin filtro
← volver al diario
ingeniería · método

Modernizar lo heredado: de Rails 7 a 8 sin que el usuario lo note

Subimos un producto que mantenemos de Rails 7.1 a 8 y de Ruby 3.2 a 3.4. Lo difícil no fue el salto; fue todo lo que el salto destapó.

N.º 038 BOGOTÁ 2026·06·11 por e. hernández

Mantenemos un producto que heredamos, y tocaba subirlo: Rails 7.1 a 8, Ruby 3.2 a 3.4. El salto de versión es un párrafo en el changelog. El trabajo real fue todo lo que el salto dejó al descubierto.

lo que se rompió

Un caché de segundo nivel que nadie usaba pero parchaba ActiveRecord a nivel global — y reventaba en Rails 8. Predicados de consulta que cambiaron de forma entre versiones. Un esquema de API que ahora hay que materializar al arranque. Un archivo de secretos que Rails 8 ya no lee. Cada uno fue un 500 distinto esperando en producción.

Ninguno era el 'upgrade’. Eran deuda vieja que el upgrade volvió visible de golpe.

Modernizar no es saltar de versión. Es pagar la deuda que el salto te obliga a ver.

Al final el producto sirve exactamente igual que ayer. Esa es la meta de una migración bien hecha: que por fuera no pase nada. El recibo está adentro —en el Dockerfile nuevo, en las pruebas que ahora corren, en los 500 que ya no van a pasar.