CI/CD: co to jest i jak działa pipeline (przykład 2026)

CI/CD to zestaw praktyk i narzędzi, które po każdej zmianie w repozytorium automatycznie budują aplikację, uruchamiają testy i przygotowują ją do wdrożenia albo wdrażają. CI oznacza ciągłą integrację (continuous integration). CD ma dwa rozwinięcia: ciągłe dostarczanie (continuous delivery) albo ciągłe wdrażanie (continuous deployment). W praktyce wygląda to tak: programista wysyła zmianę na serwer, a po kilku minutach widzi zielony albo czerwony znacznik przy swoim commicie. Poniżej wyjaśniamy, czym różnią się te trzy pojęcia, jak działa pipeline krok po kroku i jak wygląda prawdziwy plik konfiguracyjny w GitHub Actions i GitLab CI/CD. Na koniec piszemy, od czego zacząć wdrożenie CI/CD w małym zespole.

CI/CD co to jest i skąd wziął się ten skrót

Skrót składa się z dwóch części, które opisują dwa etapy drogi kodu: od komputera programisty do wspólnego repozytorium i od repozytorium do użytkowników.

CI, czyli ciągła integracja. Martin Fowler, jeden z najważniejszych popularyzatorów tej praktyki, definiuje ją w artykule “Continuous Integration” jako praktykę, w której każdy członek zespołu łączy swoje zmiany ze wspólnym kodem co najmniej raz dziennie. Każde takie połączenie sprawdza automatyczny build razem z testami. Dzięki temu błąd integracji wychodzi po kilku minutach. Bez CI ten sam błąd potrafi wyjść dopiero po tygodniu, gdy pięć osób scala swoje gałęzie naraz.

CD, czyli ciągłe dostarczanie albo ciągłe wdrażanie. Tu zaczyna się zamieszanie, bo ten sam skrót ma dwa znaczenia. Ciągłe dostarczanie oznacza, że kod po testach jest w każdej chwili gotowy do wypuszczenia na produkcję, ale o samym wdrożeniu decyduje człowiek. Ciągłe wdrażanie idzie krok dalej: każda zmiana, która przejdzie wszystkie testy, trafia na produkcję automatycznie.

GitLab w swojej dokumentacji CI/CD opisuje całość jako ciągły sposób wytwarzania oprogramowania, w którym zmiany w kodzie są stale budowane, testowane, wdrażane i monitorowane. Dla programisty znaczy to tyle, że nie musi pamiętać o odpaleniu testów ani o ręcznym kopiowaniu plików na serwer. Robi to maszyna, za każdym razem tak samo.

Ciągła integracja, dostarczanie i wdrażanie: różnice

Najczęstsze pytanie po “CI/CD co to” brzmi: czym różni się continuous delivery od continuous deployment. Różnica sprowadza się do jednego kroku na samym końcu.

Fowler opisuje tę zależność wprost w notce “ContinuousDelivery”: żeby robić ciągłe wdrażanie, trzeba najpierw robić ciągłe dostarczanie. Firmy często zatrzymują się na dostarczaniu, bo wolą wydawać nowe wersje rzadziej, na przykład raz w tygodniu po akceptacji klienta.

W polskich zespołach zwykle mówi się po prostu “CI” i “deploy”. Gdy w ogłoszeniu albo dokumentacji projektu pojawia się “CD”, warto dopytać, które znaczenie autor ma na myśli. Pierwsze oznacza przycisk “wdróż” w rękach człowieka, drugie brak takiego przycisku. Szerzej o obu połówkach piszemy w tekstach o ciągłej integracji i o continuous delivery.

Frontend Master 2026 · Kodożercy

Pisz kod, nie tylko prompty

Frontend Master 2026 to pakiet sześciu kursów Kodożerców (HTML, CSS, JavaScript, Git) w polskim wideo z 12-miesięcznym dostępem. Fundamenty frontu od pierwszej linijki kodu do deploy.

Wchodzę w to →

Jak działa pipeline CI/CD krok po kroku

Pipeline CI/CD to zautomatyzowany ciąg kroków, przez który przechodzi każda zmiana w kodzie. Uruchamia go zdarzenie w repozytorium, najczęściej wysłanie commita albo otwarcie pull requesta. Typowy pipeline ma cztery etapy:

