Close

Zasady ciągłego dostarczania

Poznaj podstawowe zasady leżące u podstaw ciągłego dostarczania z naszymi przewodnikami dla początkujących.


Ciągłe dostarczanie (CD) jest zbiorem wielu wcześniejszych skutecznych praktyk Agile i najlepszych praktyk organizacyjnych. Celem organizacji praktykującej ten model jest utworzenie sprawnego, zautomatyzowanego procesu wydawania oprogramowania. Istotą procesu wydawania jest iteracyjna pętla informacji zwrotnych. Taka pętla informacji zwrotnych skupia się na jak najszybszym dostarczaniu oprogramowania do użytkownika końcowego, czerpania z praktycznego doświadczenia użytkowników, a następnie uwzględniania ich opinii w kolejnym wydaniu.

Ciągła integracja, ciągłe dostarczanie a ciągłe wdrażanie

Zawsze dostępne usługi wymagają, aby zespoły swoją strukturę, wartości i narzędzia pozwalające zapewnić, że doskonałość operacyjna stanie się podstawową kompetencją. Przeczytaj artykuł

Wartość biznesowa ciągłego dostarczania

Wartość biznesowa ciągłego dostarczania nie ogranicza się do zagadnień technologicznych. Ciągłe dostarczanie poprawia prędkość, produktywność i zrównoważony rozwój zespołów programistycznych. Przeczytaj artykuł

Mapowanie strumienia wartości

Mapowanie strumienia wartości to technika analityczna, która pomaga w optymalizacji pipeline'u ciągłego dostarczania. Dowiedz się, w jaki sposób i do czego jest wykorzystywana. Przeczytaj artykuł


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.

Schemat przedstawiający przepływ kodu komputerowego i elementów prac w modelu ciągłym | Atlassian CI/CD

Powtarzalny niezawodny proces

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.

Zautomatyzuj wszystko

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

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.

Wbudowana jakość

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.

Zacznij od tego, co najtrudniejsze

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.

Każdy ponosi odpowiedzialność

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.

Zespół współpracuje przy kontroli kodu przed wydaniem. | Atlassian CI/CD

„Gotowe” oznacza wydane

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.

Ciągłe doskonalenie

Wartość ciągłego dostarczania

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.

Ciągłe dostarczanie — pierwsze kroki

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ń.

Max Rehkopf
Max Rehkopf

Jako samozwańczy „władca chaosu” wykorzystuję praktyki Agile i zasady Lean, aby wprowadzić w swoje życie codzienne nieco porządku. Dzielenie się własnymi wnioskami poprzez liczne artykuły, pogadanki i filmy, jakie przygotowuję dla Atlassian, sprawia mi wielką radość. 


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