Zasady ciągłego dostarczania

Ciągłe dostarczanie jest ogólnoorganizacyjną metodyką o charakterze inkluzywnym, która łączy zespoły nietechniczne, takie jak zespoły projektowe, produktowe i marketingowe. Ciągłe dostarczanie zachęca programistów do skoncentrowania się na dostarczeniu produktu dla użytkowników końcowych w przeciwieństwie do środowisk, które nie stosują takiego podejścia i sprzyjają modelowi zapominania o wykonanej pracy od razu po jej przekazaniu do kolejnych etapów, gdzie zespół zapewniania jakości jest głównym źródłem informacji na temat wrażeń użytkowników, z jakimi programiści mają do czynienia. W kolejnych częściach omówimy konkretne zasady wyznaczające podstawę do przepływów pracy opartych na ciągłym dostarczaniu.

Procesy organizacyjne cechuje własny cykl rozwoju. Zazwyczaj mają one swój początek w listach kontrolnych ręcznie wykonywanych czynności lub poradach strategicznych zawierających wykaz zadań do ręcznego wykonania. Później mogą one zostać zautomatyzowane przy użyciu narzędzi i skryptów oprogramowania. Przekształcenie tych porad strategicznych na skrypty oprogramowania zapewnia ich powtarzalność. Jeśli konieczne jest ponowne wykonanie listy kontrolnej, członek zespołu może uruchomić skrypt. Niezawodność uzyskuje się przez spójne wykonywanie skryptów porad strategicznych w różnych środowiskach. Przykładowo porady strategiczne dotyczące wdrażania kodu w środowisku programistycznym lub przejściowym powinny możliwie jak najdokładniej odzwierciedlać środowisko produkcyjne. Taka niezawodna spójność między środowiskami i wykonaniami eliminuje całą klasę błędów spójności.

Kluczową wartość ciągłego dostarczania stanowi automatyzacja. Czas pracowników jest drogi i powinno się go poświęcać na zadania twórcze, a nie żmudne realizowanie powtarzalnych czynności z porad strategicznych. Proces ręczny nie jest rzeczywiście powtarzalny i niezawodny, dopóki nie zostanie przekształcony na kod, który można wykonać automatycznie na życzenie. Zautomatyzowane zadania można łączyć ze sobą, tworząc nowe poziomy automatyzacji. Zautomatyzuj tyle zadań, ile tylko się da: testy, wydania, zmiany w konfiguracjach i wiele innych.

Kontrola wersji będąca podstawą ciągłego dostarczania jest niezbędnym elementem każdego poważnego projektu oprogramowania. Kontrola wersji umożliwia zespołowi programistów efektywną współpracę nad wspólną bazą kodu. Git jest najczęściej używanym systemem kontroli wersji i doskonale sprawdza się w modelu ciągłego dostarczania. Kontrola wersji umożliwia „cofnięcie” funkcji dzięki możliwości przywrócenia stanu do poprzednich wydań. Kontrola wersji powinna obejmować nie tylko kod, ale także konfiguracje, skrypty, bazy danych i dokumentację, co pozwoli dokładnie prześledzić historię zmian.

W modelu ciągłego dostarczania jakość nie jest refleksją przerzucaną na zespół ds. zapewniania jakości. Jakość jest nieodłącznym elementem każdego etapu pipeline'u wydania. Centralna pętla informacji zwrotnej w modelu ciągłego dostarczania oznacza ciągłe badanie na nowo jakości dostarczanej użytkownikom końcowym. Nowe funkcje są dostarczane po wykonaniu zestawów zautomatyzowanych testów, które mają wyeliminować błędy w nowym kodzie i zapewnić spełnienie oczekiwań co do jakości. Planowanie projektów wydań nowy funkcji powinno uwzględniać zagadnienia dotyczące analizy, monitorowania wydajności i zadania opracowania zautomatyzowanych testów.