1. Integracja kodu. Programista wysyła zmianę do wspólnego repozytorium. Serwer CI pobiera dokładnie tę wersję kodu, więc wszyscy pracują na tym samym stanie aplikacji.
2. Budowanie aplikacji. Kod jest kompilowany, zależności instalowane, a pliki przygotowywane do uruchomienia. Jeśli projekt się nie buduje, pipeline zatrzymuje się już tutaj.
3. Testy automatyczne. Uruchamiają się testy jednostkowe, integracyjne, a w większych projektach także testy end-to-end i wydajnościowe. Jeden czerwony test zatrzymuje dalsze kroki.
4. Wdrożenie. Zbudowana wersja trafia na środowisko testowe albo produkcyjne, automatycznie lub po zatwierdzeniu przez człowieka.

Każde narzędzie nazywa te elementy trochę inaczej, ale słownik jest podobny. W dokumentacji GitHub Actions workflow to zautomatyzowany proces opisany w pliku YAML, który uruchamia jedno lub więcej zadań (jobów). Job to zestaw kroków (steps) wykonywanych na tym samym runnerze, czyli serwerze, który wykonuje pracę. W GitLabie zadania grupuje się w etapy (stages). Joby z jednego etapu działają równolegle, a kolejne etapy idą po sobie.

Najważniejsza cecha pipeline’u jest prosta: konfiguracja leży w repozytorium razem z kodem. Każda zmiana w procesie budowania przechodzi więc przez ten sam przegląd kodu co reszta projektu. Widać też w historii, kto i kiedy ją wprowadził.

Przykład pipeline’u CI/CD w GitHub Actions

GitHub Actions to system CI/CD wbudowany w GitHuba. Pliki workflow umieszcza się w katalogu .github/workflows w repozytorium. Poniższy przykład opiera się na wzorze z dokumentacji GitHuba dla Node.js i dodaje do niego osobny krok wdrożenia:

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Use Node.js
        uses: actions/setup-node@v7
        with:
          node-version: '24.x'
      - run: npm ci
      - run: npm run build --if-present
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v7
      - run: ./deploy.sh
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Co robi każda część pliku workflow

Pierwsza część pliku odpowiada za testy:

• on określa, kiedy workflow startuje: przy każdym wysłaniu zmian do gałęzi main i przy każdym pull requeście do niej.
• permissions: contents: read ogranicza uprawnienia tokenu GITHUB_TOKEN do odczytu. Dokumentacja GitHuba zaleca taki domyślny poziom i podnoszenie uprawnień tylko tam, gdzie są potrzebne.

• Job test pobiera kod (actions/checkout), instaluje Node.js, odtwarza zależności z pliku package-lock.json (npm ci), buduje projekt i uruchamia testy. Druga część odpowiada za wdrożenie:

• Job deploy czeka na zielony wynik testów (needs: test) i rusza tylko na gałęzi main. Pull request przejdzie więc same testy, bez wdrożenia.

• environment: production wiąże wdrożenie ze środowiskiem w ustawieniach repozytorium. Można tam wymagać zatwierdzenia przez wskazaną osobę. Na planach Free, Pro i Team ta opcja działa tylko w repozytoriach publicznych. Tak z ciągłego wdrażania robi się ciągłe dostarczanie.
• secrets.DEPLOY_TOKEN to sekret zapisany w ustawieniach repozytorium. Hasła i tokeny nigdy nie trafiają do pliku YAML.
• Tagi @v6 i @v7 zostawiamy dla czytelności. W produkcyjnym workflow akcje warto przypiąć do pełnego skrótu commita, o czym piszemy niżej.

Wdrożenie i darmowe minuty w GitHub Actions

Skrypt deploy.sh to miejsce na własny sposób wdrożenia: wysyłkę plików przez SSH, publikację obrazu Dockera albo wywołanie API hostingu. W publicznych repozytoriach standardowe runnery GitHuba są darmowe. W prywatnych konto GitHub Free ma 2000 minut miesięcznie, co według dokumentacji rozliczeń resetuje się na początku każdego miesiąca.

Ten sam pipeline w GitLab CI/CD

W GitLabie konfiguracja mieszka w pliku .gitlab-ci.yml w głównym katalogu repozytorium. Struktura jest prostsza: definiujemy etapy, a każdy job ma przypisany etap i sekcję script z poleceniami. Przykład oparty na samouczku GitLaba:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  image: node:24
  script:
    - npm ci
    - npm run build --if-present

test-job:
  stage: test
  image: node:24
  script:
    - npm ci
    - npm test

