Déprécier une gem dans un projet, c'est comme retirer une pièce d'un mécanisme bien huilé — sans les précautions nécessaires, tout risque de s’écrouler. Mais chez Captive, nous avons élaboré un chemin clair et maitrisé pour la suppression de la gem data_migrate, qui garantira une transition en douceur dans vos projets Rails.
- Comment déplacer aisément vos versions de données existantes vers de nouvelles migrations
- Exploiter un script Bash pour automatiser le retrait de la gem data_migrate
- Les erreurs courantes à éviter pour garantir une transition sans heurts
- Initiatives concrètes de projets similaires chez Captive
Pourquoi cette transition est essentielle 🚀
Il est impératif de noter que la gem data_migrate est désormais dépréciée dans le Tech Radar 2025 de Captive. Cette situation oblige les développeurs et équipes techniques à anticiper ce changement pour éviter les surprises lors de leurs futurs déploiements. En prenant les mesures adéquates, vous vous assurez de ne pas être pris au dépourvu lors des migrations de données, cruciales pour votre application.
Le processus que nous proposons se divise en deux parties majeures, chacune composée de plusieurs étapes efficaces, afin de faciliter la transition depuis la gem data_migrate vers des pratiques plus performantes.
Les points clés pour réussir cette transition
Ce processus minutieux de suppression de la gem se divise en plusieurs phases cruciales :
Créer une migration pour migrer les versions existantes 🌤️
Avant tout, il vous faudra créer une migration spéciale pour déplacer les versions présentes dans data_migrations vers schema_migrations. Cette étape précède la suppression de la table importée par la gem. C'est aussi l'occasion de vérifier que rien n'est laissé au hasard en confirmant que toutes les versions ont été déplacées correctement. Pour ce faire, utilisez la commande en Ruby suivante :
ActiveRecord::Base.connection.execute("SELECT version FROM schema_migrations").map { |row| row['version'] }
C'est une manière de s'assurer que vos versions de données cruciales sont bel et bien transférées, et ce, exactement à l'endroit où elles doivent être.
Faire un premier déploiement 🚀
Après la migration des versions, vient un premier test de mise à jour. Cette vérification sur tous vos environnements sert d’échauffement pour la véritable mise en production, permettant de confirmer que rien n’a été oublié lors du transfert.
Écrire un script bash pour automatiser la suppression de la gem 🌤️
Le cœur de votre projet est son rythme d’évolution. Comme une horloge réglée, un script bash vous aidera à automatiser l’enlèvement de la gem data_migrate. Cela inclut de retirer la gem de votre Gemfile, de mettre à jour Gemfile.lock et de déplacer méthodiquement vos migratoires de db/data à db/migrate. Enfin, renommez les occurrences de db:migrate:with_data par db:migrate.
Rendre exécutable son fichier bash 🌤️
Quel est l'intérêt d'un script s’il n’est pas approprié adroitement? Rendre exécutable votre script avec chmod +x bin/nom-du-fichier
est l’étape finale pour garantir que tout est en ordre et prêt pour la suite.
Écrire une migration de suppression de la table data_migrations 🌤️
Enfin, une migration dédiée supprimera la table data_migrations elle-même. Cet acte de défaire le surplus garantit que votre base de données est propre de toute trace de la gem d'origine, rendant vos migrations plus claires et lisibles.
Faire un second déploiement 🚀
Le déploiement final s'assurer que vos nouvelles configurations fonctionnent comme prévu sur l'ensemble des environnements, consolidant tous les changements apportés.
Les erreurs type à éviter ❌
Comme tout projet technique exigeant, il est essentiel d’avancer avec prudence. Lors d’un déploiement chez Vesta, un faux pas nous a rappelé l'importance de ne pas regrouper toutes les étapes en une seule PR. Cette précipitation avait entraîné des doublons de migrations. Comprendre les leçons du passé aide à guider nos décisions futures avec plus de sagesse et d’efficacité.
Aller plus loin 🌱
Exemples : L’expérience de Vesta nous a permis de rédiger ce standard pour éviter les erreurs précédemment rencontrées, et nous avons documenté cette démarche dans ces PRs détaillées. Quand un problème de commande de migration est apparu, ce fut une opportunité d’innovation que nous avons saisie pour améliorer nos processus internes.
Prêt à discuter plus en détail de vos besoins en migration de données et bénéficier de notre expertise sur le sujet ?