Jakie powinny być środowiska PreProd i Prod?

Niedawno byłem przy projekcie i podczas premiery zdaliśmy sobie sprawę, że nie działał on w produkcji. Działa we wszystkich innych środowiskach, ale ponieważ mamy oddzielny zespół wydający i nie możemy sami skonfigurować serwerów i środowisk, nie mamy widocznej konfiguracji na nich.

Podejrzewamy, że Prod ma pewne uprawnienia użytkownika na swoim koncie lub w ustawieniach IIS, które są różne, więc pracujemy nad tym teraz.

Myślę więc, że to wszystko było dla mnie doświadczeniem uczenia się i nie chcę, aby to samo się powtarzało. Chciałbym zapytać, jak różne powinny być te środowiska? Zawsze myślałem, że PreProd powinien być identyczną kopią środowiska Prod, używając kopii tej samej bazy danych, używając kopii tego samego konta użytkownika, powinien być zainstalowany na tych samych serwerach itp.

Ale jak daleko mam to zrobić? Jeśli strona internetowa jest skierowana na zewnątrz, czy PreProd powinien być skierowany na zewnątrz? Co się stanie, jeśli witryna zawiera komponenty, do których nawigacji nie wymaga konta użytkownika ani hasła? Czy nadal można wystawiać go na działanie świata zewnętrznego?

Z pewnością powinieneś testować środowisko, które jest identyczne z serwerami produkcyjnymi, o ile jest to możliwe. Jeśli tego nie zrobisz, nie będziesz testować, z czego będą korzystać Twoi klienci. Jeśli nic więcej nie potrzebujesz takiego środowiska do testowania raportów o błędach.

Oczywiście będą rzeczy, których nie chcesz, aby były identyczne - na myśl przychodzą linki do systemów płatności, ale należy je wyśmiewać, jakby były prawdziwe . Są też rzeczy, których nie można powielić - skala systemu.

Możesz przetestować za pomocą zewnętrznego adresu URL - ponownie testujesz to, co zobaczą Twoi użytkownicy. Również testowanie za pomocą zewnętrznego adresu URL będzie wykorzystywać sieć w inny sposób niż wewnętrzne użycie systemu. Uprawnienia (na przykład) będą odgrywać rolę, podobnie jak dostępna przepustowość, zapory ogniowe itp. Wszyscy użytkownicy będą musieli stawić czoła, ale pominiesz je, jeśli uzyskasz bezpośredni dostęp do systemu.

Nie widzę jednak problemu ze składnikami, które nie wymagają konta i hasła. Jeśli nie potrzebuje hasła, to nie jest istotne / wrażliwe, jeśli jest wrażliwe, to dlaczego nie ma hasła?

Myślę, że najlepszą praktyką jest podejście Blue Green Deployment, ukute przez Jez Humble i David Farley w ich książce Continuous Delivery i opisane przez Martina Fowlera w jego blogu Blue Green Deployment .

Założenie jest bardzo proste. Z postu Martina Fowlera:

Niebiesko-zielone podejście do wdrażania ... [zapewnia], że masz dwa środowiska produkcyjne, możliwie identyczne. W dowolnym momencie jeden z nich, powiedzmy na przykład niebieski, jest aktywny. Przygotowując nową wersję oprogramowania, przeprowadzasz ostatni etap testowania w zielonym środowisku. Gdy oprogramowanie działa w zielonym środowisku, przełączasz router, aby wszystkie przychodzące żądania trafiały do ​​zielonego środowiska - niebieskie jest teraz bezczynne.

Wdrożenie niebiesko-zielone daje również szybki sposób na wycofanie - jeśli coś pójdzie nie tak, przełącz router z powrotem na niebieskie środowisko.

Takie podejście rozwiązałoby problem braku identycznych środowisk przedprodukcyjnych i produkcyjnych, a także optymalizacji strategii wdrażania.

Nasze końcowe środowisko przedprodukcyjne to po prostu jeden z serwerów działających na żywo wyjęty z modułu równoważenia obciążenia. Wdrażamy naszą kompilację przedprodukcyjną (która jest zasadniczo identyczna z kompilacją na żywo, z wyjątkiem parametrów połączenia z bazą danych i kilku innych zmian konfiguracji) i testujemy ją. Jeśli to pójdzie dobrze, wdrażamy kod na żywo, a na koniec, jeśli okaże się, że jest to w porządku, zwracamy serwer do modułu równoważenia obciążenia i wdrażamy wersję produkcyjną na pozostałych serwerach jeden po drugim.

Powinny być jak najbardziej podobne, aby można było zidentyfikować problemy w dowolnym punkcie systemu, z możliwym wyjątkiem niemożności skalowania. Jeśli to w ogóle możliwe, jedyną różnicą między środowiskiem produkcyjnym a środowiskiem przedprodukcyjnym / testowym / testowym byłby rozmiar - oczekiwałbym, że środowisko produkcyjne będzie się składać z wielu innych maszyn w środowisku na dużą skalę. Powinieneś nawet odzwierciedlić przeznaczenie posiadanych maszyn, takich jak serwery baz danych, serwery WWW i tak dalej.

Jednak dokładna replikacja może nie być możliwa w ramach obecnego budżetu. Im bliżej, tym bardziej skuteczne będą testy i tym mniej prawdopodobne problemy pojawią się podczas popychania do produkcji.

Zajmuję inne stanowisko niż ChrisF, jeśli chodzi o to, aby środowisko to było dostępne publicznie. Mówię, że nie powinno tak być. Zdecydowałbym się uruchomić na kopii rzeczywistych baz danych lub przynajmniej kopii podzbioru rzeczywistych baz danych i środowiska skierowanego do wewnątrz. W ten sposób możesz przetestować rzeczywiste i realistyczne dane i nie martwić się lukami bezpieczeństwa prowadzącymi do wycieku. Możesz oczywiście zdezynfekować dane, ale może to usunąć niektóre „brudne dane” ze środowiska, które mogą prowadzić do wykrycia defektu w aktywnym systemie.

Wszędzie, gdzie pracowałem, banki, telekomunikacja itp. Pre-prod był bezpośrednią kopią produkcji, z tym że baza danych miałaby około tygodnia. To był ogromny proces utrzymywania danych w całym przedprodukcie, ale został uznany za niezbędny dla firm, dla których pracowałem, dla których wdrożyłem przedprodukcję.

W sekcji dotyczącej bankowości w UA rząd nakłada grzywny na banki za awarie usług, np. Bankomaty internetowe itp. Są co minutę niedostępne. Często zdarza się, że zespół projektowy / testujący został zwolniony z powodu incydentu. Pre-prod nie jest dla każdej firmy lub procesu rozwoju, ale dla niektórych jest niezbędny.