Porównanie ciągłej integracji oraz ciągłego dostarczania i wdrażania
Poznaj różnice między tymi „ciągłymi” praktykami
Sten Pittet
Autor współpracujący
CI i CD to dwa akronimy często używane w nowoczesnych praktykach programistycznych i DevOps. CI odnosi się do ciągłej integracji, czyli podstawowej najlepszej praktyki DevOps polegającej na częstym scalaniu zmian w kodzie z centralnym repozytorium, w którym kompilacje oraz testy uruchamiane są automatycznie.Natomiast akronim CD może oznaczać ciągłe dostarczanie lub ciągłe wdrażanie.
Czym różnią się od siebie ciągła integracja, ciągłe dostarczanie i ciągłe wdrażanie (CI/DC)?
Ciągła integracja
Programiści praktykujący ciągłą integrację jak najczęściej scalają swoje zmiany z gałęzią główną. Zmiany wprowadzone przez programistów są weryfikowane przez utworzenie kompilacji i poddanie jej zautomatyzowanym testom. W ten sposób unika się trudności integracyjnych, jakie mogą wystąpić, gdy ze scaleniem zmian z gałęzią wydania czeka się do dnia wydania.
W ciągłej integracji duży nacisk kładzie się na automatyzację testów w celu sprawdzenia, czy aplikacja nie została uszkodzona, po każdym zintegrowaniu nowych commitów z gałęzią main.
Ciągłe dostarczanie
Ciągłe dostarczanie jest rozszerzeniem ciągłej integracji, ponieważ polega na automatycznym wdrażaniu wszystkich zmian w kodzie do środowiska testowego i/lub produkcyjnego po przeanalizowaniu kompilacji w środowisku przejściowym.
Oznacza to, że oprócz automatycznego przeprowadzania testów można zastosować zautomatyzowany proces wydawania i wdrożyć aplikację w dowolnej chwili kliknięciem przycisku.
Teoretycznie w przypadku ciągłego dostarczania możesz zdecydować się na wydawanie kodu codziennie, co tydzień, co dwa tygodnie lub z dowolną częstotliwością odpowiadającą Twoim wymaganiom biznesowym. Jeśli jednak naprawdę chcesz czerpać korzyści z ciągłego dostarczania, musisz postawić na możliwie jak najwcześniejsze wdrażanie do środowiska produkcyjnego, aby móc wydawać małe partie, których naprawienie w razie wystąpienia problemu będzie łatwiejsze.
Poznaj rozwiązanie
Tworzenie i obsługa oprogramowania za pomocą Open DevOps
Materiały pokrewne
Czym jest pipeline DevOps?
Ciągłe wdrażanie
Ciągłe wdrażanie to kolejny krok po ciągłym dostarczaniu. W tym modelu każda zmiana, która przejdzie przez wszystkie etapy pipeline'u produkcyjnego zostaje wydana klientom. Ingerencja ludzka zostaje wyeliminowana, a wdrożeniu zmiany do środowiska produkcyjnego może zapobiec tylko niepomyślny wynik testu.
Ciągłe wdrażanie stanowi doskonały sposób na przyspieszenie pętli informacji zwrotnej w relacji z klientami i odciążenie zespołu poprzez wyeliminowanie „dnia wydania”. Programiści mogą skoncentrować się na tworzeniu oprogramowania i obserwować efekty swojej pracy w środowisku produkcyjnym w ciągu kilkunastu minut od momentu ich ukończenia.
Powiązania między tymi praktykami
Upraszczając, ciągła integracja stanowi element zarówno ciągłego dostarczania, jak i ciągłego wdrażania. Ciągłe wdrażanie przypomina ciągłe dostarczanie, przy czym różnica polega na tym, że wydawanie odbywa się automatycznie.
Zalety poszczególnych praktyk
What are the benefits of each practice?
Wyjaśniliśmy różnicę między ciągłą integracją, ciągłym dostarczaniem a ciągłym wdrażaniem, jednak wciąż nie powiedzieliśmy sobie, dlaczego warto wprowadzić te modele. Implementacja każdej z tych praktyk wiąże się z oczywistymi kosztami, jednak korzyści znacznie je przewyższają.
Ciągła integracja
Potrzeby (koszty)
- Twój zespół będzie musiał napisać zautomatyzowane testy dla każdej nowej funkcji, poprawki błędu i każdego ulepszenia.
- Będziesz potrzebować serwera do ciągłej integracji, który umożliwi monitorowanie głównego repozytorium i automatyczne przeprowadzanie testów dla każdego nowego wypchniętego commita.
- Programiści muszą jak najczęściej (co najmniej raz dziennie) scalać swoje zmiany.
Zyski
- Mniej błędów trafiających do produkcji, ponieważ regresje są wychwytywane na wczesnym etapie przez testy zautomatyzowane.
- Kompilowanie wydania jest łatwe, ponieważ wszystkie problemy z integracją zostały rozwiązane na wczesnym etapie.
- Mniej przełączania między kontekstami, ponieważ programiści otrzymują ostrzeżenie, gdy tylko spowodują uszkodzenie kompilacji, i mogą przystąpić do naprawy, zanim przejdą do kolejnego zadania.
- Znaczne obniżenie kosztów testów — Twój serwer ciągłej integracji może w ciągu kilku sekund wykonać setki testów.
- Twój zespół zapewniania jakości poświęca mniej czasu na testy i może skoncentrować się na znacznej poprawie kultury jakości.
Ciągłe dostarczanie
Potrzeby (koszty)
- Potrzebujesz solidnej podstawy w postaci ciągłej integracji, a pakiet Twoich testów musi obejmować dostatecznie dużą część bazy kodu.
- Wdrożenia muszą być zautomatyzowane. Wyzwalanie nadal odbywa się ręcznie, jednak po rozpoczęciu wdrożenia ingerencja ręczna powinna zostać całkowicie wyeliminowana.
- Twój zespół najprawdopodobniej będzie musiał wdrożyć flagi funkcji, aby nieukończone funkcje nie wpływały na klientów w środowisku produkcyjnym.
Zyski
- Mniejsza złożoność oprogramowania do wdrażania. Zespół nie musi już poświęcać wielu dni na przygotowanie wydania.
- Możliwość zwiększenia częstotliwości wydań, a w konsekwencji przyspieszenia pętli informacji zwrotnej od klientów.
- Znacznie mniejsza presja w kwestii decyzji dotyczących niewielkich zmian, sprzyjająca szybszym iteracjom.
Ciągłe wdrażanie
Potrzeby (koszty)
- Twoja kultura testowania musi być na najwyższym poziomie. Jakość zestawu testów będzie decydować o jakości Twoich wydań.
- Proces tworzenia dokumentacji będzie musiał nadążyć za tempem wdrożeń.
- Flagi funkcji stają się nieodłącznym elementem procesu wydawania istotnych zmian, aby możliwe było skoordynowanie prac z innymi działami (wsparcia, marketingu, PR itp.).
Zyski
- Możesz tworzyć oprogramowanie szybciej, ponieważ nie ma potrzeby wstrzymywania prac programistycznych w celu przeprowadzenia wydania. Pipeline'y wdrożeniowe są wyzwalane automatycznie dla każdej zmiany.
- Wydania są mniej ryzykowne i łatwiejsze do naprawy w razie wystąpienia problemu, ponieważ zmiany są wdrażane mniejszymi partiami.
- Klienci widzą ciągły strumień ulepszeń, a jakość zwiększa się codziennie, a nie każdego miesiąca, kwartału lub roku.
Jednym z tradycyjnych kosztów powiązanych z ciągłą integracją jest instalacja i utrzymanie serwera ciągłej integracji. Możesz jednak w istotny sposób obniżyć koszt wdrożenia tych praktyk, korzystając z serwera w chmurze, takiego jak Bitbucket Pipelines, który dodatkowo wprowadza funkcję automatyzacji do każdego repozytorium Bitbucket. Wystarczy dodać plik konfiguracji do katalogu głównego repozytorium, aby móc utworzyć pipeline ciągłego wdrażania, który będzie wykonywany po każdym wypchnięciu nowej zmiany do gałęzi main.
Od ciągłej integracji do ciągłego wdrażania
Jeśli dopiero rozpoczynasz nowy projekt i nie masz jeszcze żadnych użytkowników, wdrożenie każdego commita do produkcji może być łatwe. Możesz nawet zacząć od zautomatyzowania wdrożeń i wydawania swojej wersji alfa do produkcji, nie mając żadnych klientów. Następnie możesz rozwinąć swoją kulturę testowania i zwiększyć pokrycie kodu przy kompilowaniu aplikacji. Gdy wszystko będzie gotowe do wdrożenia użytkowników, będziesz dysponować fantastycznym procesem ciągłego wdrażania, w którym wszystkie nowe zmiany będą testowane przed automatycznym wydaniem do produkcji.
Jeśli jednak masz do czynienia z istniejącą aplikacją, która ma już swoich klientów, postaw raczej na wolniejszy proces i zacznij od ciągłej integracji oraz ciągłego dostarczania. Na początek wprowadź podstawowe testy jednostkowe wykonywane automatycznie — nie musisz koncentrować się jeszcze na przeprowadzaniu złożonych testów kompleksowych. Spróbuj najpierw jak najszybciej zautomatyzować wdrożenia i osiągnąć etap, w którym kod będzie wdrażany do środowisk przejściowych automatycznie. Chodzi o to, że dysponując automatycznymi wdrożeniami, możesz skoncentrować swoje wysiłki na udoskonaleniu testów, zamiast okresowo zatrzymywać prace w celu skoordynowania wydania.
Gdy będzie można rozpocząć codzienne wydawanie oprogramowania, nadejdzie czas, aby przyjrzeć się możliwości ciągłego wdrażania. Pamiętaj o konieczności przygotowania także innych działów organizacji odpowiedzialnych na przykład za dokumentację, wsparcie czy marketing. Funkcje te muszą dostosować się do nowego rytmu wydawania i ważne jest, aby osoby, które je pełnią, nie pominęły istotnych zmian, które mogą wpływać na klientów.
Przeczytaj nasze przewodniki
Read our guides
Możesz znaleźć kilka bardziej szczegółowych przewodników, które pomogą Ci zacząć stosować te praktyki.
Udostępnij ten artykuł
Następny temat
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.
Społeczność DevOps
Przeczytaj blog
