Najlepsza praktyka do aktualizacji serwera gier online?

Question

Załóżmy, że mam uruchomioną grę online i jej wersję 1.0.

Ciągle rozwijam się na serwerze testowym i wprowadzam nowe funkcje do gry. Serwer pomostowy jest oddzielnym serwerem od serwera na żywo. (Jestem pewien, że większość ludzi robi to w ten sposób)

OK. Kończę nową wersję 1.1. Jaka jest najlepsza praktyka do uaktualnienia serwera gier online?

Załóżmy, że jest to prosty serwer PHP + MYSQL. Pojawiły się więc nowe skrypty php lub zmienione skrypty oraz nowe tabele, kolumny lub zmodyfikowane kolumny mysql. Mam nadzieję, że nie zrobię tego ręcznie - ręcznie wykonuj te same zmiany jeden po drugim na serwerze na żywo. To jest brzydkie i łatwe do popełnienia błędu i pamiętaj o każdej zmianie, którą zrobiłeś.

Innym sposobem, jaki przychodzi mi na myśl, jest sprawdzenie, czy serwer pomostowy jest aktywny i importowanie wszystkich istniejących danych bazy danych. Nie podoba mi się to, wydaje się, że błąd może się zdarzyć w każdej chwili.

Jaki jest najlepszy sposób, aby polecić?

Answer 1

• Kontrola wersji - użyj go!
• Migracje - użyj!

kontroli wersji (GIT)

Trzeba serwer git na serwerze na żywo, a także, jak na etapie testowania/serwer. Będziesz popełniał zmiany, które wprowadzisz, a następnie "popchniesz" te zmiany/zmiany na serwer. Gdy serwer testowy zadziała, należy go przekazać na serwer live.

Migracje

Większość nowoczesnych frameworków PHP oferują tę funkcję. Zasadniczo opisałbyś swój schemat bazy danych w kodzie. Z Laravelem można uruchomić: artisan migrate lub coś, co popchnie schemat do bazy danych.

Tylko z jedną bazą danych i jednym serwerem WWW możesz uniemożliwić dostęp publiczności do nich, dopóki nie zostanie zaktualizowany, dotyczy to głównie bazy danych i potrwa tylko kilka sekund, ale zapobiegnie błędom podczas migracji. Prosty podnośnik z git mógłby zrobić lewę. W Internecie jest mnóstwo informacji na ten temat.

Answer 2

Słyszałem, że SharePoint sprawia, że ​​front-end obsługuje starą i nową bazę danych. Następnie najpierw zaktualizuj cały kod front-end i użyj starej bazy danych. Gdy wszyscy użytkownicy skorzystają z nowego kodu front-end, zaktualizuj bazę danych. Po zakończeniu aktualizacji można usunąć obsługę starej bazy danych i ponownie wykonać tę samą sztuczkę dla następnej wersji.

W ten sposób masz minimalny czas przestojów ze zrównoważonym obciążeniem front-endem.

Może sprawiły, że zabrzmiało to łatwiej niż jest, ale lubię tę zasadę.

Answer 3

Utwórz skrypt aktualizacji bazy danych. Najlepiej wygeneruj go za pomocą narzędzia.

Utwórz pakiet wersji dla wersji 1.0, jeśli jeszcze tego nie zrobiłeś. Utwórz pakiet aktualizacji oraz skrypt wdrażania w wersji 1.1, który poprawi wersję produkcyjną z wersji 1.0 na 1.1

Dla inspiracji, w jaki sposób zaktualizować istniejącą instalację można spojrzeć na How Wordpress upgrades:

1. Pobierz pakiet aktualizacji i rozpakować go do katalogu tymczasowego
2. Sprawdź, czy plik rozpakowany!
3. Ułóż komunikat "W dół do konserwacji"
4. Skopiuj nowe pliki. Jest to prosta kopia/zamiana. Nie usuwać.
5. Uaktualnienie bazy danych, jeśli nie jest jeszcze aktualne
6. Usuń rozpakowane pliki z katalogu tymczasowego
7. Usuń wiadomość
8. „nieczynny” Usuń stare pliki. Przegląda listę wycofanych i nieużywanych plików i usuwa je.

Odtworzyć maszynę produkcyjną w środowisku pomostowym przy użyciu pakietu wersji 1.0 i przetestować instalację pakietu uaktualnień, dopóki nie będziesz usatysfakcjonowany przed uruchomieniem.

Tworzenie kopii zapasowych, ulepszanie produkcji.