CI/CD, SDLC i inne pojęcia z zakresu kultury DevOps

Autor:
Zespół Innokrea

Data publikacji: 2024-03-28

Kategorie: Programowanie

Dzisiaj postaramy się przybliżyć Wam kwestię CI/CD i udowodnić Wam, że jej wprowadzenie zwiększa efektywność zespołów, a także częstość i jakość wdrożeń oprogramowania w Waszych firmach. Opowiemy także o tym czym jest blue-green deployment oraz single source of truth Jeśli jesteście ciekawi, to zapraszamy do lektury.

Czym jest CI/CD?

Sam skrót rozwijamy jako continuous integration/continuous delivery/deployment. Pierwszy człon tego skrótu odnosi się do integracji kodu do współdzielonego repozytorium, co jest powszechnie stosowaną praktyką w prawie każdej firmie, która ma cokolwiek wspólnego z oprogramowaniem. W tym celu, deweloperzy najczęściej korzystają z oprogramowania GIT oraz zdalnego repozytorium w formie GitHuba, GitLaba czy Bitbucket hostowanego samemu lub publicznej wersji dostępnej w Internecie. Ciągła integracja odnosi się do częstego commitowania zmian w kodzie przez deweloperów i pushowania ich do zdalnego repozytorium. Dodatkowo w skład CI wchodzą praktyki DevOps, takie jak automatyczne testowanie oraz budowanie (build) projektu w przypadku przejścia przez testy. W przypadku błędu w kodzie wykrytego przez testy deweloper sprawnie otrzymuję informację zwrotną o testach, które się nie powiodły. Dodatkowo dbamy o to, że na głównej gałęzi naszego repozytorium tj. main lub master znajduje się w pełni sprawna, przetestowana wersja oprogramowania. Nie jest możliwe zmergowanie gałęzi jeśli zmiany nie przeszły testów.

Drugi człon tj. CD można rozwijać dwojako – zarówno jako continuous delivery jak i deployment. Ten pierwszy oznacza automatyczne wdrożenie na środowisko testowe, nazywane często stage. Po takim wdrożeniu wymagane jest manualna interwencja odpowiedzialnej osoby, aby wdrożyć zbudowaną wersję do klienta. Jeśli automatyzujemy także ostatni krok tj. wdrożenie do klienta, to wtedy zamiast o continuous delivery mówimy o continuous deployment.

Rysunek 1 – proces CI/CD, źródło: synopsys.com

Jak CI/CD ma się do SDLC?

Niedawno opowiadaliśmy Wam o tym jak wyglądają poszczególne fazy tworzenia oprogramowania w ramach SDLC (software development lifecycle). Jeśli nie znacie tematu, to polecamy zapoznać się z naszym artykułem, który opublikowaliśmy kilka tygodni temu.

Jaki związek ma jednak CI/CD z SDLC? Otóż poszczególne fazy rozwoju oprogramowania używają narzędzi DevOps (w tym CI/CI) do przyspieszenia produkcji kodu, zwiększenia automatyzacji oraz tym samym podwyższenia efektywności całej firmy. Podczas fazy rozwoju oprogramowania powszechnie używamy systemu kontroli wersji (przeważnie GIT), który jak wiadomo odnosi się do fazy CI. Z kolei testowanie oprogramowania podczas SDLC może być sklasyfikowane zarówno pod CI jak i pod CT tj. continuous testing. Wdrożenie w SDLC koresponduje natomiast do wszelkich narzędzi CD tj. continuous deployment jak np. Jenkins, Github Actions czy CircleCI. W ramach SDLC wyróżniamy także, jako jeden z ostatnich etapów, konserwacje i monitorowanie w kulturze devops nazywane continuous monitoring. Można tutaj wymienić takie narzędzia jak Prometheus czy choćby Zabbix pozwalające na agregację informacji z systemu i ich graficzną prezentację dla administratora.

Czym jest SSOT, blue-green deployment i rollback w DevOps?

Aby dokładniej uchwycić kontekst kultury DevOps oraz CI/CD warto poznać kilka koncepcji dzięki którym systemy stają się bardziej niezawodne i efektywne. SSOT (ang. single source of truth) jest konceptem polegającym na posiadaniu spójnych, autorytatywnych informacji w jednym miejscu, źródle danych. Pomaga to na zachowanie określonej wersji danego oprogramowania czy pliku i jest często używanym pojęciem w kontekście DevOps np.:

repozytorium zdalne GIT – jest pojedynczym źródłem kodu i plików konfiguracyjnych dla oprogramowania CI/CD
dokumentacja – powinna istnieć jedna, wersjonowana (często w ramach GIT) dokumentacja danego systemu i powinna być aktualizowana wraz z wprowadzanymi zmianami
infrastruktura – w DevOps często korzystamy z narzędzi IaC takich jak Terraform, aby deklaratywnie określić stan naszych serwerów. Taka konfiguracja, także wersjonowana stanowi wtedy pojedynczy punkt wiedzy o naszej infrastrukturze.

Innym pojęciem, które warto znać rozmawiając o DevOps jest tzw. blue-green deployment, czyli stan zdublowanej infrastruktury np. serwera, którego używamy. Niebieskie (blue) środowisko odnosi się do obecnie działającej wersji aplikacji, a zielone (green) do nowszej, którą będziemy wdrażać. Środowisko zielone nie przyjmuje żadnego ruchu od klientów. W momencie w którym wdrożymy aplikację na środowisko zielone ruch od klientów jest stopniowo lub w całości przekazywany do nowego środowiska.

Rysunek 2 – blue/green deployment, źródło: candost.blog

Jeśli ruch jedynie w części trafia do nowego środowiska, to takie wdrożenie nazywamy canary release. Unikamy wtedy potencjalnego zagrożenia pozbawienia użytkowników usługi w przypadku błędnego działania aplikacji. Monitorowanie ruchu z canary release może także pozwolić na wykrycie potencjalnych błędów aplikacji. Jeśli wdrożenie całkowicie się nie udało (obojętnie czy jest to canary release czy wdrożenie w całości) to w nowoczesnych systemach DevOps istnieje możliwość dokonania rollbacku tzn. cofnięcia do ostatniej działającej wersji. W przypadku środowisk blue-green można to zrobić z pomocą jednego kliknięcia poprzez przekierowanie ruchu z powrotem do niebieskiej infrastruktury.

Istnieją rozbudowane narzędzia jak choćby Gitlab, które pozwalają na posiadanie zintegrowanego środowiska do zarządzania zarówno zdalnym repozytorium GIT jak i wdrożeniem czy rollbackami. Dokładna konfiguracja środowiska jest więc zależna od technologicznych wyborów, kosztów oraz potrzeb danej firmy.

Podsumowanie

Mamy nadzieję, że dzisiejszy artykuł przybliżył Wam pojęcia z zakresu DevOps. Aby dobrze rozumieć na czym polega praca inżyniera chmurowego, SR lub DevOps warto rozumieć podstawowe zagadnienia, aby dobrze orientować się w dużej ilości skrótów i konceptów. Jeśli temat DevOps Was interesuje, polecamy nasze poprzednie artykułu o dobrych praktykach w Dockerze oraz o Terraform, które umieszczamy w źródle. Zapraszamy za tydzień!