Testowanie a Continuous Delivery – cz.3

17 marca 2018 | Zwinny tester

No i dobrnęliśmy do ostatniej części poświęconej Continuous Delivery (i Continuous Integration). W pierwszej części skupiłam się głównie na testach, w zeszłym tygodniu natomiast zagłębiałam się trochę bardziej w teorię i narzędzia. Dzisiaj natomiast opowiem Wam o moich doświadczeniach z CI/CD.

Ze wszystkimi „ciągłymi” praktykami miałam styczność niemalże od początku swojej pracy jako tester. Były one wdrażane z różnym skutkiem, ale tak jak wspominałam w pierwszej części cyklu, CI/CD są nieodłącznym składnikiem metod zwinnych, a często nawet jeszcze wyższym poziomem bycia zwinnym. Nic więc dziwnego, że firmy w których pracowałam starały się stosować te praktyki.

Kiedyś współpracowałam z zespołem, dla którego CD było bardzo istotne i które zostało wdrożone z mojego punktu widzenia idealnie – telewizor wyświetlający dashboard ze statusami robi robotę i… no wygląda bardzo pro 🙂 Jednak zespół poświęcał sporo czasu na dbanie o proces, a telewizor był nieco kłopotliwy przy ciągłych przeprowadzkach z miejsca w miejsce – ot, taka drobnostka, wymagająca jednak nieco zaangażowania.

W innym zespole, z podobnym poziomem wtajemniczenia, monitor wyświetlający dashboard był niemalże ołtarzem w sanktuarium develompentu, a jednej z programistów niczym kapłan z czcią wpatrywał się w niego i tylko co jakiś czas wpadał w popłoch: kiedy regresja nie przeszła albo strona dawała 500.

W zespole, w którym jestem aktualnie, przez długi czas mieliśmy niemalże idealnie działające CI: w momencie kiedy wpisywaliśmy git push na Jenkinsie uruchamiany był build oraz testy jednostkowe. Byliśmy też bardzo blisko CD: eksperymentowaliśmy z automatycznym uruchamianiem testów akceptacyjnych (w naszym procesie ten rodzaj testów wykonywany jest po raz pierwszy już na branchu danej funkcjonalności). Pewnie zauważyliście, że piszę to w czasie przeszłym 😀 I nie jest to przypadek – świadomie zrezygnowaliśmy na jakiś czas z CI i CD. Przynajmniej na jakiś czas.

Powodów było kilka, ale przeważyła niestabilność maszyn na których uruchamiane były buildy. Nie mamy DevOpsów na wyłączność, więc wszystkie czynności związane z CI/CD musimy wykonywać samodzielnie, ewentualnie ze wsparciem kolegów z innych zespołów. A to w projekcie, w którym priorytetem jest przede wszystkim dowiezienie w terminie sprawia, że na „zabawy z Jenkinsem” po prostu zabrakło czasu. Okazało się, że o wiele mniej czasu zajmuje nam ręczne budowanie i odpalanie testów akceptacyjnych, niż musielibyśmy poświęcić na odpowiednie ustawienie tzw. potoku wdrożeń.

Pełne CD, które obejmowałby też automatyczne mergowanie zmian jest utrudnione przez proces – tak jak wspominałam, testy akceptacyjne wykonywane są już na branchu. A specyfika projektu, mnogość przypadków oraz pewna… wrażliwość danych wymusza na nas często wykonywanie testów eksploracyjnych, a te przecież wykonywane są ręcznie. Jest to pewien kompromis albo, jak kto woli, dług technologiczny podyktowany nieuchronnie zbliżającym się deadlinem.

Ale czy to znaczy, że wdrożenie CI/CD na tym projekcie jest niemożliwe? Przykłady projektów podobnych do naszego pokazują, że wręcz przeciwnie. Podejrzewam, że gdy tylko „postawimy projekt na nogi” i zmienią się priorytety znajdzie się więcej czasu na ulepszanie procesu. Być może też nie zarzucilibyśmy (ograniczyli?) tych praktyk, gdyby do dyspozycji naszego zespołu był DevOps, albo gdyby deadline nie był tak istotny. Na pewno większe pokrycie testami automatycznymi, które wykrywałyby te powiedzmy średnio krytyczne błędy (bo krytyczne już są wykrywane przez automaty) pozwoliłoby nam przesunąć testy eksploracyjne na staging, a co z tym idzie umożliwiłoby przynajmniej pełne działanie CI.

Tym przykładem w żadnym razie nie chcę Was zniechęcać do CI/CD. Bardziej chodzi mi o pokazanie, że CI/CD to tylko praktyki, narzędzia, które mają nam ułatwiać pracę, a nie utrudniać. Jeżeli tak nie jest, to warto czasami odpuścić, i wrócić do tematu wtedy, kiedy znajdą się zasoby (czas, sprzęt) i ewentualnie ludzie, którzy pomogą to zrealizować.

Najnowsze wpisy

CzytanQA: Steve Jobs

„Steve Job” autorstwa Waltera Isaacsona to dla mnie książka wyjątkowo z dwóch powodów. Po pierwsze, dostałam ją od bliskiej mi osoby. A po drugie dlatego, że to od niej zaczęło się moje zamiłowanie do biografii, reportaży i innych książek non-fiction.

CzytanQA: Labirynty Scruma

Scrumie książek napisano sporo. Dzisiejsza książka – Labirytnty Scruma – jest nieco inna, autor podchodzi do tematu od strony bardziej… problematycznej.

#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!