Jak uniknąć ciągłej niestabilności spowodowanej integracją w środowiskach testowych?

19

Załóżmy, że korzystasz z procesów ciągłej integracji, które często aktualizują niektóre środowiska docelowe, dzięki czemu za każdym razem, gdy są jakieś zmiany, „możesz” przetestować je od razu. To część celów CI, nie?

Ale załóż również, że w twoim cyklu testowym uczestniczą inne osoby, np. Kierownicy lub klienci. Sensowne jest angażowanie innych osób w próbę przeglądu (złamania?) Nadchodzących zmian, prawda?

Ale jeśli ciągle dostarczasz zmiany w środowisku, w którym ci inni ludzie, poważnie, próbują je przetestować, mogą pojawić się liczne problemy, takie jak:

  • they mogą tracić czas na zgłaszanie problemów, które do czasu zapisania (dogłębnego) raportu, nie są nawet w stanie samodzielnie odtworzyć problemu (np. ponieważ przypadkowo natknąłeś się na ten sam problem i już go naprawiłeś w swoim środowisku).
  • you mogą nie być w stanie odtworzyć zgłoszonych problemów, ponieważ środowiska, w których napotkali jakiś problem, nie są już identyczne (ty (!!!) mogłeś nałożyć ich środowisko).

Co więc możesz zrobić (jak skonfigurować?), Aby uniknąć takich (frustrujących) sytuacji?

Pierre.Vriens
źródło

Odpowiedzi:

10

Opowiem o tym, głównie dlatego, że pokazuje, dlaczego niektóre odpowiedzi nie zawsze mają zastosowanie.

Trochę kontekstu na początek:

  • Mamy 7 środowisk do obsługi około 80 aplikacji, większość z nich polega na sobie nawzajem za pośrednictwem usług internetowych lub wspólnych tabel w db2-iSeries.
  • Na dobre i złe, iSeries to nasz system referencyjny DB.
  • Ten ostatni punkt unieważnia pomysł wprowadzenia aplikacji z jej zależnościami w izolowanym środowisku, ponieważ uruchomienie AS400 dla każdego z nich kosztowałoby zbyt wiele i nie mielibyśmy sprzętu do jego uruchomienia.

To, co robimy, nie jest kompletną automatyczną ciągłą dostawą, mamy harmonogram wydań, aby wprowadzić spójną masę aplikacji do ogólnych operacji. Poza tym każdy zespół testowy może uruchomić wydanie w jednym ze środowisk Q / A dla testowanej aplikacji i może zablokować niektóre wersje aplikacji, aby uniknąć przerwania testów przez inne zespoły.

Zależności aplikacji są sprawdzane przed wydaniem, więc system nie wyda czegoś, jeśli inne aplikacje nie będą mogły zostać zaktualizowane lub nie będą pasować do potrzebnych zależności. Główną ideą jest umożliwienie aktualizacji, gdy nie będzie to miało wpływu na kogoś, jeśli nie zaplanowano żadnych testów, powinno wypłynąć z poprzedniego środowiska (a naszym celem jest usunięcie zaplanowanych wydań w 5 pierwszych wersjach w połowie okresu, teraz mamy zatwierdził ten system metody „na żądanie”).

Krótka wersja ma mieć system „semaforów” wokół aplikacji w środowisku, zespół powinien być w stanie zablokować docelową aplikację za pomocą jej zależności (i zależności przechodnich) na czas testów ręcznych.
Implementacja tego semafora jest w dużym stopniu zależna od twojego systemu automatyki, więc nie będę tego rozszerzać.

Oczywiście, jak wspomniano inni, najłatwiejszym sposobem jest stworzenie świeżego środowiska dla aplikacji ze wszystkimi jej zależnościami, aby uniknąć opisanego powyżej semafora.

