Migraties die de productie niet platleggen
Een migratie draait perfect op jouw machine. Je voert hem uit op vrijdag om 18:00 uur omdat het klein lijkt. Dan bevriest de deployment. Of erger nog: een tabel met 8 miljoen rijen blokkeert voor 40 seconden en je site crasht.
Migraties gedragen zich anders in productie. Lokale databases zijn leeg en snel. Productiedatabases bevatten echte data en actieve gebruikers.
Volg deze regels om rampen in productie te voorkomen.
Schrijf altijd een werkende down-methode Elke migratie heeft een up- en een down-functie nodig. De down-functie moet de up-functie exact omkeren. Als je geen rollback kunt schrijven, is je migratie te complex. Test het op je machine met
migrategevolgd doormigrate:rollbackvoordat je pusht.Pas nooit oude migraties aan Misschien wil je de grootte van een kolom in een oud migratiebestand aanpassen. Doe dit niet. Laravel zal dat bestand niet opnieuw uitvoeren op de server. Maak in plaats daarvan een nieuwe migratie aan om de structuur te wijzigen. Een migratie is een geschiedenis van wijzigingen. Je voegt nieuwe hoofdstukken toe in plaats van oude te herschrijven.
Gebruik nullable of standaardwaarden Het toevoegen van een NOT NULL-kolom aan een tabel met bestaande data veroorzaakt fouten. De database weet niet wat hij in de oude rijen moet plaatsen.
Gebruik in plaats daarvan deze aanpak: • Maak de nieuwe kolom nullable. • Stel een standaardwaarde (default value) in. • Als de kolom verplicht moet zijn, doe dit dan in drie stappen: maak hem nullable, vul de data in, en verander hem dan naar NOT NULL.
Gegevensverlies is permanent Het
dropColumn-commando verwijdert data voorgoed. Een rollback kan een kolom opnieuw aanmaken, maar de data erin is weg. Controleer je back-ups voordat je een kolom verwijdert. Een veiligere manier is om de kolom eerst niet meer te gebruiken in je code, een paar weken te wachten en deze vervolgens uit de database te verwijderen.Scheid schema-wijzigingen van data-updates Het uitvoeren van
User::all()binnen een migratie kan miljoenen rijen in het geheugen laden en je deployment laten crashen. Als je tijdens een migratie data moet bijwerken, gebruik danchunkByIdom records in kleine batches te verwerken.Gebruik de force-flag in pipelines Geautomatiseerde deployment-pipelines blijven hangen als Laravel om bevestiging vraagt. Gebruik dit commando in je deployment-scripts:
php artisan migrate --forceLet op tabelblokkeringen Het wijzigen van een kolom of het toevoegen van een index op een enorme tabel blokkeert die tabel. Dit veroorzaakt downtime. Kijk voor zeer grote tabellen naar 'online schema change'-tools of voer wijzigingen uit tijdens uren met weinig verkeer.
Checklist voordat je pusht: • Werkt de down-methode? • Heb ik de rollback lokaal getest? • Maak ik een nieuwe migratie aan in plaats van een oude aan te passen? • Is de nieuwe kolom nullable of heeft deze een standaardwaarde? • Heb ik een back-up voordat ik kolommen verwijder?
Bron: https://dev.to/denisgusto1/migrations-que-nao-quebram-em-producao-o-guia-que-ninguem-te-deu-363o
