Migrazioni che non rompono la produzione

Una migrazione gira perfettamente sulla tua macchina. La distribuisci un venerdì alle 18:00 perché sembra piccola. Poi il deployment si blocca. O peggio, una tabella con 8 milioni di righe si blocca per 40 secondi e il tuo sito va in crash.

Le migrazioni si comportano diversamente in produzione. I database locali sono vuoti e veloci. I database di produzione contengono dati reali e utenti attivi.

Segui queste regole per evitare disastri in produzione.

  • Scrivi sempre un metodo down funzionante Ogni migrazione ha bisogno di una funzione up e una down. La funzione down deve invertire esattamente la funzione up. Se non riesci a scrivere un rollback, la tua migrazione è troppo complessa. Testala sulla tua macchina con migrate seguito da migrate:rollback prima di fare il push.

  • Non modificare mai le vecchie migrazioni Potresti voler correggere la dimensione di una colonna in un vecchio file di migrazione. Non farlo. Laravel non eseguirà di nuovo quel file sul server. Invece, crea una nuova migrazione per modificare la struttura. La migrazione è una cronologia di cambiamenti. Aggiungi nuovi capitoli invece di riscrivere quelli vecchi.

  • Usa valori nullable o di default Aggiungere una colonna NOT NULL a una tabella con dati esistenti causa errori. Il database non sa cosa inserire nelle vecchie righe.

Usa invece questi approcci: • Rendi la nuova colonna nullable. • Imposta un valore di default. • Se la colonna deve essere obbligatoria, procedi in tre passaggi: creala come nullable, inserisci i dati e poi cambiala in NOT NULL.

  • La perdita di dati è permanente Il comando dropColumn elimina i dati per sempre. Un rollback può ricreare una colonna, ma i dati al suo interno sono andati perduti. Prima di eliminare una colonna, verifica i tuoi backup. Un modo più sicuro è smettere prima di usare la colonna nel codice, aspettare qualche settimana e poi rimuoverla dal database.

  • Separa le modifiche allo schema dagli aggiornamenti dei dati Eseguire User::all() all'interno di una migrazione può caricare milioni di righe in memoria e far crashare il deployment. Se devi aggiornare i dati durante una migrazione, usa chunkById per elaborare i record in piccoli lotti.

  • Usa il flag --force nelle pipeline Le pipeline di deployment automatizzate si bloccheranno se Laravel richiede una conferma. Usa questo comando nei tuoi script di deployment: php artisan migrate --force

  • Attenzione ai lock delle tabelle Modificare una colonna o aggiungere un indice su una tabella massiccia blocca quella tabella. Questo causa downtime. Per tabelle molto grandi, valuta l'uso di strumenti di online schema change o esegui le modifiche durante le ore di basso traffico.

Checklist prima del push: • Il metodo down funziona? • Ho testato il rollback localmente? • Sto creando una nuova migrazione invece di modificarne una vecchia? • La nuova colonna è nullable o ha un valore di default? • Ho un backup prima di eliminare le colonne?

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