Close

Ciągłe dostarczanie: wartość biznesowa, korzyści, wyzwania i wskaźniki

Ciągłe dostarczanie poprawia prędkość, produktywność i zrównoważony rozwój zespołów programistycznych.

Zdjęcie portretowe Juni Mukherjee
Juni Mukherjee

Autor współpracujący

Dlaczego ciągłe dostarczanie?


Jakie emocje budzi w Tobie słowo „wydanie”? Ulgę? Uniesienie? Triumfalne poczucie spełnienia? Gdy nowe funkcje trafiają wreszcie do klientów, a błędy zostają usunięte, wszyscy są zadowoleni, prawda? Cóż, mrocznym sekretem wielu organizacji jest fakt, że wysłanie wydania wymaga ogromnego wysiłku. Jeśli Twój zespół wciąż przygotowuje się do wydania, ręcznie przeprowadzając testy, a następnie przeprowadza wydania w formie ręcznych lub częściowo zautomatyzowanych wdrożeń, Twoje odczucia mogą oscylować bliżej „przerażenia” i „ślepej wściekłości”.

Zrzut ekranu emocjonalnego cyklu związanego z ręcznym dostarczaniem

Dlatego tworzenie oprogramowania przesunęło się w kierunku ciągłości, wdrażając takie metodyki, jak Agile czy DevOps. W paradygmacie opartym na ciągłości wysokiej jakości produkty często i w przewidywalnym czasie udostępnia się klientom. To z kolei pozwala ograniczyć ceremoniały i ryzyko związane z wydaniem. Jeśli na co dzień polegasz na swoich pipeline'ach, zauważysz (i wyeliminujesz!) ich niedociągnięcia znacznie szybciej niż w sytuacji, gdy realizujesz je raz na kilka tygodni czy miesięcy. To pozwala obniżyć poziom trudności przez zwiększenie częstotliwości wydań produktów. Kultura ciągłego doskonalenia jest wskaźnikiem DevOps dla zespołów osiągających wysokie wyniki.

Nacisk na ciągłe dostarczanie, w tym ciągłą integrację, ciągłe testowanie, stałe monitorowanie oraz analizowanie pipeline'ów wskazują na ogólny trend w branży tworzenia oprogramowania, ułatwiając zespołom reagowanie na zmiany zachodzące na rynku. Nie daj się zwieść — ciągłe dostarczanie nie jest wyłączną domeną wyjątkowych firm i technologicznych znawców. Każdy zespół — od najskromniejszego start-upu po najbardziej skostniałe przedsiębiorstwo — może i powinien praktykować ciągłe dostarczanie.

W tym artykule przyjrzymy się uzasadnieniu biznesowemu dokonania tej zmiany. Omówimy pracę, która jest przed nami, oraz korzyści, jakie przyniesie wysyłanie oprogramowania przy użyciu pipeline'ów CD.

Poznaj rozwiązanie

Tworzenie i obsługa oprogramowania za pomocą Open DevOps

Materiały pokrewne

Zmierz częstotliwość wdrożeń

Najważniejsze korzyści biznesowe wynikające z ciągłego dostarczania


Ciągłe dostarczanie poprawia prędkość, produktywność i zrównoważony rozwój zespołów tworzących oprogramowanie.

1. Prędkość

Zautomatyzowane pipeline'y dostarczania oprogramowania pomagają organizacjom lepiej reagować na zmiany rynkowe. Potrzeba szybkości ma ogromne znaczenie dla skrócenia czasu opóźniania wysyłki nowych funkcji. Skracając czas wprowadzania na rynek, organizacje mają większą szansę na wyprzedzenie konkurencji i pozostanie w interesie.

Pamiętaj, że prędkość sama w sobie nie jest wskaźnikiem sukcesu. Bez jakości prędkość jest nie ma znaczenia. Pipeline'y ciągłego dostarczania pozwalające na błyskawiczne wysyłanie do produkcji błędnego kodu są bezwartościowe.

Błąd

Zatem w świecie ciągłego dostarczania prędkość oznacza odpowiedzialne, ale nie samobójcze tempo.

