🎯 Pourquoi faire cela ?

La gem data_migrate est désormais dépréciée dans le Captive Tech radar 2025. Ce guide vous aide à la retirer proprement de vos projets tout en assurant une transition sans erreur pour les migrations de données.

<aside> ✅

Pré-requis

• Avoir connaissance du standard ‣
• Savoir à quoi sert une version dans les migrations https://guides.rubyonrails.org/active_record_migrations.html#rails-migration-version-control </aside>

✅ Points clés

<aside> ⌛ Temps indicatif :

</aside>

Ce travail de suppression va se diviser en 2 parties soit deux PR à mettre en production distinctement. La première consiste à transférer les données de version de la table data_migrations vers la table schema_migrations et la seconde à supprimer la gem data_migrate ainsi que la table data_migrations

🌤️ Créer une migration pour migrer les versions existantes

🚀 Faire un premier déploiement

🌤️ Écrire un script bash pour automatiser la suppression de la gem

🌤️ Rendre exécutable son fichier bash

🌤️ Écrire une migration de suppression de la table data_migrations

🚀 Faire un second déploiement

❌ Erreurs type à éviter

• Faire une seule mise en production

  Sur Vesta, nous avons rencontré un problème de migration lors du déploiement en staging lorsque nous avons tout mis dans une seule et même PR. La migration repassait sur toutes les migrations ayant été déplacées alors que ces versions avaient bien été ajouté dans la table schema_migrations