Uciążliwe, czasochłonne i podatne na błędy zadania z czasem zaczynają się gromadzić. Uciążliwymi zadaniami należy zająć się jak najszybciej, aby nie dopuszczać do olbrzymiej utraty energii w wyniku ich nawarstwienia. Wyobraź sobie uciążliwy obowiązek, którego spełnienie trwa 20 minut, a trzeba go wykonać pięć razy w tygodniu. To przekłada się na 100 uciążliwych minut tygodniowo i około 400 uciążliwych minut miesięcznie. Wyobraź sobie teraz, że możesz zająć się tym obowiązkiem raz na zawsze i zoptymalizować jego realizację tak, aby całkiem pozbyć się uciążliwego czasu. To z pewnością okaże się korzystne.

„Zacznij od tego, co najtrudniejsze” jest również ćwiczeniem, które pomaga w ujawnieniu słabości procesu organizacyjnego. Aktywnie unikane lub systematycznie przekładane na później zadanie jest oznaką potencjalnego obszaru wymagającego poprawy, którym należy aktywnie się zająć. Zespoły powinny regularnie sięgać do trudności, aby mieć świadomość ich istnienia i poruszać je w pierwszej kolejności w trakcie rozmów związanych z planowaniem.

Cała organizacja powinna koncentrować się na zapewnieniu jak najwyższej jakości produktu dostarczanego do użytkownika końcowego i wszystkich powinno się do tego zachęcać. Menedżerowie produktów powinni uważnie planować wdrożenia i zapewnianie jakości. W proces wydawania należy aktywnie zaangażować zespół ds. bezpieczeństwa. Członkowie zespołu ds. zapewniania jakości powinni przeprowadzać testy w środowiskach programistycznym i przejściowym równie rygorystycznie, co w produkcji, aby wychwycić wszelkie błędy przed ewentualnym wydaniem. Programiści powinni aktywnie planować wydania produkcyjne.

Firmy zajmujące się tworzeniem oprogramowania stawiają sobie za cel dostarczanie oprogramowania do użytkowników końcowych. Jeśli aplikacja działa tylko na jednym komputerze programisty, nie ma w tym żadnego interesu. „U mnie działa” to powszechny zwrot ostrzegawczy, wskazujący na brak świadomości ogólnego celu biznesowego oraz empatii dla użytkownika końcowego. Ciągłe dostarczanie w całości koncentruje się na dostarczaniu oprogramowania do użytkownika końcowego. Ponadto „gotowe” nie oznacza, że gotowości poszczególnych części realizowanych przez członków zespołu, tylko ukończenie całości prac przewidzianych dla zespołu.

Mam nadzieję, że z poprzednich sekcji wynurzył się wstępny obraz ogólnej wartości dodanej modelu ciągłego dostarczania. W skali makro model ten sprzyja wydajności realizacji prac, komunikacji międzyzespołowej, dopasowaniu do rynku produktu, zwinności i ogólnej przejrzystości organizacyjnej.

Na poziomie mikro ciągłe dostarczanie możne opracować na podstawie pomiarów wyraźnych wskaźników śledzenia. Wśród cennych wskaźników ciągłego dostarczania można wymienić:

• czas od fazy zaprojektowania nowej funkcji do wydania produkcyjnego,
• liczbę błędów produkcyjnych napotykanych przez użytkowników,
• poziom zaangażowania użytkowników w korzystanie z nowych funkcji,
• częstotliwość wydawania nowych funkcji.

Ponadto ciągłe dostarczanie może stanowić podstawę kreowania wskaźników wydajności organizacyjnej, takich jak wskaźniki KPI. Wreszcie doskonałą miarą wpływu na praktyki organizacyjne są przychód bazowy i kondycja finansowa firmy.

Zapoznawszy się z zaletami i zasadami ciągłego dostarczania, można przejść do wdrażania tego modelu. Dobrym punktem wyjścia jest ciągła integracja. Ciągła integracja (CI) jest prekursorem ciągłego dostarczania i koncentruje się na automatyzacji przepływu pracy związanego z wydawaniem kodu. Wykorzystuje w tym celu narzędzia do zautomatyzowanego testowania kodu oraz zadania związane z zapewnianiem jakości. Po wdrożeniu ciągłej integracji można wykorzystać ją jako podstawę do wykreowania procesów ciągłego dostarczania celem wdrażania kodu wśród użytkowników końcowych i wypracowania pętli informacji zwrotnej, która będzie określała kierunek przyszłych wydań.