Co to jest CI / CD? Wyjaśnienie ciągłej integracji i ciągłego dostarczania

Ciągła integracja (CI) i ciągłe dostarczanie (CD) ucieleśniają kulturę, zestaw zasad działania i zbiór praktyk, które umożliwiają zespołom tworzącym aplikacje częstsze i bardziej niezawodne wprowadzanie zmian w kodzie. Implementacja jest również znana jako potok CI / CD

CI / CD to jedna z najlepszych praktyk do wdrożenia przez zespoły DevOps. Jest to również najlepsza praktyka metodologii zwinnej, ponieważ umożliwia zespołom programistów skupienie się na spełnianiu wymagań biznesowych, jakości kodu i bezpieczeństwie, ponieważ etapy wdrażania są zautomatyzowane.

Zdefiniowane CI / CD

Ciągła integracja  to filozofia kodowania i zestaw praktyk, które skłaniają zespoły programistów do częstego wdrażania niewielkich zmian i sprawdzania kodu w repozytoriach kontroli wersji. Ponieważ większość nowoczesnych aplikacji wymaga tworzenia kodu na różnych platformach i narzędziach, zespół potrzebuje mechanizmu do integracji i walidacji wprowadzonych zmian.

Celem technicznym CI jest ustanowienie spójnego i zautomatyzowanego sposobu tworzenia, pakowania i testowania aplikacji. Dzięki spójności procesu integracji zespoły są bardziej skłonne do częstszego wprowadzania zmian w kodzie, co prowadzi do lepszej współpracy i jakości oprogramowania.

Ciągła dostawa  rozpoczyna się tam, gdzie kończy się ciągła integracja. CD automatyzuje dostarczanie aplikacji do wybranych środowisk infrastrukturalnych. Większość zespołów pracuje z wieloma środowiskami innymi niż produkcyjne, takimi jak środowiska programistyczne i testowe, a dysk CD zapewnia zautomatyzowany sposób przesyłania do nich zmian w kodzie.

Narzędzia CI / CD pomagają w przechowywaniu parametrów specyficznych dla środowiska, które muszą być spakowane z każdą dostawą. Automatyzacja CI / CD wykonuje następnie wszelkie niezbędne wywołania usług do serwerów WWW, baz danych i innych usług, które mogą wymagać ponownego uruchomienia lub wykonania innych procedur podczas wdrażania aplikacji.

Ciągła integracja i ciągłe dostarczanie wymagają  ciągłego testowania,  ponieważ celem jest dostarczanie użytkownikom wysokiej jakości aplikacji i kodu. Testowanie ciągłe jest często implementowane jako zestaw automatycznych testów regresji, wydajności i innych testów wykonywanych w potoku CI / CD.

Dojrzała praktyka deweloperska CI / CD ma opcję wdrażania ciągłego wdrażania, w którym zmiany aplikacji są przeprowadzane przez potok ciągłej integracji / ciągłego wdrażania, a kompilacje przekazywane są wdrażane bezpośrednio w środowiskach produkcyjnych. Zespoły praktykujące ciągłe dostarczanie decydują się na wdrażanie do produkcji według harmonogramu dziennego lub nawet godzinowego, chociaż ciągłe dostarczanie nie zawsze jest optymalne dla każdej aplikacji biznesowej.  

Powiązane wideo: Jak szybciej dostarczać kod dzięki CI / CD

Jak ciągła integracja poprawia współpracę i jakość

Ciągła integracja to filozofia rozwoju wspierana przez mechanikę procesów i pewną automatyzację. Ćwicząc CI, programiści często wysyłają swój kod do repozytorium kontroli wersji, a większość zespołów ma minimalny standard zatwierdzania kodu przynajmniej codziennie. Uzasadnieniem tego jest fakt, że łatwiej jest zidentyfikować defekty i inne problemy z jakością oprogramowania w przypadku mniejszych różnic w kodzie, a nie większych, które powstały przez długi czas. Ponadto, gdy programiści pracują na krótszych cyklach zatwierdzania, jest mniej prawdopodobne, że wielu programistów będzie edytować ten sam kod i wymagać scalenia podczas zatwierdzania.

