Testowanie a Continuous Delivery – cz.2

10 marca 2018 | Zwinny tester

W zeszłym tygodniu, zainspirowana przez jednego z kolegów z pracy (tak, Wojt, to o Tobie :)), rozpoczęłam cykl wpisów o Continuous Delivery, a w zasadzie o wszystkich „ciągłych” praktykach. Poprzednio luźno nawiązałam do problemu testów manualnych, w zasadzie tylko lekko nakreślając temat. Dziś będzie troszkę więcej teorii – opowiem Wam, czym różnią się te trzy praktyki, o których w branży IT mówi się coraz więcej. Dowiecie się również, co pozwala na wdrażanie tych praktyk, oraz jak ma się do nich testowanie.

Oszczędzę Wam suchych formułek, głównie dlatego, że naprawdę ciężko jest znaleźć spójne definicje. Ale praktyki są trzy: ciągła integracja (ang. Continuous Integration), ciągłe dostarczanie (ang. Continuous Delivery) oraz ciągłe wdrażanie (ang. Continuous Deployment). Mocno upraszczając różnią się one tym, jak głęboko sięga automatyzacja procesów. W CI – które wywodzi się z Extreme Programming – chodzi o to, aby twórcy programu jak łączyli wyniki swojej pracy. Każdego dnia powstaje kilka wersji głównego kodu, a każda jest sprawdzana przez automatyczny proces budowania i testowania. W Continuous Delivery automatyzacja idzie dalej, obejmując również proces wydawania na środowisko przedprodukcyjne oraz testy akceptacyjne. Tutaj od wdrożenia na produkcję dzieli nas tylko “wciśnięcie przycisku”. Z kolei dzięki Continuous Deployment również “wciśnięcie przycisku” dzieje się „automagicznie” – oczywiście jeśli budowanie oraz testy poszły zgodnie z planem. Aby lepiej zrozumieć różnice między tymi „ciągłymi praktykami” spójrzcie na poniższy diagram, który jest tłumaczeniem znalezionego na stronie Atlassian:

Co z testami?

Zarówno w CI, jak i w obu CD pojawia się automatyzacja testów. Chodzi tu głównie o testy akceptacyjne, które po zautomatyzowaniu pełnią funkcję testów regresji. Co jest zasadne, biorąc pod uwagę potrzebę jak najszybszej odpowiedzi na pytanie, czy nasz produkt działa prawidłowo. Temat jest bardzo szeroki i wolałabym poświęcić mu odrębną serię. Ale jeżeli interesują Was strategie automatyzacji testów zachęcam do lektury książki „Ciągłe dostarczanie oprogramowania. Automatyzacja kompilacji, testowania i wdrażania” autorstwa Jeza Humble’a oraz Davida Farley’a.

Najwięcej emocji jednak budzą testy manualne i pozwolę sobie jeszcze raz wrócić do tego tematu. Jak już wspominałam, są testy, z którymi człowiek radzi sobie o wiele lepiej niż maszyna (np. testy użyteczności). Są też takie, których automatyzacja jest czasami nieopłacalna lub bezsensowna. Dzięki jak największej automatyzacji testów akceptacyjnych, możemy skupić się bardziej na tych, które ciężko zautomatyzować. Przy ciągłym dostarczaniu mamy czas na automatyzację przed „wciśnięciem przycisku”. A co z ciągłym wdrażaniem? Często jest ono realizowane w formie „nightly builds” – wtedy, kiedy nikogo nie ma w biurze. Oznacza to, że zanim wyjdziemy z pracy możemy przeprowadzić te testy, które muszą być wykonane ręcznie.

Co jest potrzebne do wdrożenia CD?

Według DevOps Zone wdrożenia Continues Delivery potrzebne są narzędzia z siedmiu kategorii:

Ciągła integracja
Jak już wiecie, nie ma CD bez CI. Najpopularniejsze narzędzia to Jenkins, Atlassianowe Bamboo oraz Travis.

Kontrola wersji
Kontrola wersji jest niezbędna przy dążeniu do ciągłej integracji (i, co za tym idzie, do CD). Pozwala pracować wielu programistom na tym samym kodzie. Chyba najpopularniejszy jest jest rozproszony system kontroli wersji Git, ale często spotyka się też SVN.

Code review
Praktyka sprawdzania kodu umożliwia wychwycenie błędów, sprawdzenie zgodności ze standardami a często też poznanie pracy kolegów. Tutaj z pomocą przychodzi GitHub, a dla tych korzystających z pakietu Atlassiana zwykle Bitbucket (do niedawna znany jako Stash).

Konfiguracja
Narzędzia z tej grupy pozwalają zachować spójność środowisk w całym procesie tworzenia oprogramowania, od komputera programisty aż po produkcję. Ja najczęściej spotykam się z Vagrantem oraz Puppetem.

Monitorowanie
Monitorowanie pozwala na gromadzenie i analizę dane w środowiskach testowych, a także w innych częściach infrastruktury. Przykładem narzędzia do monitorowania jest Logstash.

Orkiestracja
Tutaj należy się kilka słów wyjaśnienia – Orkiestracja to zautomatyzowane rozmieszczenie, koordynacja i zarządzanie systemami, oprogramowaniem pośredniczącym i usługami. Stosuje się tutaj np. wspomniany już Puppet, ale również Chef.

Dashboard
Stosowanie dashboardu pozwala na pokazywanie zespołowi statusu środowisk i poszczególnych etapów CD. Jeśli np. Kompilacja nie działa, to szybko zauważymy czerwony kolor na dashboardzie. W dashboardy wyposażone są często narzędzia CI, m.in wspomniane już Jenkins i Bamboo.

To oczywiście tylko przykłady narzędzi, te są najbardziej popularne. Na Stickify znajdziecie listę aż 51 narzędzi tylko do CI, więc zachęcam Was do poszukiwań. Ten post i tak jest już dłuższy, niż planowałam 🙂 W trzeciej części opowiem Wam, jak wyglądały moje dotychczasowe doświadczenia z CI i CD.

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!