2. Produktywność

Produktywność przekłada się na zadowolenie, a zadowolone zespoły są bardziej zaangażowane.

Produktywność wzrasta, gdy żmudne i powtarzalne zadania, takie jak wypełnianie raportu o błędzie dla każdej wykrytej usterki, mogą być wykonywane przez pipeline'y zamiast przez ludzi. Pozwala to zespołom skupić się na wizji, podczas gdy pipeline'y zajmują się realizacją. A kto nie chce delegować dużych obciążeń na narzędzia?

Zespoły analizują problemy zgłaszane przez ich pipeline'y, a po zatwierdzeniu poprawki pipeline'y te są uruchamiane ponownie w celu sprawdzenia, czy problem został rozwiązany oraz czy przypadkowo nie wprowadzono nowych problemów.

Ludziki patrzące na procedury tworzenia oprogramowania

3. Zrównoważony rozwój

Firmy chcą wygrywać maratony, nie tylko sprinty. Wiemy, że wyjście przed szereg wymaga odwagi. Jeszcze trudniej jest utrzymać swoją pozycję przed tym szeregiem. Wymaga to dyscypliny i rygoru. Ciężka praca 24/7 doprowadzi do przedwczesnego wypalenia. Zamiast tego pracuj mądrze i deleguj powtarzalne prace maszynom, które, nawiasem mówiąc, nie potrzebują przerw na kawę i nie pyskują!

Każda organizacja, niekoniecznie o profilu technologicznym, wykorzystuje technologię, aby wyróżnić się na rynku. Zautomatyzowane pipeline'y ograniczają liczbę ręcznie wykonywanych prac, a ostatecznie prowadzą do oszczędności, ponieważ zatrudnianie personelu jest droższe od narzędzi. Znaczna inwestycja na początku może budzić wątpliwości u niedoświadczonego kierownictwa, jednak dobrze zaprojektowane pipeline'y dają organizacjom możliwość lepszego i szybszego tworzenia innowacji zaspokajających potrzeby ich klientów. Ciągłe dostarczanie zapewnia firmie większą elastyczność w dostarczaniu funkcji i poprawek. Określone zestawy funkcji mogą być udostępniane konkretnym klientom lub konkretnej grupie klientów, aby zyskać pewność, że będą one działały i skalowały się zgodnie z przewidywaniami. Funkcje można testować i rozwijać bez aktywowania ich w produkcie przez wiele wydań. Twój dział marketingu chce zaskoczyć odbiorców na dorocznym konwencie branżowym czymś spektakularnym? Z modelem ciągłego dostarczania jest to nie tylko możliwe, ale wręcz proste.

Najważniejsze wyzwania związane z ciągłym dostarczaniem


Choć żywimy głębokie przekonanie, że ciągłe dostarczanie jest właściwym podejściem, dla wielu organizacji opracowanie i wdrożenie solidnych pipeline'ów ciągłego dostarczania może stanowić wyzwanie. Ciągłe dostarczanie wymaga poważnego przekształcenia procesów technicznych, kultury działania i myślenia organizacyjnego, co często wydaje się znaczną przeszkodą uniemożliwiającą postawienie pierwszych kroków. Fakt, że wymaga ono znacznych inwestycji w infrastrukturę umożliwiającą dostarczanie oprogramowania firmy, która być może przez wiele lat była zaniedbywana, sprawia, że perspektywa ta staje się jeszcze trudniejsza do przełknięcia.

Istnieje wiele problemów, z którymi borykają się organizacje, a najczęstszymi pułapkami wśród nich są budżet, ludzie oraz priorytety.

Budżet: czy Twój jest zbyt niski?

Tworzenie pipeline'ów ciągłego dostarczania zajmuje najlepszych ludzi. Nie jest to projekt poboczny, którego koszt można zamieść pod dywan. Zawsze zaskakiwało mnie, w jaki sposób niektóre organizacje zaczynają od przydzielania młodszych członków zespołu oraz szukania oszczędności na zakupie nowoczesnych narzędzi. Na pewnym etapie korygują swój tok postępowania i przydzielają starszych architektów do inwestycji w rozdzielenie architektury i opracowanie solidnych pipeline'ów ciągłego dostarczania.

