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

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?

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.

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.

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ć :)?

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.

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.