MongoDB
 sql >> Baza danych >  >> NoSQL >> MongoDB

Jak przetestować aktualizacje aplikacji MongoDB?

Wybrałeś MongoDB jako bazę danych aplikacji i prawdopodobnie masz już wiele danych produkcyjnych w swojej bazie danych. Teraz musisz wprowadzić poważną zmianę w swojej aplikacji. W jaki sposób przystępujesz do testowania, aby upewnić się, że nowa wersja Twojej aplikacji dobrze zachowuje się z danymi produkcyjnymi?

Dane produkcyjne są zawsze nieskończenie bardziej zróżnicowane niż dane testowe i ćwiczą więcej przypadków brzegowych, co w konsekwencji prowadzi do większej liczby błędów. Nie zaleca się eksportowania danych produkcyjnych do środowiska testowego ze względu na kwestie związane z polityką, prywatnością i bezpieczeństwem. Z drugiej strony identyfikacja i testowanie błędów w środowisku produkcyjnym jest dość trudne i kosztowne. Jak więc zadbać o to, aby nowa wersja aplikacji dobrze współpracowała z danymi produkcyjnymi? Oto, co zalecamy w ScaleGrid:

4 kroki uaktualniania MongoDB do wersji produkcyjnej

  1. Przede wszystkim bezpieczeństwo

    Naszą główną troską jest bezpieczeństwo danych produkcyjnych. Dlatego nigdy nie eksportujemy żadnych danych produkcyjnych do naszego środowiska testowego lub testowego. To, co mamy, to „pseudoprodukcja” – jest to środowisko identyczne z produkcją – ten sam rozmiar, te same ograniczenia bezpieczeństwa co produkcja. Jest jednak efemeryczny i żyje tylko przez czas trwania testu.

  2. Klonuj swój produkcyjny klaster MongoDB

    Używamy funkcji „Klonuj” usługi ScaleGrid, aby utworzyć klon produkcyjnej bazy danych w określonym momencie. W chmurach, takich jak AWS, funkcja Clone używa migawek EBS, więc operacja klonowania ma niewielki lub żaden wpływ na produkcyjną bazę danych. Daje nam to „pseudoprodukcyjne” środowisko bazy danych, które ma te same funkcje, co produkcja – te same dane, te same rozmiary maszyn, te same zabezpieczenia, ta sama konfiguracja klastra itp.

  3. Przeprowadź szczegółowe testy

    Przeprowadzamy obszerny zestaw testów, aby upewnić się, że nowa wersja aplikacji nie powoduje problemów z danymi. Gdy jesteśmy usatysfakcjonowani, niszczymy środowisko „pseudoprodukcyjne”.

  4. Uaktualnij swoje środowisko produkcyjne

    Gdy jesteśmy zadowoleni z naszych testów, przystępujemy do aktualizacji naszej aplikacji w środowisku produkcyjnym. W zależności od funkcji możesz też chcieć uaktualnić ją tylko dla niektórych klientów, czyli testowanie A/B.

Jakie więc inne problemy masz z testowaniem uaktualnień aplikacji za pomocą MongoDB? Czy masz narzędzia, techniki lub sugestie, którymi chciałbyś się podzielić? Bardzo chcielibyśmy usłyszeć od Ciebie!


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Przegląd kopii zapasowej Percona dla MongoDB

  2. Lista kontrolna rozwoju i operacji dla MongoDB

  3. Nie można uruchomić MongoDB. BŁĄD:adres jest już używany

  4. Architektura dla bezpieczeństwa:przewodnik po MongoDB

  5. MongoDB - pobierz dokumenty z maksymalnym atrybutem na grupę w kolekcji