Nie zaczynaj od obniżania poprzeczki. Bazując na swojej wizji, odłóż odpowiednią kwotę, aby mieć pewność że inwestycja zostanie zrealizowana bez problemów. Udostępnij minimalną funkcjonalną wersję pipeline'u ciągłego dostarczania, a następnie przeskaluj ją na całą organizację.

Czy masz osoby, które myślą przyszłościowo?

Nawet jeśli będziesz dysponować budżetem, ostatecznie może okazać się, że problemem w realizacji będą ludzie.

Zespoły powinny nieustraszenie dążyć do automatyzacji swoich zadań, a następnie przechodzić do nowych projektów. Jeśli Twoi ludzie obawiają się powierzać zautomatyzowanym agentom zadania, które w innym przypadku musieliby wykonywać ręcznie, zatrudniasz niewłaściwe osoby.

Jeśli czujesz, że nie dasz rady ruszyć dalej, zmień bieg. Naucz się dawać zespołowi samochód tam, gdzie proszą jedynie o szybszego konia. Na początku skorzystaj z pomocy doświadczonych specjalistów, którzy pomogą Ci uporać się z tymi wstępnymi trudnościami. W końcu to ludzie są Twoim najcenniejszym zasobem i zapewnij im szkolenie, które umożliwi im podjęcie właściwych działań. Ułatw podejmowanie właściwych kroków i utrudnij działanie w sposób niewłaściwy, a wyniki będą dla Ciebie miłym zaskoczeniem.

Brak priorytetów

„Zatrzymajmy prace i opracujmy pipeline'y ciągłego dostarczania!” — nie powiedział nigdy żaden product owner.

Na ich obronę można powiedzieć, że są skoncentrowani na wyprzedzaniu konkurencji w tworzeniu nowych funkcji, które zachwycą odbiorców na całym świecie. Jednocześnie zdajesz sobie sprawę, że masz problem, jeśli w każdym planowaniu sprintu wartość pipeline'ów ocenia się przez porównanie z funkcjami produktów, a w konsekwencji się je odrzuca.

W backlogach niektórych produktów pipeline'y, jeśli w ogóle się pojawiają, dożywotnio okupują pozycje najbliższe dolnej kreski. Krótkowzroczne kierownictwo klasyfikuje prace związane z pipeline'ami jako wydatki, a nie inwestycje, które zapewnią zespołom lepszą pozycję. Wypierają oni długoterminowe szkody, jakie generują, i niestety często uchodzi im to na sucho.

Pipeline'y są jak higiena. Jeśli chcesz się utrzymać na rynku, zadaj sobie pytanie „czy higiena jest ważna”. Założę się, że odpowiesz twierdząco.

Wskaźniki ciągłego dostarczania


Przetwarzanie transakcji online (OLTP) oraz przetwarzanie analityczne online (OLAP) to dwie dobrze znane w branży techniki. Obydwa pojęcia odnoszą się do pipeline'ów ciągłego dostarczania i pomagają generować analizy popychające organizacje we właściwym kierunku. Przyjrzyjmy się, w jaki sposób.

W Pipeline'ach znajduje się ogrom danych transakcyjnych

Wyobraź sobie typowy dzień z życia zespołu programistycznego. Zespół zatwierdza funkcję, którą firma uznała za priorytetową, następnie zatwierdza testy dla tej funkcji i integruje wdrożenia z pipelinem ciągłego dostarczania, aby każda zmiana była wdrażana automatycznie. Zespół uzmysławia sobie, że po dodaniu nowej funkcji, aplikacja zaczęła działać powoli, i zatwierdza poprawkę problemu z wydajnością. Zespół dodaje również testy wydajności, aby się upewnić, że niewłaściwe czasy reakcji zostaną wychwycone przed przeniesieniem aplikacji ze środowiska testowego do przejściowego.