Zespoły wdrażające ciągłą integrację często rozpoczynają od konfiguracji kontroli wersji i praktycznych definicji. Mimo że sprawdzanie kodu jest wykonywane często, funkcje i poprawki są wdrażane zarówno w krótkich, jak i dłuższych ramach czasowych. Zespoły programistyczne praktykujące ciągłą integrację używają różnych technik do kontrolowania, jakie funkcje i kod są gotowe do produkcji.

Wiele zespołów używa flag funkcji , mechanizmu konfiguracji do włączania i wyłączania funkcji i kodu w czasie wykonywania. Funkcje, które są wciąż w fazie rozwoju, są opakowane w kodzie flagami funkcji, wdrażane z gałęzią master do produkcji i wyłączane, dopóki nie będą gotowe do użycia. Według niedawnego badania 63 procent zespołów, które używają flag funkcji, zgłasza lepsze testy i wyższą jakość oprogramowania. Narzędzia do oznaczania funkcji, takie jak CloudBees Rollout, Optimizely Rollouts i LaunchDarkly, integrują się z narzędziami CI / CD i umożliwiają konfiguracje na poziomie funkcji.

Inną techniką zarządzania funkcjami jest  rozgałęzianie kontroli wersji . Wybrano strategię rozgałęziania, taką jak Gitflow, w celu zdefiniowania protokołów dotyczących sposobu łączenia nowego kodu w standardowe gałęzie w celu rozwoju, testowania i produkcji. Dodatkowe gałęzie funkcji są tworzone dla tych, które będą wymagały dłuższych cykli rozwoju. Po ukończeniu funkcji programiści mogą następnie scalić zmiany z gałęzi funkcji do głównej gałęzi programistycznej. To podejście działa dobrze, ale może być trudne w zarządzaniu, jeśli jednocześnie opracowuje się wiele funkcji.

Sam proces kompilacji jest następnie zautomatyzowany poprzez pakowanie całego oprogramowania, bazy danych i innych składników. Na przykład, jeśli tworzysz aplikację Java, CI spakowałoby wszystkie statyczne pliki serwera WWW, takie jak HTML, CSS i JavaScript, wraz z aplikacją Java i wszystkimi skryptami bazy danych.

CI nie tylko pakuje całe oprogramowanie i komponenty bazy danych, ale także automatyzacja wykonuje testy jednostkowe i inne testy. To testowanie dostarcza deweloperom informacji zwrotnych, że ich zmiany w kodzie nie przerwały żadnych istniejących testów jednostkowych.

Większość narzędzi CI / CD umożliwia programistom uruchamianie kompilacji na żądanie, wyzwalane przez zatwierdzanie kodu w repozytorium kontroli wersji lub według określonego harmonogramu. Zespoły muszą omówić harmonogram kompilacji, który najlepiej pasuje do wielkości zespołu, liczbę oczekiwanych dziennych zatwierdzeń i inne kwestie dotyczące aplikacji. Najlepsza praktyka zapewniająca szybkie zatwierdzanie i kompilacje, w przeciwnym razie może to utrudniać postęp zespołów próbujących szybko kodować i często zatwierdzać.

Ciągłe testowanie wykracza poza automatyzację testów

Zautomatyzowane struktury testowe pomagają inżynierom ds. Zapewnienia jakości definiować, wykonywać i automatyzować różne typy testów, które mogą pomóc zespołom programistów dowiedzieć się, czy kompilacja oprogramowania przebiega pomyślnie, czy nie. Obejmują testy funkcjonalne, które są opracowywane pod koniec każdego sprintu i zagregowane w teście regresji dla całej aplikacji. Te testy regresji informują następnie zespół, czy zmiana kodu nie powiodła się w jednym lub kilku testach opracowanych we wszystkich obszarach funkcjonalnych aplikacji, w których występuje pokrycie testów.

