🥇Przewodnik: jak działa proces Continuous Integration

Dziś przyjrzymy się historii terminu, omówimy trudności związane z wdrażaniem CI oraz przedstawimy kilka popularnych narzędzi, które mogą pomóc w jego wykorzystaniu.

/ Flickr / Altug Karakoc / CC BY / Фото изменено

Termin

Continuous Integration (ciągła integracja) to podejście do tworzenia aplikacji, które zakłada częste kompilowanie projektu i testowanie kodu.

Celem jest uczynienie procesu integracji przewidywalnym i wczesne wykrywanie potencjalnych błędów i usterek, aby mieć więcej czasu na ich naprawę.

Termin Continuous Integration po raz pierwszy pojawił się w 1991 roku. Wprowadził go twórca języka UML Grady Booch . Inżynier przedstawił koncepcję CI jako część własnej praktyki programistycznej — metody Boocha. Oznaczało to stopniowe doprecyzowanie architektury przy projektowaniu systemów obiektowych. Grady nie opisał żadnych wymagań dotyczących ciągłej integracji. Jednak później w swojej książce „Object-Oriented Analysis and Design with Applications” powiedział, że celem metodyki jest przyspieszenie wydania „wewnętrznych wersji”.

Historia

W 1996 roku CI przejęli twórcy metodologii ekstremalnego programowania (XP) — Kent Beck i Ron Jeffries . Częstą integrację uznano za jeden z dwunastu kluczowych zasad ich podejścia. Założyciele XP doprecyzowali wymagania dotyczące metodologii CI i podkreślili potrzebę kompilowania projektu kilka razy dziennie.

Na początku lat 2000-ych metodologię ciągłej integracji zaczął promować jeden z założycieli Agile Alliance Martin Fowler . Jego eksperymenty z CI doprowadziły do powstania pierwszego narzędzia programowego w tej dziedzinie — CruiseControl. Narzędzie stworzył kolega Martina — Matthew Foemmel.

Cykl kompilacji w tym narzędziu jest realizowany w postaci demona, który okresowo sprawdza system kontroli wersji pod kątem zmian w kodzie. Rozwiązanie można pobrać do dziś — jest rozpowszechniany na licencji przypominającej BSD.

Z pojawieniem się oprogramowania do CI coraz więcej firm zaczęło przejmować tę praktykę. Zgodnie z badaniem Forrester [str.5 raport], w 2009 roku 86% z pięćdziesięciu ankietowanych firm technologicznych korzystało lub wdrażało metody CI.

Dziś praktyka Continuous Integration jest stosowana przez organizacje z różnych branż. W 2018 roku duży dostawca chmury przeprowadził ankietę wśród specjalistów IT z firm z sektora usług, edukacji i finansów. Spośród sześciu tysięcy respondentów 58% zadeklarowało, że korzysta w pracy z narzędzi i zasad CI.

Jak to działa

Podstawę ciągłej integracji stanowią dwa narzędzia — system kontroli wersji oraz serwer CI. Ten ostatni może być zarówno fizycznym urządzeniem, jak i wirtualną maszyną w chmurze. Programiści przesyłają nowy kod jeden lub kilka razy dziennie. Serwer CI automatycznie kopiuje go ze wszystkimi zależnościami i wykonuje budowę. Następnie uruchamia testy integracyjne i jednostkowe. Jeśli testy przechodzą pomyślnie, system CI wdraża kod.

Ogólny schemat procesu można przedstawić w następujący sposób:

Metodologia CI stawia przed programistami szereg wymagań:

Niezwłocznie naprawiać problemy. Ta zasada pochodzi z ekstremalnego programowania. Rozwiązywanie błędów to najważniejsze zadanie dla programistów.
Automatyzować procesy. Programiści i menedżerowie powinni nieustannie poszukiwać „wąskich gardeł” w procesie integracji i je eliminować. Na przykład często „wąskim gardłem” integracji okazuje się testowanie.
Przeprowadzać budowy tak często, jak to możliwe. Raz dziennie, aby zsynchronizować pracę zespołu.

Trudności w wdrożeniu

Pierwszym problemem są wysokie koszty operacyjne. Nawet jeśli firma korzysta z otwartych narzędzi CI (o których opowiemy później), i tak będzie musiała ponieść wydatki na utrzymanie infrastruktury. Rozwiązaniem mogą być jednak technologie chmurowe.

Ułatwiają one budowę różnych konfiguracji komputerowych. Co więcej, firmy płacą tylko za używane zasoby, co pozwala zaoszczędzić na infrastrukturze.

Zgodnie z ankietami [str.14 artykułu], ciągła integracja zwiększa obciążenie pracowników firmy (przynajmniej przez pierwszy czas). Muszą oni nauczyć się nowych narzędzi, a koledzy nie zawsze pomagają w szkoleniu. W związku z tym muszą radzić sobie z nowymi frameworkami i usługami „w biegu„.

Trzecia trudność to problemy z automatyzacją. Dotykają one organizacje z dużą ilością kodu legacy, który nie jest pokryty automatycznymi testami. Prowadzi to do sytuacji, w której kod jest po prostu przepisywany przed pełnym wdrożeniem CI.

/ Flickr / theilr / CC BY-SA

Kto korzysta

Jednymi z pierwszych, którzy docenili zalety tej metody, były wielkie firmy IT. Google używa wdrożyło ciągłą integrację w połowie lat 2000. CI zostało wprowadzone w celu rozwiązania problemów z opóźnieniami w działaniu wyszukiwarki. Ciągła integracja pozwoliła na szybkie wykrywanie i eliminowanie usterek. Obecnie CI używają wszystkie jednostki giganta IT.

Ciągła integracja pomaga również małym firmom, a narzędzia CI stosują także instytucje finansowe i zdrowotne. Na przykład w Morningstar usługi ciągłej integracji pomogły przyspieszyć łatanie luk o 70%. Platforma medyczna Philips Healthcare była w stanie dwukrotnie skrócić czas testowania aktualizacji.

Narzędzia

Oto kilka popularnych narzędzi do CI:

Jenkins — jeden z najbardziej popularnych systemów CI. Obsługuje ponad tysiąc wtyczek do integracji z różnymi VCS, platformami chmurowymi i innymi usługami. Jenkins używamy i my w 1cloud: narzędzie jest częścią naszego systemu DevOps. Regularnie sprawdza gałąź Git, przeznaczoną do testów.
Buildbot — framework w języku python do tworzenia własnych procesów ciągłej integracji. Początkowa konfiguracja narzędzia jest dość skomplikowana, jednak rekompensuje to szerokimi możliwościami personalizacji. Wśród zalet frameworka użytkownicy wskazują na niskie zapotrzebowanie na zasoby.
Concourse CI — serwer od Pivotal, który wykorzystuje kontenery Docker. Concourse CI integruje się z dowolnymi narzędziami i systemami kontrolowania wersji. Programiści podkreślają, że system nadaje się do pracy w firmach każdej wielkości.
Gitlab CI — narzędzie wbudowane w system kontroli wersji GitLab. Usługa działa w chmurze i wykorzystuje pliki konfiguracyjne YAML. Podobnie jak Concourse, Gitlab CI stosuje kontenery Docker, które pomagają izolować różne procesy od siebie.
Codeship — chmurowy serwer CI, który współpracuje z GitHub, GitLab i BitBucket. Platforma nie wymaga długiej konfiguracji początkowej — w Codeship dostępne są standardowe wstępnie zainstalowane procesy CI. Dla małych (do 100 kompilacji miesięcznie) i projektów open source Codeship jest dostępny bezpłatnie.