Mettre à jour Ruby on Rails : ce qui casse et comment l'éviter

Une montée de version Rails échoue rarement à cause d'une incompatibilité spectaculaire. Elle échoue parce que plusieurs petites choses s'accumulent : une version sautée, un gem qui n'est plus maintenu, une suite de tests incapable de dire si quelque chose a cassé. Voici l'approche que nous utilisons pour que la montée de version reste ennuyeuse.

Monter une version mineure à la fois

Passer d'une vieille version directement à la dernière paraît efficace et c'est la cause la plus fréquente d'une migration qui s'enlise. Chaque version mineure déprécie des comportements que la suivante supprime. Avancer pas à pas signifie que chaque avertissement de dépréciation que vous corrigez est encore pertinent, et que chaque échec pointe vers un petit changement récent.

Rendre les tests fiables d'abord

Avant de toucher au Gemfile, vérifiez que la suite de tests est verte et qu'elle couvre les parcours qui comptent : connexion, paiements, jobs en arrière-plan, principaux chemins d'écriture. Si la couverture est mince, consacrez les premiers jours à ajouter des tests de caractérisation autour du code le plus risqué. Une montée de version sans ce filet de sécurité est un pari dont vous découvrez la perte en production.

Faire tourner les deux versions côte à côte

Un dual-boot permet à la même application de tourner avec la version actuelle et la version suivante de Rails, ce qui permet de corriger les incompatibilités sur la branche principale, en petits commits, pendant que la production reste sur l'ancienne version. Une condition dans le Gemfile suffit pour démarrer :

if ENV["NEXT_RAILS"] == "1"
  gem "rails", "~> 7.1.0"
else
  gem "rails", "~> 7.0.0"
end

Lancez la suite dans les deux modes dans votre CI. La branche verte sur les deux peut être fusionnée en continu, et le basculement final devient un changement d'une ligne.

Lire les avertissements de dépréciation avant de monter

La plupart des changements cassants s'annoncent une version à l'avance. Activez le rapport de dépréciations en test et en développement, collectez les avertissements et corrigez-les tant que vous êtes sur l'ancienne version. La montée de version supprime alors très peu de ce que vous utilisiez encore.

S'attendre à des problèmes venant des gems, pas de Rails

Le framework est généralement la partie facile. Le plus dur, c'est un gem qui fige une ancienne version de Rails, qui a été abandonné ou qui modifie des éléments internes. Pour chaque dépendance, vérifiez s'il existe une version compatible, une alternative maintenue, ou si la fonctionnalité est assez petite pour être reprise en interne. Faites cet inventaire dès le départ : c'est lui qui détermine le vrai calendrier.

Déplacer les valeurs par défaut du framework séparément

Lancer la tâche de mise à jour génère des initialiseurs qui contiennent les nouvelles valeurs par défaut de la version cible. Résistez à l'envie de tout activer d'un coup. Gardez les anciennes valeurs, livrez la montée de version, puis activez les nouvelles valeurs une par une, chacune avec son propre déploiement. Si un comportement change, vous savez exactement quel réglage en est la cause.

Planifier la montée de Ruby comme une étape à part

Les versions de Ruby et de Rails sont liées, mais ce sont deux risques différents. Montez Ruby lorsque la version actuelle de Rails le supporte, livrez-le seul, et ne montez Rails qu'ensuite. Deux petits changements que l'on peut annuler séparément sont plus sûrs qu'un gros changement que l'on ne peut pas annuler.

Déployer comme tout autre changement risqué

Déployez d'abord sur un seul environnement, surveillez le suivi des erreurs et les performances pendant une journée, et gardez la version précédente à une commande de distance. Les migrations de base de données qui accompagnent la montée de version doivent suivre les mêmes règles que les autres : pas de verrous longs, pas de changements qui bloquent la version précédente, comme décrit dans notre article sur les migrations sans interruption.

Une montée de version est plus simple quand on connaît bien son point de départ. Un court audit Rails vous donne l'inventaire des dépendances, les trous dans les tests et un ordre de travail réaliste avant de vous engager sur un calendrier.