deploy-prod:
  stage: deploy
  script:
    - ./deploy.sh
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Joby wykonują runnery, czyli według GitLaba agenty, które uruchamiają zadania CI/CD. image: node:24 każe uruchomić job w kontenerze Dockera z gotowym Node.js. Warunek rules sprawia, że wdrożenie rusza tylko z gałęzi main. Zmienne takie jak $CI_COMMIT_BRANCH GitLab podstawia sam, a sekrety zapisuje się w ustawieniach projektu jako zmienne CI/CD.

Na GitLab.com darmowe konto dostaje 400 minut obliczeniowych miesięcznie na współdzielonych runnerach, co podaje dokumentacja limitów. Firmy, które trzymają kod na własnych serwerach, często instalują GitLaba u siebie razem z własnymi runnerami. Wtedy limit minut ich nie dotyczy. Pełne porównanie obu systemów znajdziesz w tekście GitHub Actions vs GitLab CI.

Narzędzia CI/CD w 2026 roku

Wybór narzędzia zależy najczęściej od tego, gdzie leży kod. Zespół na GitHubie sięga po GitHub Actions, zespół na GitLabie po wbudowane GitLab CI/CD. Osobne serwery CI wybiera się, gdy firma ma nietypowe wymagania albo wieloletnią infrastrukturę.

Jenkins to otwartoźródłowy serwer automatyzacji. Daje największą swobodę dzięki wtyczkom, ale wymaga utrzymania własnej maszyny. Z narzędzi wymienionych w pierwszej wersji tego tekstu warto jeszcze znać Bamboo od Atlassiana, powiązane z Jirą i Bitbucketem, oraz Spinnakera, który specjalizuje się we wdrożeniach na kilka chmur naraz.

Jak to wygląda w liczbach? Ankieta JetBrains z 2025 roku (State of CI/CD, 805 uczestników) pokazała, że 62% badanych używa GitHub Actions w projektach prywatnych i 41% w firmach. Organizacje wciąż mocno polegają na Jenkinsie i GitLabie, a 32% z nich używa dwóch narzędzi naraz. Ankietę przygotował producent TeamCity, więc traktujemy ją jako orientacyjną. Pokazuje jednak typowy obraz: stare pipeline’y działają latami obok nowych. Jenkinsa z GitHub Actions porównujemy w osobnym tekście Jenkins vs GitHub Actions.

Wdrożenie CI/CD w projekcie: od czego zacząć

Wdrożenie CI/CD najlepiej robić małymi krokami. Pierwszy pipeline może mieć dziesięć linijek i już będzie przydatny.

Krok 1: testy przy każdym pull requeście

Zacznij od jednego workflow, który buduje projekt i uruchamia istniejące testy. Jeśli testów jest mało, nawet sam build i linter, czyli narzędzie sprawdzające jakość kodu, wyłapią sporo błędów, na przykład brakujący import albo literówkę w nazwie zmiennej. Następnie w ustawieniach repozytorium włącz ochronę gałęzi main z wymaganym zielonym statusem. Wtedy czerwonego kodu nie da się scalić. W repozytoriach publicznych GitHub daje tę funkcję za darmo, w prywatnych wymaga płatnego planu.

Krok 2: bezpieczne sekrety i uprawnienia

Pipeline ma dostęp do tokenów, kluczy i serwerów, więc jest łakomym celem dla atakujących. Dokumentacja GitHuba w sekcji o bezpiecznym używaniu Actions zaleca przypinanie zewnętrznych akcji do pełnego skrótu commita (SHA). Tylko tak akcja staje się niezmienną wersją. Zaleca też minimalne uprawnienia tokenu i ochronę sekretów środowiska przez wymagane zatwierdzenie. Jak wygląda atak na sekrety w CI w praktyce, opisaliśmy przy kampanii Mini Shai-Hulud.

Krok 3: automatyczne wdrożenie na środowisko testowe

Gdy testy działają stabilnie, dodaj job, który po scaleniu zmian wdraża aplikację na środowisko testowe. Produkcję zostaw na razie z ręcznym zatwierdzeniem. To jest właśnie ciągłe dostarczanie. Ciągłe wdrażanie włącza się dopiero wtedy, gdy zespół ufa testom na tyle, że nie chce ich już dublować ręcznym klikaniem.

Krok 4: monitorowanie pipeline’u

