Des migrations qui ne casseront pas la production

Une migration fonctionne parfaitement sur votre machine. Vous la déployez un vendredi à 18h car elle semble mineure. Puis le déploiement se fige. Ou pire, une table de 8 millions de lignes se verrouille pendant 40 secondes et votre site plante.

Les migrations se comportent différemment en production. Les bases de données locales sont vides et rapides. Les bases de données de production contiennent des données réelles et des utilisateurs actifs.

Suivez ces règles pour éviter les catastrophes en production.

  • Écrivez toujours une méthode down fonctionnelle Chaque migration nécessite une fonction up et une fonction down. La fonction down doit inverser exactement la fonction up. Si vous ne pouvez pas écrire de rollback, votre migration est trop complexe. Testez-la sur votre machine avec migrate suivi de migrate:rollback avant de la pousser.

  • Ne modifiez jamais les anciennes migrations Vous pourriez vouloir corriger la taille d'une colonne dans un ancien fichier de migration. Ne faites pas cela. Laravel ne réexécutera pas ce fichier sur le serveur. Créez plutôt une nouvelle migration pour modifier la structure. Une migration est un historique de changements. Vous ajoutez de nouveaux chapitres au lieu de réécrire les anciens.

  • Utilisez des valeurs nullable ou par défaut L'ajout d'une colonne NOT NULL à une table contenant déjà des données provoque des erreurs. La base de données ne sait pas quoi insérer dans les anciennes lignes.

Utilisez plutôt ces approches : • Rendez la nouvelle colonne nullable. • Définissez une valeur par défaut. • Si la colonne doit être obligatoire, procédez en trois étapes : créez-la en tant que nullable, remplissez les données, puis passez-la en NOT NULL.

  • La perte de données est permanente La commande dropColumn supprime les données pour toujours. Un rollback peut recréer une colonne, mais les données qu'elle contenait sont perdues. Avant de supprimer une colonne, vérifiez vos sauvegardes. Une méthode plus sûre consiste à arrêter d'utiliser la colonne dans votre code d'abord, à attendre quelques semaines, puis à la supprimer de la base de données.

  • Séparez les changements de schéma des mises à jour de données Exécuter User::all() à l'intérieur d'une migration peut charger des millions de lignes en mémoire et faire planter votre déploiement. Si vous devez mettre à jour des données lors d'une migration, utilisez chunkById pour traiter les enregistrements par petits lots.

  • Utilisez le flag --force dans les pipelines Les pipelines de déploiement automatisés se bloqueront si Laravel demande une confirmation. Utilisez cette commande dans vos scripts de déploiement : php artisan migrate --force

  • Attention aux verrous de table (table locks) Modifier une colonne ou ajouter un index sur une table massive verrouille cette table. Cela provoque une interruption de service (downtime). Pour les tables très volumineuses, renseignez-vous sur les outils de changement de schéma en ligne (online schema change) ou effectuez les changements pendant les heures de faible trafic.

Checklist avant de pousser : • La méthode down fonctionne-t-elle ? • Ai-je testé le rollback localement ? • Est-ce que je crée une nouvelle migration au lieu de modifier une ancienne ? • La nouvelle colonne est-elle nullable ou possède-t-elle une valeur par défaut ? • Ai-je une sauvegarde avant de supprimer des colonnes ?

Source: https://dev.to/denisgusto1/migrations-que-nao-quebram-em-producao-o-guia-que-ninguem-te-deu-363o