Myślę, że ten problem ma dwie części.
Pierwszym z nich jest zarządzanie schematem bazy danych i jego zmianami. Robimy to za pomocą South, przechowując zarówno działające modele, jak i pliki migracji w naszym repozytorium SCM. Ze względów bezpieczeństwa (lub paranoi) wykonujemy zrzut bazy danych przed (a jeśli naprawdę się boimy, po) uruchamianiu jakichkolwiek migracji. Południe spełnia wszystkie nasze dotychczasowe wymagania.
Drugi to wdrożenie zmiany schematu, która wykracza poza samo uruchomienie pliku migracji wygenerowanego przez South. Z mojego doświadczenia wynika, że zmiana bazy danych zwykle wymaga zmiany wdrożonego kodu. Jeśli masz nawet małą farmę sieciową, utrzymywanie wdrożonego kodu w synchronizacji z bieżącą wersją schematu bazy danych może nie być trywialne — sytuacja się pogarsza, jeśli weźmiesz pod uwagę różne warstwy pamięci podręcznej i wpływ na już aktywnego użytkownika witryny. Różne witryny w różny sposób radzą sobie z tym problemem i nie sądzę, aby istniała jedna odpowiedź dla wszystkich.
Rozwiązanie drugiej części tego problemu niekoniecznie jest proste. Nie wierzę, że istnieje podejście uniwersalne, a informacji o Twojej witrynie i środowisku nie ma wystarczająco dużo, aby zasugerować rozwiązanie, które byłoby najbardziej odpowiednie dla Twojej sytuacji. Myślę jednak, że istnieje kilka kwestii, o których należy pamiętać, aby pomóc we wdrażaniu w większości sytuacji.
W niektórych przypadkach możliwe jest przełączenie całej witryny (serwerów internetowych i bazy danych) w tryb offline. Jest to z pewnością najprostszy sposób zarządzania aktualizacjami. Jednak częste przestoje (nawet jeśli są zaplanowane) mogą być dobrym sposobem na szybkie rozpoczęcie działalności, sprawiają, że wdrażanie nawet niewielkich zmian w kodzie jest męczące i może zająć wiele godzin, jeśli masz duży zestaw danych i/lub złożoną migrację. To powiedziawszy, w przypadku witryn, którymi pomagam zarządzać (które są wewnętrzne i ogólnie używane tylko w godzinach pracy w dni robocze) to podejście działa cuda.
Zachowaj ostrożność, jeśli wprowadzasz zmiany w kopii swojej głównej bazy danych. Głównym problemem jest to, że Twoja witryna nadal działa i prawdopodobnie akceptuje zapisy do bazy danych. Co dzieje się z danymi zapisanymi w głównej bazie danych, gdy jesteś zajęty migracją klonu do późniejszego użycia? Twoja witryna musi być przez cały czas niedostępna lub tymczasowo przełączona w stan tylko do odczytu, w przeciwnym razie je stracisz.
Jeśli Twoje zmiany są kompatybilne wstecz i masz farmę internetową, czasami możesz uciec od aktualizacji działającego produkcyjnego serwera bazy danych (co moim zdaniem jest nieuniknione w większości sytuacji), a następnie stopniowo aktualizować węzły w farmie, usuwając je z load balancer na krótki okres. To może działać dobrze - jednak głównym problemem jest to, że jeśli węzeł, który został już zaktualizowany, wyśle żądanie adresu URL, który nie jest obsługiwany przez starszy węzeł, otrzymasz błąd, ponieważ nie możesz nim zarządzać na poziomie równoważenia obciążenia.
Widziałem/słyszałem, że kilka innych sposobów działa dobrze.
Pierwszym z nich jest owinięcie wszystkich zmian kodu w blokadę funkcji, którą można następnie skonfigurować w czasie wykonywania za pomocą niektórych opcji konfiguracyjnych dla całej witryny. Zasadniczo oznacza to, że możesz zwolnić kod, w którym wszystkie zmiany są wyłączone, a następnie po dokonaniu wszystkich niezbędnych aktualizacji na serwerach zmienić opcję konfiguracji, aby włączyć tę funkcję. Ale to sprawia, że kod jest dość ciężki...
Drugi to pozwolenie kodowi na zarządzanie migracją. Słyszałem o witrynach, w których zmiany w kodzie są napisane w taki sposób, aby obsługiwały migrację w czasie wykonywania. Jest w stanie wykryć używaną wersję schematu i format danych, które odzyskał - jeśli dane pochodzą ze starego schematu, wykonuje migrację na miejscu, jeśli dane pochodzą już z nowego schematu, nie robi nic . Z naturalnego korzystania z witryny duża część Twoich danych zostanie przeniesiona przez osoby korzystające z witryny, resztę możesz zrobić za pomocą skryptu migracji, kiedy tylko chcesz.
Ale myślę, że w tym momencie Google staje się twoim przyjacielem, ponieważ, jak mówię, rozwiązanie jest bardzo specyficzne dla kontekstu i obawiam się, że ta odpowiedź zacznie tracić sens… Wyszukaj coś w stylu „wdrożenie z zerowym czasem przestoju”, a ty” Otrzymam wyniki, takie jak to z mnóstwem pomysłów...