Wyobraź sobie, że każdy taki commit jest transakcją. W ten sposób zespoły tworzące oprogramowanie idą naprzód — transakcja za transakcją — aż powstanie produkt, który zachwyci świat. A potem znów ruszają. Pomnóż te transakcje przez wszystkich inżynierów i wszystkie zespoły w Twojej organizacji, a okaże się, że masz do dyspozycji ogrom danych transakcyjnych.

Ilustracja przedstawiająca dwóch współpracowników spoglądających na siebie znad biurek z monitorami, przy których siedzą

To dobry skrót do kolejnego stopnia analiz pipeline'ów i lepszego wykorzystania tych danych transakcyjnych.

Przeanalizujmy dane transakcyjne pipeline'u

Czy moglibyśmy przeanalizować dane transakcyjne, aby wydobyć z nich pęczki informacji? Pewnie, że tak!

Podobnie jak w przypadku wszystkich danych transakcyjnych, ilość danych sprawia, że same w sobie nie wnoszą zbyt wiele. Dlatego powinniśmy agregować dane i przeprowadzać analizy, aby uzyskać lepszy wgląd w naszą organizację. Analizy pomagają nam dostrzec całość obrazu, jaki tworzą części układanki. Poniżej przedstawiliśmy trzy przykłady ulepszenia naszych praktyk dzięki analizom pipeline'ów i wyciąganiu z nich wniosków.

Na podstawie setek wdrożeń realizowanych każdego tygodnia wywnioskowaliśmy, że liczba nieudanych wdrożeń aplikacji A jest trzy razy większa niż w przypadku aplikacji B. To odkrycie skłoniło nas do przyjrzenia się decyzjom projektowym w zakresie stabilności środowiska i zarządzaniu konfiguracjami w kontekście aplikacji A. Okazało się, że zespół używał do wdrażania w swoim centrum danych niespójnych maszyn wirtualnych, podczas gdy aplikacja B była skonteneryzowana. Potraktowaliśmy zatem priorytetowo inwestycję w niezmienną infrastrukturę, a po miesiącu przeprowadziliśmy kontrolę, aby się upewnić, że zwrot z tej inwestycji był dobry. I faktycznie taki był. To, co da się zmierzyć, można naprawić.

Kolejnym przykładem jest sytuacja, gdy dowiedzieliśmy się, że w ostatnich kilku kwartałach liczba błędów statycznej analizy kodu aplikacji B wykazuje tendencję wzrostową. Mogło to oznaczać, że zespół odpowiedzialny za aplikację B wymaga doszkolenia celem poprawy jakości pisanego kodu. Odkryliśmy również, że narzędzia do statycznej analizy kodu zgłaszały fałszywe błędy, co oznacza, że dodawały flagi naruszenia zasad kodu, podczas gdy takie naruszenia nie występowały. Zamieniliśmy narzędzie analityczne tego zespołu na dobrze znane standardowe narzędzie branżowe i w pewnym stopniu udało się ograniczyć liczbę fałszywych błędów. Zorganizowaliśmy warsztaty pisania kodu, w trakcie których omówiono i rozwiązano istotne błędy analizy statycznej. Ostatecznie zespół znów zaczął pracować bardzo sprawnie.

Innym ciekawym wnioskiem z analizy było stwierdzenie, że testy jednostkowe aplikacji A obejmują mniej testów pokrycia niż testy aplikacji B i C, a mimo to w zeszłym roku liczba błędów produkcyjnych tej aplikacji była mniejsza. Pisanie testów jednostkowych i przeprowadzanie testów pokrycia jest w porządku. Jednak przywiązywanie nadmiernej wagi do tej aktywności jest mało produktywne z punktu widzenia zespołu i nieprzydatne dla klientów. Wyciągnęliśmy odpowiednie wnioski.

Kluczowe wskaźniki wydajności (KPI)

W kwestii naprowadzania organizacji na właściwy kierunek nie można polegać na opiniach. Najpierw musimy zdefiniować wskaźniki KPI na podstawie naszej wizji sukcesu. Następnie musimy podejmować decyzje oparte na danych, analizując wskaźniki KPI na przestrzeni miesięcy, kwartałów i lat.