Pipeline też wymaga opieki. Warto śledzić czas jego trwania, bo build, który rośnie z 5 do 25 minut, zniechęca do częstych commitów. Druga rzecz to testy, które raz przechodzą, a raz nie bez zmiany w kodzie. Takie testy uczą zespół ignorować czerwony status, a wtedy CI przestaje spełniać swoją funkcję. Dobrze ułożona piramida testów, z dużą liczbą szybkich testów jednostkowych na dole, opisana jest w tekście o piramidzie testów.

CI/CD a DevOps

DevOps to sposób pracy, który łączy zespoły programistów (development) i administratorów (operations). Wspólnie odpowiadają za cały cykl życia aplikacji: od napisania kodu po jego działanie na produkcji. CI/CD jest najbardziej namacalną częścią DevOps. To konkretny mechanizm, który sprawia, że kod przechodzi od programisty na serwer szybko, powtarzalnie i z kontrolą jakości po drodze.

Z tej zależności wynikają korzyści, o których pisaliśmy w pierwszej wersji tego artykułu i które pozostają aktualne. Błędy wychodzą na wczesnym etapie, gdy ich naprawa jest najtańsza. Wdrożenie przestaje być stresującym wydarzeniem raz na kwartał i staje się rutyną. Nowe funkcje szybciej trafiają do użytkowników. W naszej ocenie najważniejsza zmiana jest jednak mniej widoczna: zespół zaczyna ufać swojemu kodowi, bo każda zmiana przechodzi ten sam zestaw sprawdzeń.

{ aplikacje webowe }

Masz pomysł na aplikację? Najpierw go zobacz

Zanim zainwestujesz w pełny system, przygotujemy klikalny prototyp, który pokażesz zespołowi albo klientom. Potem budujemy aplikację webową, która rośnie razem z firmą.

Zobacz, jak pracujemy → Software house, który prowadzi ten blog

Najczęstsze pytania

Czy CI/CD to to samo co DevOps?

To dwa różne pojęcia. DevOps to szersza kultura współpracy programistów i administratorów, obejmująca też monitoring, infrastrukturę i odpowiedzialność za produkcję. CI/CD to jeden z mechanizmów, którymi DevOps realizuje się w praktyce. Zespół może mieć pipeline CI/CD i nadal pracować w osobnych silosach.

Czy CI/CD wymaga testów automatycznych?

Ciągła integracja bez testów sprowadza się do sprawdzania, czy kod się buduje, a to łapie tylko najprostsze błędy. Pełna wartość CI/CD pojawia się wtedy, gdy pipeline uruchamia testy jednostkowe i integracyjne. Ciągłe wdrażanie bez dobrych testów jest ryzykowne, bo nic nie zatrzyma błędu w drodze na produkcję.

Ile kosztuje CI/CD w GitHub Actions i GitLabie?

Na start można korzystać z obu za darmo. GitHub Actions jest darmowy dla publicznych repozytoriów na standardowych runnerach i dla własnych runnerów. Prywatne repozytoria na planie GitHub Free mają 2000 minut miesięcznie. GitLab.com daje darmowym kontom 400 minut obliczeniowych miesięcznie. Ponad limit płaci się za minuty albo stawia własne runnery.

Czym jest CI/CD w chmurze?

To pipeline, który działa na serwerach dostawcy, na przykład na runnerach GitHuba albo GitLab.com. Zespół nie utrzymuje wtedy własnych maszyn do budowania. Alternatywą są runnery na własnych serwerach. Wybiera się je, gdy kod nie może opuścić firmowej sieci albo gdy build potrzebuje nietypowego sprzętu.

Podsumowanie

CI/CD to automatyzacja drogi kodu od commita do użytkownika. Ciągła integracja buduje i testuje każdą zmianę, ciągłe dostarczanie przygotowuje wersję do wydania, a ciągłe wdrażanie wypuszcza ją na produkcję bez udziału człowieka. W 2026 roku najprostszy start daje narzędzie wbudowane w platformę z kodem. Dla GitHuba będzie to GitHub Actions z plikiem w .github/workflows, dla GitLaba plik .gitlab-ci.yml. Oba są darmowe w podstawowym zakresie. Pierwszy pipeline powinien robić jedną rzecz: uruchamiać build i testy przy każdym pull requeście. Potem przychodzi czas na ochronę gałęzi, bezpieczne sekrety z przypiętymi wersjami akcji i automatyczne wdrożenie na środowisko testowe. Produkcja z ręcznym zatwierdzeniem to rozsądny punkt docelowy dla większości małych zespołów.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.