Wszelkie pomysły na prowadzenie konserwacji w witrynie, która jest zawsze w użyciu?

Pomagam w dużej witrynie z grami w Australii. Prowadzimy konkursy od godziny 7 rano czasu lokalnego do godziny 1:00 następnego dnia, każdego dnia tygodnia. Nie opuściliśmy dnia od czasu wydania strony. Naturalnie sprawia to, że konserwacja jest niezwykle trudna do przeprowadzenia, i okazuje się, że nasz serwer pomostowy ma do 50 zatwierdzeń przed naszym oddziałem produkcyjnym. Zwykle główny programista musi wstawać bardzo wcześnie, aby połączyć gałęzie i upewnić się, że wszystko działa poprawnie.

Staramy się, aby nasza witryna pomostowa była jak najbardziej podobna do witryny produkcyjnej, ale możemy tylko uczynić ją tak podobną.

Nasza strona oparta jest na Laravel z serwerem Node.JS w czasie rzeczywistym. Używamy Kuźni Laravel.

Czy ktoś ma jakieś sugestie, w jaki sposób możemy częściej przekazywać aktualizacje? Jesteśmy otwarci na wszystko.

Istnieje wiele rzeczy, które możesz zrobić, aby usprawnić proces wdrażania. Kilka z nich to:

• Upewnij się, że kod jest dobrze przetestowany.

  Idealnie powinieneś mieć 100% pokrycie testem jednostkowym, a także testy integracyjne dla każdego możliwego scenariusza.

  Jeśli nie masz tego, prawdopodobnie powinieneś porzucić wszystko i zająć się tym.

  Spójrz na rozwój oparty na zachowaniu.

  Posiadanie pełnego zestawu testów pozwoli Ci ...

• Uruchom ciągłą integrację.

  Ilekroć ktoś dokonuje zmiany, CI może wtedy automatycznie uruchomić na nim pakiet testowy. Jeśli pakiet testowy przejdzie pomyślnie, można go natychmiast wdrożyć (lub zaplanować wdrożenie). W przypadku zmian, które nie wymagają znaczących zmian w bazach danych, samo to pozwoli Ci zaoszczędzić dużo czasu i bólu głowy.

  W przypadku problemu CI może również cofnąć za jednym kliknięciem.

  CI jest znacznie mniej przydatny, jeśli Twój zestaw testów nie jest kompletny i poprawny, ponieważ cała przesłanka opiera się na możliwości sprawdzania poprawności kodu w sposób zautomatyzowany.

• Dokonaj aktualizacji atomowych.

  Idealnie byłoby, gdyby nie kopiować nowych plików na stary na serwerze produkcyjnym. Zamiast tego użyj narzędzia takiego jak capistrano, które kopiuje każdy plik do nowej lokalizacji, a następnie używa dowiązania symbolicznego, aby wskazać pożądane wdrożenie. Wycofywanie jest natychmiastowe, ponieważ polega po prostu na zmianie dowiązania symbolicznego w celu wskazania poprzedniego wdrożenia. (Chociaż nie musi to obejmować migracji bazy danych).

  Sprawdź także, czy pojemniki takie jak Docker mogą ci pomóc.

• Dokonuj mniejszych, częstszych zmian.

  Niezależnie od tego, czy masz testy, CI czy nic, samo to może znacznie ci pomóc. Każda zmiana powinna mieć własną gałąź git, a wdrożenie powinno zawierać jak najmniej zmian. Ponieważ zmiany są mniejsze, jest mniej potencjalnych błędów podczas wdrażania.

  W tej notatce wprowadzaj zmiany bardziej izolowane, gdy tylko to możliwe. Jeśli dokonałeś zmiany w grze Omaha i nie ma ona wpływu na Texas Hold'em, 5-kartowy stud ani nic innego, to jest to jedyna gra, która musi zostać zawieszona na utrzymanie.

