Jaki jest sens inscenizacji?

18

Myślałem, że to wypracowałem, ale po przeczytaniu Continuous Delivery (doskonała książka) jestem trochę zdezorientowany. Mówią o posiadaniu serwerów dla:

  • rozwój
  • różne formy automatycznych testów
  • test akceptacji użytkownika (UAT) - tj. siadanie z klientem i pokazywanie mu go oraz pozwalanie mu na badanie eksploracyjne. Testerzy wewnętrzni mogliby również użyć tego zestawu do testowania eksploracyjnego.
  • inscenizacja
  • produkcja.

Zawsze myślałem o inscenizacji jako o funkcji UAT, ale wydają się mieć inscenizację jako osobny poziom. Więc w tym schemacie jaką funkcję pełnią serwery pomostowe?

deployment  testing  release-management 
— Hamish Downer
źródło
10
Nie mogę powiedzieć, że zgadzam się z tą metodologią. UAT należy zawsze wykonywać na możliwie najbliższych specyfikacjach systemu na żywo (tzn. Na etapie testowania). Nie mogę policzyć, ile razy zrobiliśmy UAT i wszyscy narzekali na problemy z prędkością, na co musimy tysiąc razy tłumaczyć, że „System na żywo będzie szybszy”. A kiedy system na żywo NIE JEST szybszy, z powodu błędu w kodzie lub zapytania SQL, musisz jeść własne słowa.
— Mark Henderson
UAT = test akceptacji użytkownika, prawda?
— Martin Thoma,

Odpowiedzi:

13

Inscenizacja polegałaby na wdrożeniu pełnych systemów produktów, ale jeszcze ich nie stosowaniu. Gdy wejdą do użytku, będzie to „produkcja”. Powinieneś umieścić wszystko na miejscu, jak będzie używane, przetestować, a następnie przestawić przełącznik.

UAT często używa środowiska „testowego”, które znacznie różni się od sprzętu / oprogramowania / konfiguracji, która będzie używana w produkcji.

Na przykład tam, gdzie pracuję, klienci testują wszystko w środowisku VM działającym na naszych serwerach. Kiedy ich system zostanie uruchomiony, będzie działał na ich sprzęcie, w ich obiektach, prawdopodobnie integrując się z istniejącymi systemami; nie będzie miało to absolutnie nic wspólnego z naszymi serwerami lub środowiskiem testowym (oprócz tego, że kod i niektóre ustawienia zostały skopiowane stamtąd ...)

— Chris S.
źródło
Więcej testów zwykle odbywa się również na serwerze pomostowym, nie tylko w UAT - tuż przed rozpoczęciem produkcji.
— jftuga
3
@ jftuga, patrz ostatnie zdanie pierwszego akapitu ...
— Chris S
@Chris S: Jeśli dobrze cię rozumiem, nie ma czegoś takiego jak „serwer pomostowy”, tylko serwer produkcyjny, który jest poza pulą, a obecnie nie służy użytkownikom końcowym. To ma sens i jest to metodologia, którą stosuję, ale nie nazywam tych serwerów „serwerami przejściowymi”, a jedynie serwerami produkcyjnymi (których nie ma w puli). Ponieważ wszędzie tam, gdzie pracowałem, że serwery pomostowe mają je jako osobne serwery, nie sądzę, aby twój opis serwera pomostowego był standardowym użyciem tego terminu. Dobry pomysł, ale nie to, co zwykle oznacza „serwer pośredniczący” (w każdym razie z mojego doświadczenia).
— iconoclast
1
@Brandon Z twojego doświadczenia, czym jest zatem „serwer pośredniczący”? Może to być regionalna różnica, na przykład „odbijanie” serwera.
— Chris S
Wydaje mi się, że różni się w zależności od organizacji. Widziałem, że jest używany jako serwer UAT, jako serwer dla programistów, aby umieścić aplikację w środowisku podobnym do produkcyjnego i prawdopodobnie innych rzeczy. (Osobiście uważam, że jedyną dobrą strategią jest wykorzystanie prawdziwego serwera produkcyjnego do przygotowywania scen.) Ponieważ różne organizacje rozwijają własną kulturę, myślę, że opracowują również własny leksykon, a więc słowa, które powinny mieć standardowe znaczenie w całej branży niestety nie.
— iconoclast
17

