Czym jest Continuous Delivery?

W pierwszym artykule z serii „Techniczny Poradnik Product Managera” opisałem bardzo wartościową praktykę programistyczną, jaką jest ciągła integracja (ang. continuous integration). Prawidłowe jej zrozumienie i wdrożenie w organizacji dostarcza korzyści nie tylko zespołowi wytwórczemu, ale również każdemu Product Managerowi, który z takim zespołem współpracuje. W celu uzyskania jeszcze większego zwrotu z inwestycji, ciągłą integrację należy rozszerzyć o kolejny element — ciągłe dostarczanie (ang. continuous delivery). Należy tutaj zaznaczyć, iż wdrożenie tej praktyki jest niemożliwe bez wcześniejszego wdrożenia ciągłej integracji.

Ciągłe dostarczanie, czyli sprawdźmy, czy na pewno działa

Ciągłe dostarczanie (ang. continuous delivery) jest praktyką programistyczną, gdzie zespół wytwarza oprogramowanie w krótkich cyklach (np. dwutygodniowych sprintach), posiadając cały czas pewność, że każda kolejna zmiana w kodzie, bez względu na jej rozmiar, może zostać wydana (zaprezentowana użytkownikowi końcowemu) w dowolnym momencie. Głównym celem continuous delivery jest szybsze i częstsze budowanie, testowanie oraz wydawanie oprogramowania.

„Ciągłe dostarczanie to praktyka programistyczna, gdzie oprogramowanie jest budowane w taki sposób, że może ono zostać opublikowane na środowisku produkcyjnym w dowolnej chwili.”

Martin Fowler

Wyżej wymienione etapy takie jak budowanie czy testowanie oprogramowania są składowymi tzw. procesu wdrażania (ang. deployment process). Zawiera on w sobie wszystkie etapy, które muszą zostać pozytywnie zakończone dla każdej zmiany wprowadzonej przez jakiegokolwiek członka zespołu, aby zespół miał pewność, że zmiana ta może zostać bezpiecznie opublikowana na środowisku produkcyjnym. Poziom skomplikowania i liczba etapów samego procesu wdrażania będzie różna dla różnych zespołów produktów i organizacji, jednakże przede wszystkim powinien on być powtarzalny, a więc w dużej mierze zautomatyzowany.

Wróćmy na chwilę do Andrzeja i Tomka, czyli dwóch przykładowych programistów z pierwszego artykułu cyklu. Załóżmy, że wykorzystując prawidłowo wdrożoną ciągłą integrację, Andrzej po kilku godzinach pracy wgrał wprowadzone zmiany do centralnego współdzielonego repozytorium kodu. Zmiana ta została automatycznie wykryta przez serwer ciągłej integracji, który uruchomił wszystkie napisane wcześniej testy jednostkowe, które zakończyły się powodzeniem (tzw. zielony build). Taka weryfikacja na serwerze ciągłej integracji to najczęściej pierwszy etap procesu wdrażania. Jednak same testy jednostkowe nie dają zespołowi stuprocentowej gwarancji, że zmiany wprowadzone przez Andrzeja mogą zostać bezpiecznie zaprezentowane użytkownikowi końcowemu. Dlatego też, dobry proces wdrażania powinien składać się z co najmniej kilku etapów.

Bardzo często jednym z kolejnych kroków sprawdzających są testy regresywne lub wydajnościowe przeprowadzane z wykorzystaniem środowiska jak najbardziej zbliżonego do środowiska produkcyjnego (np. środowisko stagingowe). Należy tutaj podkreślić, że zmiany dokonane przez Andrzeja „przechodzą” do kolejnego etapu procesu wyłącznie, jeżeli obecny etap zakończył się sukcesem. Podejście takie pozwala na jak najszybsze wykrycie ewentualnych problemów. Jednocześnie, tak samo, jak w przypadku ciągłej integracji, zespół powinien otrzymywać automatycznie informację zwrotną w razie jakiegokolwiek niepowodzenia (np. poprzez notyfikację na Slacku).

Tak jak ciągła integracja nie ma większego sensu bez kodu źródłowego pokrytego wystarczającą liczbą dobrych testów jednostkowych, tak ciągłe dostarczanie jest bezużytecznie bez prawidłowo wdrożonej ciągłej integracji oraz dodatkowo wartościowych testów wyższych poziomów. Co więcej, aby móc w pełni wykorzystać zalety ciągłego dostarczania, proces wdrażania musi być wystarczająco rozbudowany, a zarazem powtarzalny — wszystkie jego etapy powinny zostać w jak największym stopniu zautomatyzowane. Automatyzacja pozwala na wyeliminowanie potencjalnych błędów spowodowanych czynnikiem ludzkim.

Wartość z ciągłej integracji i ciągłego dostarczania dla Product Managera

Czy Product Manager odpowiedzialny za sukces produktu może czerpać jakiekolwiek korzyści z wdrożenia continuous integration oraz continuous delivery?

Szybsza informacja zwrotna od użytkowników

Jedną z głównych zalet stosowania powyższych praktyk jest z całą pewnością szybszy feedback. Musisz pamiętać, że to co Ty uważasz za „dobre” dla Twoich użytkowników, niekoniecznie może okazać się prawdą. Szybsze uzyskanie informacji zwrotnej pomoże Ci więc w przekonaniu się czy idziesz w dobrą stronę czy jednak należy dokonać zmiany. Oczywiście, wcześniejsze zdefiniowanie hipotez poprzez wywiady, testy czy prototypy będzie bardzo pomocne. Nic jednak nie zastąpi szczerej opinii użytkownika po skorzystaniu z nowej wersji produktu.

Redukcja czasu i oszczędność pieniędzy

Szybsza informacja zwrotna od użytkowników stanowi konkretną wartość w przypadku przyszłych decyzji. Co w przypadku, gdy okaże się, że funkcja, nad którą pracowałe(a)ś z zespołem przez ostatnie kilka miesięcy wcale nie jest potrzebna? Stracisz z całą pewnością mnóstwo czasu i pieniędzy. Dostarczając wartość stopniowo i iteracyjnie, szybciej dojdziesz do prawidłowego rozwiązania problemu.

Tworzenie produktów wyższej jakości

Prawdopodobnie jakość nie zawsze jest dla Ciebie priorytetem, ale na pewno zgodzisz się ze mną, że jest ona równie ważna jak funkcjonalności, które Twój produkt oferuje. Ciągłe dostarczanie pozwala na to, aby Twoja usługa była cały czas dostępna, a także przekłada się na mniejszą liczbę błędów, na które napotkają użytkownicy. Brak błędów przeniesie się na większy poziom zadowolenia, a to z kolei na większą liczba poleceń produktu i większe prawdopodobieństwo sukcesu.

Podsumowanie

Niewątpliwie prawidłowe wdrożenie ciągłej integracji i ciągłego dostarczania wymaga sporej ilości czasu i pieniędzy. Bardzo często pociąga za sobą również wiele zmian na poziomie zespołu, a nierzadko organizacji. Niemniej jednak jest to gra warta świeczki: szybsza informacja zwrotna od użytkownika, większa produktywność i efektywność zespołu wytwórczego, wzrost jakość oraz większa satysfakcja użytkowników to tylko niektóre z korzyści, których praktyki te dostarczają.