Za każdym razem, gdy to robię, wybieramy dwa przejścia ...
- zrób migawkę i pracując na innym serwerze, użyj tego, aby określić, co należy zrobić dla migracji, i wykonaj skrypt.
- kiedy już mają skrypt w ręku, sklep snapshop jest przywracany w systemie testowym, a jego czas sprawdza, czy uruchomi się w wymaganym czasie, czy jest dostrojony i modyfikowany, dopóki nie będzie mógł.
- niech zainteresowane strony podpiszą, że dane w systemie testowym nie wyglądają źle.
Następnie przez weekend masz zaplanowane przerwy:
- W piątek wieczorem systemy korzystające z bazy danych zostają wyłączone, wykonywana jest pełna zimna kopia zapasowa, a skrypty są uruchamiane w celu migracji / modyfikacji / czegokolwiek do danych
- Systemy są przywracane pod jakimś prywatnym adresem lub w jakiś sposób skonfigurowane, więc nie są otwarte dla nikogo oprócz interesariuszy do testów akceptacyjnych
- Jeśli zainteresowane strony wyrażą na to zgodę, system zostaje udostępniony online i upubliczniony; jeśli nie, baza danych zostanie przywrócona z kopii zapasowej wykonanej w piątek wieczorem i proces rozpocznie się od nowa.
Zgodnie z naszym harmonogramem ludzie z bazy danych zwykle mieli od 18:00 w piątek do 10 rano w sobotę na uruchomienie skryptów tworzenia kopii zapasowych i migracji, więc naszym celem było uruchomienie ich w ciągu 8 godzin (~ 6 z nich to kopie zapasowe), więc „ d mieć trochę czasu na nasze testy i poprawki, zanim zostaną udostępnione interesariuszom.
Zainteresowanym stronom podano z góry swoje okna czasowe, więc wiedzieli, że pozostawiają weekend otwarty na testy na początku okna. Powiedziano im także koniec okna, zwykle w niedzielne popołudnie, gdzie gdyby wszyscy się nie wypisali, musielibyśmy się wycofać.
Aha i oczywiście ... jeśli ktoś miał zmianę podczas jednego z testów akceptacyjnych, a my dokonaliśmy zmiany, oznaczało to, że wszystkie podpisy interesariuszy zostały unieważnione i musieli ponownie przetestować ... więc staramy się dać im wszystkim chwilę na poszukiwanie problemów i przeprowadzanie korekt jako partii, zamiast stosować je pojedynczo.
Na szczęście jedyne sytuacje, w których miałem jedną z tych sytuacji, w których nie mogliśmy mieć znacznego przestoju, systemy, które migrowałem, były zasilane ze skryptów, a nie ze strony użytkownika, więc mogłem po prostu uruchomić dwa równoległe systemy i wymienić je kiedy wszystko się wypisało. (tylko raz pojawił się problem, gdy mój szef nalegał, abyśmy wzięli pełną kopię zapasową, nie rozumiejąc, że cała sprawa będzie nadal dostępna online pod innym adresem IP ... więc co powinno być 5-minutowym przestojem na zły dzień stał się przerwą na 5 godzin).
