Pipeline to zautomatyzowany ciąg kroków, który prowadzi Twój kod od momentu wrzucenia zmiany do repozytorium aż po działającą aplikację u użytkownika. Zamiast ręcznie budować projekt, uruchamiać testy, pakować artefakt i wgrywać go na serwer, definiujesz te etapy raz w pliku konfiguracyjnym, a maszyna powtarza je tak samo za każdym razem. To rdzeń podejścia CI/CD (Continuous Integration / Continuous Delivery), czyli ciągłej integracji i dostarczania.
Jak to działa
Pipeline składa się z etapów (stages), a te z zadań (jobs). Typowy układ to: build (kompilacja, instalacja zależności), test (testy jednostkowe, integracyjne, lintery), package (zbudowanie obrazu Dockera albo paczki) i deploy (wdrożenie na środowisko). Najczęściej wyzwala go jakieś zdarzenie: push na branch, otwarcie pull requesta albo merge do main.
Kluczowa zasada: jeśli któryś etap się wywróci, pipeline zatrzymuje się i dalsze kroki nie ruszają. Dzięki temu zepsuty kod nie dojedzie na produkcję, a Ty dostajesz informację zwrotną w kilka minut, a nie po tygodniu od klienta. To właśnie odróżnia pipeline od „ręcznego deploya w piątek o 17:00”, który skończył się dla kogoś weekendem przy laptopie.
Przykład z praktyki
W GitHub Actions pipeline opisujesz w pliku YAML w katalogu .github/workflows/. Definiujesz w nim joby, a w każdym listę kroków, na przykład run: npm ci, potem run: npm test, a na końcu budowę i publikację obrazu. Podobnie działa GitLab CI (plik .gitlab-ci.yml) czy Jenkins (Jenkinsfile). Narzędzie odpala każdy krok w czystym środowisku — zwykle w kontenerze — więc „u mnie działa” przestaje być argumentem.
Częste błędy i mity
- Mit: pipeline = deployment. Deployment to tylko jeden z etapów. Sam pipeline może budować i testować, nigdy nie tykając produkcji.
- Brak cache’owania zależności — bez tego każdy run pobiera wszystko od zera i pipeline trwa wieczność. Nikt nie czeka 20 minut na feedback.
- Sekrety w kodzie YAML — hasła i tokeny trzymaj w mechanizmie secrets danego narzędzia, nigdy na sztywno w pliku.
- Testy „na potem” — pipeline bez testów to tylko automatyczne wysyłanie bugów na produkcję, za to szybciej.
Pojęcia powiązane
CI/CD, GitHub Actions, GitLab CI, Jenkins, DevOps, Docker, artefakt, deployment, runner, YAML.