• Analizuj wszystko, co długoterminowe.

  Wspomniałeś, że niektóre części wdrożeń zajmują dużo czasu. To jest prawdopodobnie zmiany schematu bazy danych. Warto spojrzeć na bazę danych DBA wraz z każdą zmianą schematu, aby zobaczyć, co może działać lepiej.

  Poproś specjalistę o zapoznanie się z każdą inną częścią wdrożenia, która zajmuje duże bloki czasu.

• Dziwne godziny pracy.

  Być może już to robisz, ale trzeba o tym wspomnieć. Nie należy się spodziewać, że programiści (i sysadmins!) Będą pracować od „9 do 5”, szczególnie w przypadku operacji 24x7. Jeśli ktoś ma spędzić noc na opiece nad wdrożeniem, rozwiązywaniu problemów, a następnie dotrzymywać harmonogramu dnia, twoje oczekiwania są nierealne, a ty ustawiasz tę osobę na wypalenie.

Z tego, co mówisz, wydaje się, że masz okno serwisowe od 1 do 7 rano każdego dnia, problemem jest nie czas, ale wygoda. Jest to normalne i wiele osób po prostu zajmuje się tym w ramach działalności gospodarczej.

Możesz mieć 2 (lub więcej) backendowych systemów z interfejsem, który kieruje ruch do tego, który jest aktualnie aktywny. Gdy będziesz zadowolony, że wydanie będzie działać, powiedz interfejsowi, aby przeszedł na nowy system. powinno to być łatwe do napisania w krótkim czasie.

Masz teraz możliwość pozostawienia starego systemu bez zmian, aby go wycofać, lub zaktualizować, aby mógł być używany jako zapasowy dla systemu na żywo, dopóki nie nadejdzie czas na kompilację / testowanie kolejnych aktualizacji.

Zmieniając pozostałe odpowiedzi: Powinieneś postępować zgodnie z niebiesko-zielonym modelem wdrażania . Kiedy chcesz wydać nową wersję, wdrażaj ją na wewnętrznej stronie pośredniej. Następnie możesz uruchomić automatyczne testy w witrynie produkcyjnej następnej wersji. Po przejściu testów wskaż moduł równoważenia obciążenia, aby skorzystać z nowej witryny.

Pomaga to w następujący sposób:

1. Poważne problemy zawsze występują przy zerowym przestoju.
2. Przejście na nową wersję ma dokładnie zero przestojów, ponieważ nowa wersja jest już uruchomiona i rozgrzana.
3. Możesz wrócić do starej wersji w dowolnym momencie, ponieważ nadal działa fizycznie.

Wszystkie inne problemy, o których wspominaliście ty i inni, stają się mniej dotkliwe, gdy można je wdrożyć w dowolnym momencie bezstresowo. Niebiesko-zielony model wdrażania jest dość kompletnym rozwiązaniem problemów związanych z wdrażaniem.

Co zrobisz, jeśli w głównym centrum danych wystąpi awaria, co zdarza się od czasu do czasu we wszystkich centrach danych? Możesz zaakceptować przestoje, możesz przełączyć się na inne centrum danych, możesz pracować w trybie aktywnym-aktywnym w wielu centrach danych przez cały czas lub możesz mieć inny plan. Niezależnie od tego, co to jest, zrób to, gdy robisz wydania, a następnie możesz zwolnić swoje główne centrum danych podczas wydania. Jeśli jesteś przygotowany na przestoje, gdy twoje centrum danych ma awarie, to jesteś przygotowany na przestoje, więc nie powinno to stanowić problemu podczas wydania.

Aby dodać do poprzednich odpowiedzi:

• Użyj strategii wdrażania, która pozwala na wycofywanie zmian i natychmiastowe przełączanie, Capistrano lub prawie jakikolwiek inny system wdrażania pomoże w tym. Można użyć takich rzeczy, jak migawki bazy danych i dowiązania symboliczne kodu, aby móc szybko przywrócić poprzedni stan.