Tensibai
źródło
Ta odpowiedź jest odmianą tego, do czego jestem przyzwyczajony (komputery mainframe), w których robimy takie rzeczy przez co najmniej 1,5 dekady (jeszcze przed narodzinami „DevOps”). Zastanawiam się, czy uzasadnione byłoby dodanie tutaj mojej własnej odpowiedzi (w celu dalszego rozwinięcia tej odpowiedzi, w jaki sposób robimy to z CMN / ZMF np. Dla „banków”), czy po prostu wziąłbym to pytanie na nowe (samo-odpowiedzi) pytanie. Co myślisz? Ciekawi mnie też ta metafora, warta nowego pytania (w odniesieniu do tej odpowiedzi)? PS: masz coś przeciwko, jeśli poprawię kilka literówek?
Pierre.Vriens
Nie ma problemu z edycją :) Utrzymałem to ogólne, to nie jest zbyt specyficzne dla IMHO organizacji Devops. Ponownie DevOps to zmiana organizacyjna, która może pomóc w skonfigurowaniu lepszej automatyzacji poprzez podzielenie się obawami ... więc nazywam to semaforem, ponieważ w programowaniu nie sądzę, że warto zadawać pytania, ale to zależy od ciebie
Tensibai
Ok, edycja zakończona (jak zwykle: przywróć / popraw według własnego uznania). BTW, czy masz na klawiaturze „s”?!?!?! Poza tym: rzeczy do przemyślenia w weekend: zobacz moje najnowsze meta pytanie ... Bon weekend! Czas na ogrodnictwo tutaj (przycinanie ...)
Pierre.Vriens
8

Wygląda na to, że mówisz o środowisku testowym, które jest stale ponownie używane bez niezawodnej ponownej inicjalizacji dla każdego wykonania testu. To sprawia, że ​​taki test jest niewiarygodny. Podobnie z punktu widzenia niezawodności, z testowaniem ręcznym, jeśli chcesz.

IMHO nie powinieneś używać takich testów do celów kwalifikacji CI / CD, ponieważ to skutecznie unieważnia proces kwalifikacji (przynajmniej w tym obszarze). Powiedzenie, że oprogramowanie przechodzi test X bez wykonania testu X dla każdej dostarczonej wersji oprogramowania lub bez pewności, że passuzyskany wynik nie jest przypadkowy (z powodu fałszywych wyników pozytywnych) spowoduje obniżenie poziomu ufności testu. Fałszywe negatywy nie są szkodliwe dla wiarygodności, ale są również niepożądane ze względu na niepotrzebny „hałas”, który powodują.

Testy takie można przeprowadzać poza procesem kwalifikacji CI / CD. Ale nie powinieneś traktować nieudanego wyniku takiego testu jak błędu znalezionego przez klienta: musisz rzetelnie odtworzyć problem, aby móc opracować poprawkę i potwierdzić, że poprawka działa. I tak naprawdę nie możesz tego zrobić, jeśli testowanie nie jest wiarygodne.

Jeśli planujesz rozwiązać ten problem, najlepiej najpierw opracuj zautomatyzowaną, niezawodną skrzynkę testową do odtworzenia problemu. Którego użyjesz do opracowania poprawki i potwierdzenia jej skuteczności (wynik testu powinien przejść z FAIL na PASS). Możesz (powinieneś?) Także umieścić tę skrzynkę testową w procesie kwalifikacji CI / CD, aby w razie potrzeby zapobiec ponownemu pojawieniu się w przyszłości - aby podnieść ogólny poziom jakości wydania oprogramowania.

Dan Cornilescu
źródło
W twojej odpowiedzi jest wiele do strawienia (nie jestem pewien, czy już to rozumiem). Ale to, co napisałeś o „ przeprowadzaniu takich testów poza procesem kwalifikacji CI / CD ”: oczekiwałbym, że ostateczny wynik tego, co zostanie wyprodukowane / dostarczone, zostanie zapisany w twoim środowisku kontroli jakości i produktu (za pośrednictwem CD, automatycznie lub ręcznie). Ale to też „ wydaje mi się ”, że CI powinien tam również dostarczać swoje wyniki, podczas gdy „na zewnątrz” wydaje się separacją lub powielaniem czy coś, nie?
Pierre.Vriens
insideI outsidereferencje odnoszą się do pętli weryfikacji Ci. Zasadniczo kwestionuję powód istnienia środowiska kontroli jakości - większość przeprowadzonych tam testów powinna być niezawodna i ostatecznie wykonana jako część weryfikacji CI, szczególnie w kontekście ciągłego wdrażania - ponieważ chcesz je wykonywać przy każdej iteracji CI (udane przynajmniej do tego momentu).
Dan Cornilescu
7

Zwykłym podejściem jest tworzenie różnych środowisk:

DEV - jest to miejsce, w którym zespół deweloperów psuje rzeczy. Tutaj stwórz wszystkie zmiany tuningów, wdróż nową wersję i tak dalej. Oto miejsce, w którym CI jest w pełni zintegrowane.

PREPROD / QA - w tym miejscu „zagraj” zespół QA / test / validation do testów. To środowisko zwykle zawiesza się podczas testów. Integracja CI z tym środowiskiem ma na celu jedynie dostarczenie nowej wersji produktu, konfiguracji itp.