Najlepszą praktyką jest umożliwienie programistom uruchamiania wszystkich lub części testów regresji w ich środowiskach lokalnych i wymaganie od programistów wykonywania tych testów. Ten krok zapewnia, że ​​programiści zatwierdzają kod do kontroli wersji tylko po przekazaniu zmian w kodzie przez testy regresji.

Testy regresji to dopiero początek. Testy wydajnościowe, testy API, statyczna analiza kodu, testy bezpieczeństwa i inne formy testów również mogą być zautomatyzowane. Najważniejsze jest, aby móc uruchamiać te testy za pomocą wiersza poleceń, elementu webhook lub usługi internetowej i odpowiadać kodami statusu sukcesu lub niepowodzenia.

Gdy testowanie zostanie zautomatyzowane, ciągłe testowanie oznacza, że ​​automatyzacja jest zintegrowana z potokiem CI / CD. Niektóre testy jednostkowe i funkcjonalne można zintegrować z CI, które sygnalizują problemy przed lub w trakcie procesu integracji. Testy wymagające pełnego środowiska dostarczania, takie jak testy wydajności i bezpieczeństwa, są często integrowane z dyskami CD i wykonywane po dostarczeniu kompilacji do środowisk docelowych.

Potok CD automatyzuje zmiany w wielu środowiskach

Ciągłe dostarczanie to automatyzacja, która wypycha aplikacje do środowisk dostarczania. Większość zespołów programistycznych ma zwykle jedno lub więcej środowisk programistycznych i testowych, w których zmiany aplikacji są przygotowywane do testowania i przeglądu. Narzędzie CI / CD, takie jak Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo lub Travis CI, służy do automatyzacji czynności i dostarczania raportów.

Typowy potok CD ma etapy kompilacji, testowania i wdrażania. Bardziej wyrafinowane potoki obejmują wiele z następujących kroków:

  • Pobieranie kodu z kontroli wersji i wykonywanie kompilacji.
  • Wykonywanie wszelkich wymaganych kroków infrastrukturalnych, które są zautomatyzowane jako kod w celu wstrzymania lub zniszczenia infrastruktury chmury.
  • Przenoszenie kodu do docelowego środowiska obliczeniowego.
  • Zarządzanie zmiennymi środowiskowymi i konfigurowanie ich dla środowiska docelowego.
  • Wypychanie składników aplikacji do odpowiednich usług, takich jak serwery WWW, usługi API i usługi baz danych.
  • Wykonywanie wszelkich kroków wymaganych do ponownego uruchomienia usług lub wywołania punktów końcowych usługi, które są potrzebne do wypychania nowego kodu.
  • Wykonywanie testów ciągłych i środowisk wycofywania w przypadku niepowodzenia testów.
  • Udostępnianie danych dziennika i alertów o stanie dostawy.

Na przykład użytkownicy Jenkins definiują swoje potoki w pliku Jenkinsfile, który opisuje różne etapy, takie jak kompilacja, testowanie i wdrażanie. Zmienne środowiskowe, opcje, tajne klucze, certyfikaty i inne parametry są deklarowane w pliku, a następnie etapami do nich odwołuje się. Sekcja postów obsługuje błędy i powiadomienia.  

Bardziej wyrafinowana płyta CD może mieć inne etapy, takie jak wykonywanie synchronizacji danych, archiwizowanie zasobów informacyjnych lub wykonywanie poprawek aplikacji i bibliotek. Narzędzia CI / CD zazwyczaj obsługują rynek wtyczek. Na przykład Jenkins wymienia ponad 1500 wtyczek, które obsługują integrację z platformami innych firm, interfejs użytkownika, administrację, zarządzanie kodem źródłowym i zarządzanie kompilacją.

Po wybraniu narzędzia CI / CD zespoły programistyczne muszą upewnić się, że wszystkie zmienne środowiskowe są skonfigurowane poza aplikacją. Narzędzia CI / CD umożliwiają ustawianie tych zmiennych, maskowanie zmiennych, takich jak hasła i klucze kont, oraz konfigurowanie ich podczas wdrażania w środowisku docelowym.

