Migracje, które nie zepsują produkcji

Migracja działa idealnie na Twoim komputerze. Wdrażasz ją w piątek o 18:00, bo wydaje się mała. Nagle proces wdrożenia zostaje zawieszony. Albo co gorsza, tabela z 8 milionami wierszy blokuje się na 40 sekund i Twoja strona przestaje działać.

Migracje zachowują się inaczej na produkcji. Lokalne bazy danych są puste i szybkie. Produkcyjne bazy danych mają realne dane i aktywnych użytkowników.

Przestrzegaj tych zasad, aby uniknąć katastrof na produkcji.

  • Zawsze pisz działającą metodę down Każda migracja potrzebuje funkcji up i down. Funkcja down musi dokładnie odwracać funkcję up. Jeśli nie potrafisz napisać rollbacku, Twoja migracja jest zbyt skomplikowana. Przetestuj ją na swoim komputerze za pomocą migrate, a następnie migrate:rollback przed wypchnięciem zmian.

  • Nigdy nie edytuj starych migracji Możesz chcieć zmienić rozmiar kolumny w starym pliku migracji. Nie rób tego. Laravel nie uruchomi ponownie tego pliku na serwerze. Zamiast tego utwórz nową migrację, aby zmienić strukturę. Migracja to historia zmian. Dodajesz nowe rozdziały zamiast przepisywać stare.

  • Używaj wartości nullable lub domyślnych Dodanie kolumny NOT NULL do tabeli z istniejącymi danymi powoduje błędy. Baza danych nie wie, co wstawić w starych wierszach.

Zamiast tego zastosuj poniższe podejścia: • Spraw, aby nowa kolumna była nullable. • Ustaw wartość domyślną. • Jeśli kolumna musi być wymagana, zrób to w trzech krokach: utwórz ją jako nullable, uzupełnij dane, a następnie zmień na NOT NULL.

  • Utrata danych jest nieodwracalna Polecenie dropColumn usuwa dane na zawsze. Rollback może odtworzyć kolumnę, ale dane wewnątrz przepadły. Zanim usuniesz kolumnę, zweryfikuj swoje kopie zapasowe. Bezpieczniejszym sposobem jest najpierw zaprzestanie używania kolumny w kodzie, odczekanie kilku tygodni, a dopiero potem usunięcie jej z bazy danych.

  • Oddziel zmiany schematu od aktualizacji danych Uruchomienie User::all() wewnątrz migracji może załadować miliony wierszy do pamięci i spowodować awarię wdrożenia. Jeśli musisz zaktualizować dane podczas migracji, użyj chunkById, aby przetwarzać rekordy w małych partiach.

  • Używaj flagi --force w potokach Zautomatyzowane potoki wdrożeniowe zawisną, jeśli Laravel poprosi o potwierdzenie. Użyj tej komendy w swoich skryptach wdrożeniowych: php artisan migrate --force

  • Uważaj na blokady tabel Zmiana kolumny lub dodanie indeksu w ogromnej tabeli blokuje tę tabelę. Powoduje to przestój. W przypadku bardzo dużych tabel rozważ narzędzia do online schema change lub wykonuj zmiany w godzinach niskiego natężenia ruchu.

Lista kontrolna przed wypchnięciem zmian: • Czy metoda down działa? • Czy przetestowałem rollback lokalnie? • Czy tworzę nową migrację zamiast edytować starą? • Czy nowa kolumna jest nullable lub ma wartość domyślną? • Czy mam kopię zapasową przed usunięciem kolumn?

Źródło: https://dev.to/denisgusto1/migrations-que-nao-quebram-em-producao-o-guia-que-ninguem-te-deu-363o