PRODUKCJA - czy trzeba to tłumaczyć :)?

Romeo Ninov
źródło
ok, to powinno pomóc poprawić stabilność, litościwie! Moje pytanie dotyczy środowisk „testowych”, więc oczywiście nie należy traktować „produkcji” jako takiej. Pomimo tych, którzy używają „produkcji” do testowania, znasz powiedzenie „ Najlepszym testem jest aktywacja go w produkcji, a jeśli to nie działa, po prostu wykonaj wycofanie / wycofanie! ”?
Pierre.Vriens
@ Pierre.Vriens, „granie” w prod IMHO nie jest mądre :) Takie rozdzielenie środowiska jest celowe. W poprzedniej pracy mieliśmy 5 różnych środowisk .... Wotywna służba
Romeo Ninov
1
„Zgadzam się”, że taka gra nie jest mądra. Co jednak można zrobić z kowbojem (mój „termin” używam w przypadku takich juppies), którzy robią to w kółko, i za każdym razem, gdy otrzymują zgodę od swoich menedżerów na obejście (np.) Miesięcznej aktywacji wydania , przez kolejną poprawkę (np. dla ich poprawki z poprzedniego dnia ... która wprowadziła nowy błąd). Myślisz, że tak się nie dzieje w prawdziwym świecie? BTW: jeśli chodzi o „zamrożenie” w twojej odpowiedzi, uważasz, że sensowne jest opublikowanie pytania typu „Jakie są przykładowe implementacje zamrożonego środowiska?”
Pierre.Vriens
@ Pierre.Vriens, dla mnie sensowne jest opublikowanie takiego pytania. Zwykle jest to regulowane przez zasady firmy, ale devops tworzą dość dynamiczne środowisko i może to być prawdziwe wyzwanie :)
Romeo Ninov
1
To jest moje preferowane podejście, w ten sposób daje środowisko, w którym twórcy mogą natychmiast przetestować swoje zmiany w zintegrowanym środowisku, ale utrzymują QA w czystości, dopóki kod nie będzie gotowy do formalnego przetestowania
Taegost
3

Jeśli robisz CI / CD, oznacza to, że przed wdrożeniem (CD) dzieje się kilka automatycznych testów (CI). Jeśli w środowisku testowym występuje wiele problemów, oznacza to, że nie są one wychwytywane przez testy uruchamiane przed wdrożeniem; oznacza to niewystarczające automatyczne testowanie. Jeśli programiści mają problemy z pojawianiem się defektów w środowisku (ach) testowym, muszą ulepszyć swoje zautomatyzowane zestawy testów, aby temu zapobiec. Poprawi to również ogólnie jakość i niezawodność, aż do produkcji.

Adrian
źródło
3

Aby dodać do odpowiedzi Romeo Ninova, wewnętrznie w środowisku musisz spróbować jak najbardziej rozdzielić aplikacje. Jest to częściowo spowodowane tym, że docker odniósł tak duży sukces w projektowaniu / testowaniu. To pozwala niemal udawać, że w ogóle nie udostępniasz środowiska.

Inną opcją jest posiadanie bardzo jasno zdefiniowanych serwerów, na których działają aplikacje, które są oddzielone od reszty infrastruktury, która tworzy twoje środowisko. To znaczy. Wszystkie maszyny do zarządzania środowiskiem lub aktywacji działają na osobnych, długowiecznych serwerach. Następnie podłączasz nowe, krótkotrwałe serwery w oparciu o znany obraz, aby przetestować aplikację, a jeśli zostaną wprowadzone jakiekolwiek zmiany w obrazie podstawowym, musisz zastosować te zmiany wszędzie dla każdego nowego komponentu. Co oznacza testowanie zmian we wszystkim.

Jeśli zespół appdev poprosi o zmianę, która zepsuje czyjąś aplikację, to pech, musi wewnętrznie stworzyć czynnik łagodzący w swoim kodzie i oddzielić swoje specyficzne wymagania od oferowanych środowisk.

hvindin
źródło
Ciekawe punkty widzenia / uzupełnienia, chociaż są w nim pewne rzeczy, które być może chcesz udoskonalić / przerobić: (1) „aplikacje” w tym kontekście, co masz na myśli (kilka przykładów?) (2) jakikolwiek pomysł, jak to może działać (stare dobre) środowiska mainframe (3) co w tym kontekście jest „łagodzące”? PS: daj mi znać, jeśli uważasz, że powinienem utworzyć nowe pytanie dla którejkolwiek z tych „rzeczy” (pocisków).
Pierre.Vriens