Narzędzia CD zapewniają również pulpit nawigacyjny i funkcje raportowania. Jeśli kompilacje lub dostawy nie powiodą się, ostrzegają programistów o informacjach o awariach. Integrują się z kontrolą wersji i narzędziami zwinnymi, dzięki czemu można ich używać do sprawdzania, jakie zmiany w kodzie i historie użytkowników złożyły się na kompilację.

Wdrażanie potoków CI / CD z Kubernetes i architekturami bezserwerowymi 

Wiele zespołów obsługujących potoki CI / CD w środowiskach chmurowych również korzysta z kontenerów, takich jak Docker, i systemów orkiestracji, takich jak Kubernetes. Kontenery umożliwiają pakowanie i wysyłkę w standardowy, przenośny sposób. Kontenery ułatwiają skalowanie w górę lub niszczenie środowisk, które mają zmienne obciążenia.

Istnieje wiele podejść do jednoczesnego używania kontenerów, infrastruktury jako kodu i potoków CI / CD. Możesz zapoznać się z opcjami, korzystając z samouczków, takich jak Kubernetes z Jenkins lub Kubernetes z Azure DevOps.

Architektury obliczeń bezserwerowych stanowią kolejną drogę do wdrażania i skalowania aplikacji. W środowisku bezserwerowym infrastruktura jest w pełni zarządzana przez dostawcę usług w chmurze, a aplikacja zużywa zasoby w razie potrzeby na podstawie jej konfiguracji. Na przykład w AWS aplikacje bezserwerowe działają jako funkcje Lambda, a wdrożenia można zintegrować z potokiem CI / CD Jenkins za pomocą wtyczki. 

CI / CD umożliwia częstsze wdrażanie kodu

Podsumowując, pakiety CI i testy kompilacji oprogramowania i ostrzegają programistów, jeśli wprowadzone przez nich zmiany nie powiodły się w testach jednostkowych. CD to automatyzacja, która dostarcza zmiany w infrastrukturze i wykonuje dodatkowe testy. 

Potoki CI / CD są przeznaczone dla firm, które chcą często ulepszać aplikacje i wymagają niezawodnego procesu dostarczania. Dodatkowym wysiłkiem związanym z standaryzacją kompilacji, opracowywaniem testów i automatyzacją wdrożeń jest proces produkcyjny służący do wdrażania zmian w kodzie. Po wdrożeniu umożliwia zespołom skupienie się na procesie ulepszania aplikacji, a mniej na szczegółach systemowych związanych z dostarczaniem ich do środowisk obliczeniowych.

CI / CD to najlepsza praktyka DevOps, ponieważ rozwiązuje problem braku zgodności między programistami, którzy chcą często wprowadzać zmiany, z operacjami wymagającymi stabilnych aplikacji. Dzięki automatyzacji programiści mogą częściej wprowadzać zmiany. Zespoły operacyjne widzą większą stabilność, ponieważ środowiska mają standardowe konfiguracje, ciągłe testowanie w procesie dostarczania, zmienne środowiskowe są oddzielone od aplikacji, a procedury wycofywania są zautomatyzowane.

Wpływ wdrożenia potoków CI / CD można mierzyć jako kluczowy wskaźnik wydajności (KPI) DevOps. Kluczowe wskaźniki wydajności, takie jak częstotliwość wdrażania, czas realizacji zmian i średni czas do odzyskania (MTTR) po incydencie, są często poprawiane, gdy wdrażane jest CI / CD z ciągłym testowaniem. Jednak CI / CD to tylko jeden proces, który może napędzać te ulepszenia, a istnieją inne warunki wstępne dotyczące poprawy częstotliwości wdrażania.

Rozpoczęcie pracy z CI / CD wymaga od zespołów programistycznych i operacyjnych współpracy w zakresie technologii, praktyk i priorytetów. Zespoły muszą wypracować konsensus co do właściwych podejść do ich biznesu i technologii, aby po wdrożeniu CI / CD zespół był na pokładzie i konsekwentnie przestrzegał praktyk.