Actualizando Ruby y Rails usando Dual-Booting

Técnicas para actualizar

Reescribir la app

• PAREN TODO!
• El scope es muy grande
• Son los tests 100% confiables?
• Simple para reescribir? simple para actualizar
• Sin plan, el problema vuelve
• No termina hasta que está completo

Actualizar a la versión más nueva

• Perdemos deprecation warnings
• Las guías oficiales son para versiones puntuales
• Automatizaciones
• El scope es grande

Actualizar a la versión siguiente

• Deprecation warnings nos guían
• Guías oficiales
• Automatizaciones
• Scope reducido

El mayor problema con todas estas técnicas: branch de upgrade

Qué es Dual-Booting?

• Permite ejecutar la aplicación en distintas versiones de Rails, Ruby (o cualquier gema) sin cambiar branches.
• Bundler carga las gemas listadas en el archivo Gemfile.lock por defecto, pero se puede cambiar con la variable de entorno BUNDLE_GEMFILE.
• Podemos ejecutar código diferente dependiendo de la versión en una misma codebase.
• Soluciona el problema del branch de upgrade y permite hacer merge de código para la próxima versión.
• Permite a todos familiarizarse con código más moderno durante el proceso.

Ejemplo práctico

• Gemfile vs Gemfile.next
• Crear el archivo Gemfile.next
• Crear el archivo Gemfile.next.lock
• Condicionales en el Gemfile
• Condicionales en el código

El final del upgrade

• Reemplazar Gemfile.lock
• Borrar condicionales
• Cualquier task que corresponda
• Dual boot con la versión siguiente

Actualizar Ruby

• No alcanza con la variable BUNDLE_GEMFILE
• Docker Compose
• No siempre se necesita un Gemfile.next, pero en muchos casos si