Continuous Integration (CI), czyli ciągła integracja, to praktyka polegająca na tym, że każdy programista w zespole często — najlepiej kilka razy dziennie — scala swoje zmiany kodu do wspólnego repozytorium, a po każdym takim scaleniu automatycznie uruchamia się zestaw kroków sprawdzających: budowanie projektu, testy i analiza kodu. Chodzi o to, żeby błąd wyłapać w ciągu kilku minut po jego wprowadzeniu, a nie dwa tygodnie później, gdy nikt już nie pamięta, co tam właściwie zmieniał.
Jak to działa
Mechanizm jest prosty: robisz git push albo otwierasz pull request, a system CI (np. działający na serwerze build) automatycznie pobiera świeży kod, instaluje zależności, kompiluje i odpala testy. Jeśli cokolwiek się wywali, dostajesz czerwony status i wiesz, że nie wolno tego mergować. Jeśli wszystko przechodzi — masz zielono i czyste sumienie.
Kluczowa idea kryje się w słowie continuous. Zamiast trzymać swoją gałąź tygodniami i na końcu walczyć z gigantycznym konfliktem (tzw. merge hell), integrujesz małe porcje często. Im mniejsza zmiana, tym łatwiej namierzyć, co ją zepsuło. CI to też fundament pod Continuous Delivery/Deployment (CD) — bez zaufanego, zielonego builda nie ma sensu myśleć o automatycznym wdrażaniu.
Przykład z praktyki
Najpopularniejsze narzędzie dzisiaj to GitHub Actions. Tworzysz plik .github/workflows/ci.yml, w którym opisujesz pipeline. Minimalny workflow dla projektu w Node.js może wyglądać tak: na każdy push odpala się job, który robi npm ci (czysta, deterministyczna instalacja zależności), a potem npm test. Jeśli testy padną, PR dostaje czerwony znaczek i nie da się go zmergować, dopóki nie naprawisz. Inne popularne systemy to GitLab CI, Jenkins i CircleCI — różnią się składnią, ale idea jest identyczna.
Częste błędy i mity
- „Mamy serwer CI, więc robimy CI” — nie. Jeśli nikt nie patrzy na czerwony build i mergujecie mimo niego, to masz tylko drogi licznik porażek.
- Flaky tests — testy, które raz przechodzą, raz nie, bez zmiany kodu. To zabójca zaufania: zespół zaczyna ignorować czerwony status, a wtedy CI traci sens.
- Wolny pipeline — jeśli testy lecą 40 minut, nikt nie będzie commitować często. Trzymaj CI w granicach kilku minut, np. dzieląc testy na szybkie i wolne.
- Mylenie CI z CD — CI sprawdza, czy kod jest zdrowy; CD zajmuje się jego dostarczaniem na produkcję. To dwa różne etapy.
Pojęcia powiązane: Continuous Delivery, Continuous Deployment, pipeline, pull request, code review, unit testy, DevOps, Git, build automation.