Pracuję w zespole zarządzania wydaniami w bardzo dużej firmie internetowej. Stosujemy zasadniczo proces opisany powyżej i celowo wybraliśmy ten proces. W naszej metodologii etapowanie służy jako mechanizm rozgałęziający dla końcowego poziomu testowania w produkcji.

Oczywiście chcesz przeprowadzić wszystkie testy przed rozpoczęciem produkcji, ale w dużym, złożonym środowisku z dużą liczbą użytkowników jest to bardzo trudny cel. W szczególności właściwie załadowanie oprogramowania testowego w ramach kontroli jakości jest praktycznie niemożliwe. Testowanie funkcjonalne jest o wiele łatwiejsze do zautomatyzowania niż testowanie obciążenia. Gdy masz tysiące użytkowników uderzających na twoje serwery, sprawy zawodzą w dziwny i trudny do przewidzenia sposób.

Oto co robimy:

  • Rozwój
    • obejmuje ciągłą integrację i automatyczne testowanie
  • testowanie wersji
    • moja grupa analizuje samą wersję
    • przeglądanie dzienników instalacji
    • testowanie wycofania
  • QA
    • testy akceptacyjne użytkownika

W tym momencie rozgałęziamy się między inscenizacją a produkcją. Do wypuszczania używamy modelu pociągu, a nowy pociąg rozpoczyna się co kilka tygodni. Nawet ponumerowane pociągi jadą na serwery pomostowe (które są w produkcji). Pociągi o nieparzystych numerach nie.

Pomiędzy parzystymi pociągami programiści mają możliwość wypychania indywidualnych zmian na serwery pomostowe ( oczywiście po przetestowaniu tych zmian przez QA). Pozwala im to sprawdzić, czy ich oprogramowanie działa zgodnie z oczekiwaniami w rzeczywistym środowisku produkcyjnym. Jest to na ogół zarezerwowane dla komponentów, które są uważane za wyższe ryzyko, nie popychamy każdego małego elementu do inscenizacji.

Następnie wszyscy rozumieją, że kiedy rozpocznie się następny parzysty pociąg, usunie to, co jest na serwerach pomostowych i ustawi je z powrotem do linii bazowej pociągu. Deweloperzy albo upewniają się, że ich zmiany dotarły do ​​pociągu, albo decydują, że nie są jeszcze gotowi do ogólnego użytku, w którym to przypadku zmiany zostaną po prostu usunięte na serwerach pomostowych.

Podsumowując, krótką odpowiedzią (przynajmniej dla nas) jest to, że niemożliwe jest całkowite przetestowanie złożonych systemów w kontroli jakości. Inscenizacja zapewnia bezpieczny sposób wykonywania ograniczonych testów produkcyjnych.

W powiązanej notatce oto moje slajdy z prezentacji, którą właśnie przedstawiłem na temat tego, jak działa nasz proces wydawania.

— Phil Hollenback
źródło
5

Najprostszym wyjaśnieniem etapowania jest testowanie procesu wdrażania i testowanie przy użyciu prawdziwego źródła danych. Niektóre systemy łączą etapy ze swoimi środowiskami testowymi, ale w przypadku systemów na dużą skalę proces wdrażania może być bardzo złożony lub mogą wymagać dodatkowych kroków testowych po połączeniu ze źródłem danych na żywo / produkcyjnym. W takim przypadku środowisko pomostowe umożliwia przetestowanie procesu wdrażania i sprawdzenie błędów w ostatniej chwili przy użyciu danych na żywo, a następnie po zweryfikowaniu poprawności działania środowiska scenicznego można szybko przełączyć na środowisko produkcyjne.

Przykładem może być Windows Azure, który wymaga 5-25 minut na wdrożenie nowej wersji, ale można wdrożyć w środowisku pomostowym, wykonać testy, a następnie natychmiast zamienić środowiska produkcyjne i pomostowe .

— Greg Bray
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.