Organizacyjne i wydziałowe wskaźniki KPI

Wielokrotnie obserwowaliśmy, jak poszczególne działy definiują własne wskaźniki sukcesu. Dobrze, jeśli działy są świadome oblicza swojego sukcesu, pod warunkiem że przyjęte wskaźniki odpowiadają celom organizacji.

Błędy w testach, środowisku przejściowym i produkcji

Niektóre organizacje wymagają od programistów posiadania środowiska testowego, od działu zapewniania jakości — własnego środowiska przejściowego, a od zespołu odpowiedzialnego za eksploatację systemów informatycznych — własnego środowiska produkcyjnego. Zamiast zasypywania programistów raportami z testów pokrycia przeprowadzanych w ramach testów jednostkowych wykonywanych w środowisku testowym, ważne, aby zapewnić im możliwość cofnięcia się o krok i spojrzenia z szerszej perspektywy na wszystkie środowiska, bez względu na to, czy są ich właścicielami.

Odsetek błędów w środowisku przejściowym wynikających z przeprowadzanych testów wydajności może być wysoki, co może wynikać z niewłaściwych wartości referencyjnych lub powolnego działania kodu. Analiza porównawcza może wykazać, że pipeline'y wykazują błędy przede wszystkim w integracyjnych testach smoke w środowisku produkcyjnym, a to uzasadniałoby przeprowadzenie bliższej analizy. Główną przyczyną mogą być autentyczne błędy w produkcie lub błędy w kodzie testów, niedokładne dane testowe, niepoprawna konfiguracja testowa, nieporozumienia między zespołem produktowym a technicznym itp.

Dalsza analiza może ujawnić powszechne stosowanie nieprawidłowych konfiguracji testów, skłaniając do priorytetowego potraktowania usunięcia tych problemów w celu wyeliminowania częstych błędów przy integracji. Poza tym przyznanie programistom własności kodu w całym procesie, aż do produkcji, jest również zgodne z paradygmatem DevOps.

Wskaźnik stabilności

Po zdefiniowaniu wskaźników KPI bardzo ważne jest dla nas ustalenie, czy pojedynczy wskaźnik wykazuje jakiś trend i skłania się w jednym konkretnym kierunku. Jeśli tak, musimy zrównoważyć go innymi wskaźnikami KPI, które pozwolą przesunąć punkt ciężkości w kierunku środka. Jednym z takich wskaźników KPI jest stabilność.

Do pomiaru stabilności programiści wykorzystują wskaźnik „Czas wdrożenia funkcji”, który oznacza czas potrzebny na aktywne wdrożenie jednej funkcji w środowisku produkcyjnym. Funkcja składa się z wielu commitów, dlatego stosuje się również bardziej szczegółowy wskaźnik „Zaewidencjonowanie do wdrożenia”, który oznacza czas do zaewidencjonowania do aktywnego wdrożenia w środowisku produkcyjnym.

Wskaźnik „Zaewidencjonowanie do wdrożenia” warto mierzyć z wykorzystaniem pipeline'u, ponieważ w przybliżeniu odnosi się on do czasu, jaki w pipelinie zajmuje przepuszczenie kodu od środowiska testowego, poprzez przejściowe, aż do produkcyjnego. Ponadto wskaźnik „Zaewidencjonowanie do wdrożenia” wskazuje również na problemy ze średnim czasem rozstrzygania (MTTR), ponieważ poprawka błędu przechodzi przez ten sam pipeline — od środowiska testowego, poprzez przejściowe, aż po produkcję.

Co ciekawe, w rozmowach z członkami zespołu ds. eksploatacji systemów informatycznych szybkość często budziła negatywne skojarzenia, ponieważ ludzi zachęca się do unikania ryzyka. Zespół mierzy liczbę wad, jakie umknęły uwadze, co stanowi wskaźnik awaryjności, a następnie definiuje stabilność na podstawie odsetka wad wychwyconych przez pipeline, w odróżnieniu od wad, które przemknęły niezauważone.