• Używaj pełnego zarządzania konfiguracją, nie zostawiaj niczego zarządzanego ręcznie. Przykładami są systemy takie jak SaltStack, Ansible i Puppet. Można je również zastosować do konfiguracji kontenerów Docker i pudeł Vagrant.

• Użyj HA, aby upewnić się, że możesz przekazywać żądania podczas aktualizacji węzła. Jeśli aktualizacja się nie powiedzie, po prostu w dół węzła, a gdy zostanie przywrócony, przywróć go ponownie, a twoje rozwiązanie HA zauważy i ponownie przesyła żądania do tego węzła. HAProxy jest przykładem, ale nginx również działa dobrze.

• Upewnij się, że aplikacja może obsługiwać współbieżne wystąpienia, używane repozytoria danych w wersji centralnej dla danych niekodowanych, które muszą być przechowywane na dysku, takich jak pamięć podręczna. W ten sposób nigdy nie będziesz mieć uruchomionej zaktualizowanej aplikacji do buforowania plików z innej wersji. Można to zrobić poza czyszczeniem pamięci podręcznej i robieniem rozgrzewki pamięci podręcznej. (Pamięć podręczna to tylko przykład)

Zazwyczaj konfiguruję przepływy pracy, w których menedżerowie zespołów mogą zatwierdzać żądania scalenia do specjalnej gałęzi, która wykonuje wszystkie normalne czynności CI, ale jako dodatkowy ostatni krok zaczyna również przekazywać do węzłów produkcyjnych. Zasadniczo wykonujesz ręczne wdrażanie CI w instancji produkcyjnej. Jeśli to wystąpienie nie generuje nieprawidłowych odpowiedzi, psuje lub robi dziwne rzeczy w twoich danych, następnie masowo uaktualnij wszystkie węzły za pomocą wybranego rozwiązania CI. W ten sposób, jeśli jedno wdrożenie działa, wiesz, że wszystkie wdrożenia będą działać dla określonego znacznika / zatwierdzenia.

Obecnie wydaje się, że uruchamiasz aplikację produkcyjną w jednym węźle, z jednym procesem wdrażania, jednym źródłem i jednym celem. To praktycznie oznacza, że ​​każdy krok w tym przepływie pracy jest punktem awarii, który sam w sobie może uszkodzić witrynę. Zapewnienie, że coś takiego się nie stanie, jest podstawą wszystkich procesów CI, HA i przełączania awaryjnego. Nie uruchamiaj tylko jednego węzła, nie uruchamiaj tylko jednego procesu HA, nie uruchamiaj tylko jednego adresu IP, nie uruchamiaj tylko jednego CDN itp. Może to brzmieć drogo, ale umieszczenie duplikatu tego, co już masz w szafie na serwerze z własnym połączeniem zwykle kosztuje mniej niż godzinę przestoju w witrynie firmy.

Globalnie zgadzam się z Michaelem w każdym z jego punktów ( /server//a/739449/309477 ).

Moim zdaniem pierwszą poprawą, którą powinieneś wprowadzić, jest użycie narzędzia do wdrażania (Capistrano).

Umożliwi to wdrożenie pokojowe, a następnie natychmiastowe przejście do nowszej wersji. Jeśli coś pójdzie nie tak, możesz natychmiast powrócić do działającej wersji, po prostu zmieniając bieżące łącze symboliczne na działającą.

A Capistrano jest dość szybki w obsłudze (w porównaniu do rozpoczęcia testów i CI, co będzie inwestycją dłuższą).

Po drugie, jeśli pieniądze nie są twoim głównym problemem, powinieneś mieć serwer programistyczny iso-prod, aby przetestować aplikację przed wdrożeniem jej w produkcji. Użyj rozwiązania przemysłowego (Ansible, Chef, Puppet) do zarządzania instancjami VPS.