Firma definiuje stabilność na podstawie zadowolenia klientów lub liczby stałych klientów. Choć brzmi to subiektywnie wartość tego wskaźnika można oszacować w przybliżeniu na podstawie liczby problemów zgłaszanych przez klientów lub ankiet opinii klientów.

Wskaźnik stabilności jest klasycznym przykładem opiniowania zespołów programistycznych, eksploatacyjnych i biznesowych z ich własnej perspektywy, jednak dla organizacji lepiej jest opracować zestaw wskaźników niż polegać na jednym. W związku z tym trzeba opracować bezstronny wskaźnik stabilności dla organizacji.

Wskaźnik jakości kodu

Innym przykładem, w którym należy uwzględnić różne punkty widzenia, jest jakość kodu. Niektórzy twierdzą, że jakość naszego kodu znajduje odzwierciedlenie w testach pokrycia wykonywanych w ramach testów jednostkowych, podczas gdy inni twierdzą, że mamy tu do czynienia ze złożonością cykliczną. Standardowe analizatory statyczne zgłaszają przypadki powielenia kodu, luki w zabezpieczeniach i potencjalne wycieki z pamięci. Wszystkie te dane są autentyczną miarą jakości kodu, dlatego trzeba opracować wskaźnik, w którym te, a być może także inne dane będą uwzględniane.

Biznesowe wskaźniki KPI a techniczne wskaźniki KPI

Innym popularnym wskaźnikiem KPI, który organizacje lubią śledzić, jest wartość dostarczana w trakcie sprintu. Często spotykaną złą praktyką jest rejestrowanie wielu wydań, które same w sobie nie dodają wartości. Można przenosić bity z punktu A do punktu B tak, że wskazówka rozwoju firmy ani drgnie, ale to nie wystarczy. Niektóre organizacje mierzą liczbę nowo dodanych testów w danym sprincie lub całkowitą liczbę wykonanych testów, a to nie odzwierciedla wyników biznesowych, a jedynie nakład prac technicznych. Wartość dostarczana w ramach sprintu musi być adekwatna do działalności.

Do przykładów biznesowych wskaźników KPI można zaliczyć przykładowo liczbę klientów pozyskanych w ostatnim kwartale oraz liczbę reklam klikniętych w zeszłym miesiącu. Pipeline'y nie wpływają bezpośrednio na te wskaźniki biznesowe. Jedynym powodem, dla którego podejmujemy próbę odwzorowania biznesowych wskaźników KPI w technicznych wskaźnikach KPI, jest zrozumienie relacji między rzemieślniczą pracą techniczną a celami biznesowymi.

Odwzorowanie biznesowych wskaźników KPI w pipeline'ach pomaga również w obliczaniu zwrotu z inwestycji dla pipeline'ów. Zespoły kierownicze wykorzystują te wskaźniki, aby poznać możliwe obszary doskonalenia i zaplanować budżet.

Zacznij swoją podróż


Nie trać czasu na dywagowanie, czy ciągłe dostarczanie jest w Twoim przypadku odpowiednim rozwiązaniem, czy ciągła integracja wystarczy lub czy ciągłe wdrażanie to faktycznie droga do raju. Wkroczenie na tę drogę otworzy przed Twoim zespołem nowe możliwości ciągłego doskonalenia. Zespoły będą mogły eksperymentować bez obaw i unikną wypalenia spowodowanego wydaniami w późnych godzinach nocnych.

Skorzystaj z naszych samouczków na temat CI/CD w DevOps, aby się dowiedzieć, jak utworzyć pipeline ciągłej integracji, ciągłego dostarczania i ciągłego wdrażania (CI/CD). Ponadto Open DevOps firmy Atlassian zapewnia dostęp do otwartej platformy łańcucha narzędzi umożliwiającej tworzenie pipeline'u programistycznego opartego na CD z wykorzystaniem ulubionych narzędzi.

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.


Udostępnij ten artykuł

Zalecane lektury

Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.

Ilustracja DevOps

Społeczność DevOps

Ilustracja DevOps

Przeczytaj blog

Ilustracja przedstawiająca mapę

Zacznij korzystać za darmo

Zapisz się do newslettera DevOps

Thank you for signing up