# CI/CD po ludzku: co to jest i co daje Twojej firmie

Adres: https://sebastianmusial.pl/blog/ci-cd-po-ludzku/ · Opublikowano: 2026-11-12

CI/CD brzmi jak żargon, ale chodzi o prostą rzecz: zmiany w Twojej stronie albo aplikacji sprawdza i publikuje automat, a nie ręce programisty. Wyjaśniam, jak to działa, co z tego masz, ile to wymaga pracy i kiedy jest przesadą.

**W skrócie**

- CI/CD to automat, który po każdej zmianie w kodzie sam buduje i testuje stronę albo aplikację (CI), a potem publikuje sprawdzoną wersję na środowisku testowym i na produkcji, sam albo po jednym kliknięciu (CD).
- Dla Ciebie to mniej błędów typu „u mnie działa”, mniejsze i częstsze wdrożenia, zapis tego, co i kiedy poszło na żywo, łatwiejsze cofnięcie zmiany i projekt niezależny od laptopa jednej osoby.
- Kosztuje głównie czas na ustawienie i czasem opłatę za usługę, a przy prostej stronie zmienianej dwa razy w roku zwykle jest przesadą.

**Definicja.** CI/CD to zestaw automatycznych kroków, przez które przechodzi każda zmiana w kodzie strony albo aplikacji. CI, czyli ciągła integracja, oznacza, że każda zmiana jest od razu budowana i testowana. CD, czyli ciągłe dostarczanie albo wdrażanie, oznacza, że sprawdzona zmiana trafia na wersję testową i do klientów automatycznie albo jednym kliknięciem.

## Co to jest CI/CD?

To automat, który po każdej zmianie w kodzie Twojej strony albo aplikacji sam ją sprawdza i publikuje. Zamiast programisty, który ręcznie kopiuje pliki na serwer, robi to zestaw ustalonych kroków, za każdym razem tak samo.

Skrót ma dwie części. **CI** (*continuous integration*, ciągła integracja) oznacza, że każda zmiana zapisana w repozytorium, czyli wspólnym folderze projektu z historią zmian, jest od razu automatycznie budowana i testowana. Budowanie to złożenie kodu w wersję, która działa w przeglądarce albo na telefonie. **CD** oznacza, że zmiana, która przeszła testy, sama idzie dalej: na wersję testową, a potem na produkcję, czyli do Twoich klientów.

Cały ciąg tych kroków to *pipeline*, po polsku czasem „potok”. Najprościej wyobrazić go sobie jako taśmę w fabryce, na której każda zmiana przechodzi przez te same stanowiska kontroli.

## Czym różni się ciągłe dostarczanie od ciągłego wdrażania?

Tym, kto naciska ostatni przycisk. Przy ciągłym dostarczaniu (*continuous delivery*) każda sprawdzona zmiana jest gotowa do publikacji, ale na produkcję idzie dopiero po zatwierdzeniu przez człowieka. Przy ciągłym wdrażaniu (*continuous deployment*) trafia tam sama.

Tak tę różnicę opisuje [Amazon Web Services](https://aws.amazon.com/devops/continuous-delivery/): obie praktyki dzieli tylko ręczna akceptacja przed produkcją. Dla właściciela firmy zwykle wygodniejsze jest dostarczanie: zmianę oglądasz, a o dniu publikacji decydujesz Ty, np. żeby nowy cennik nie wszedł przed wysyłką newslettera. Ciągłe wdrażanie pasuje do zespołów, które publikują wiele drobnych zmian i mają je dobrze pokryte testami automatycznymi.

## Jak wygląda droga zmiany w pipeline?

Zwykle ma pięć kroków, a człowiek wykonuje z nich dwa: pisze zmianę i ją akceptuje. Resztę robi automat.

1. **Zmiana.** Programista zapisuje ją w repozytorium. Jak działa historia zmian, piszę w artykule [Kontrola wersji po ludzku](https://sebastianmusial.pl/blog/kontrola-wersji-git/).
2. **Automatyczne testy.** Serwer usługi CI pobiera kod, buduje go i uruchamia testy. Jeśli coś nie przechodzi, zmiana nie idzie dalej, a programista dostaje powiadomienie. Rodzaje testów opisuję w artykule [Testy oprogramowania](https://sebastianmusial.pl/blog/testy-oprogramowania/).
3. **Staging.** Zmiana, która przeszła testy, sama trafia na wersję testową pod osobnym adresem. Po co ona jest, wyjaśniam w artykule [Środowisko testowe przed publikacją](https://sebastianmusial.pl/blog/srodowisko-testowe-staging/).
4. **Akceptacja.** Ty albo ktoś z Twojej firmy ogląda zmianę na stagingu i ją zatwierdza. Usługi CI/CD potrafią wymagać takiego zatwierdzenia, np. w [GitHub Actions](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#required-reviewers) wskazuje się osoby, które muszą zgodzić się na publikację.
5. **Produkcja.** Po akceptacji automat publikuje tę samą wersję kodu, którą oglądałeś na stagingu, i zapisuje, kiedy to zrobił.

*Ilustracja: Automat buduje, testuje i publikuje każdą zmianę tak samo. Człowiek pisze zmianę i ją akceptuje, a zmiana, która nie przeszła testów, wraca do programisty i nie idzie dalej.*

## Co CI/CD daje mi jako klientowi?

Przewidywalność: każda zmiana przechodzi tę samą drogę, więc mniej zależy od pamięci i dobrego dnia jednej osoby. W praktyce oznacza to kilka konkretnych rzeczy.

- **Mniej błędów typu „u mnie działa”:** kod jest budowany i testowany na czystym serwerze usługi, a nie na laptopie programisty, na którym mogą być pliki i ustawienia, których nie ma nigdzie indziej.
- **Mniejsze i częstsze wdrożenia:** wdrożenie, czyli publikacja zmiany, przestaje być wydarzeniem, więc zmiany wychodzą małymi porcjami. Jak zauważa [dokumentacja GitHuba](https://docs.github.com/en/actions/get-started/continuous-integration), częstsze zapisywanie zmian pozwala szybciej wykryć błędy i zmniejsza ilość kodu, w której trzeba ich szukać.
- **Zapis tego, co i kiedy poszło na żywo:** usługi CI/CD prowadzą historię wdrożeń razem ze zmianami, które się na nie złożyły; tak działa np. [historia wdrożeń w GitHubie](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/view-deployment-history). Gdy klient zgłasza błąd od wtorku, łatwo sprawdzić, co weszło we wtorek.
- **Łatwiejsze cofnięcie:** każda wersja jest zapisana, więc powrót do poprzedniej to ponowne wdrożenie znanej, sprawdzonej wersji. [GitLab](https://docs.gitlab.com/ci/environments/deployments/) ma do tego osobny przycisk przy wcześniejszych wdrożeniach. Cofnięcie kodu nie cofa jednak danych, np. zamówień złożonych w międzyczasie, dlatego zmiany w bazie danych planuje się ostrożniej.
- **Mniejsza zależność od jednej osoby:** sposób publikacji jest zapisany w pliku w repozytorium, a hasła do serwera leżą w ustawieniach usługi, nie na czyimś laptopie. Gdy zmienisz wykonawcę albo programista zachoruje, ktoś inny wdroży zmianę tak samo.

## Ile kosztuje CI/CD?

Głównie czas programisty na ustawienie, a czasem opłatę za usługę. Dokładny koszt zależy od projektu, więc ustala się go przy wycenie, a nie z góry.

- **Ustawienie na starcie:** trzeba opisać kroki pipeline, podłączyć serwer i staging, ustawić dostępy i hasła. W nowym projekcie to część pracy na początku; dorobienie CI/CD do starego projektu bywa większym zadaniem, zwłaszcza gdy nie ma w nim testów.
- **Testy:** automat uruchamia tylko te testy, które ktoś napisał. Bez nich CI/CD nadal publikuje zmiany, ale niewiele sprawdza.
- **Usługa:** pipeline działa na serwerach usługi, np. [GitHub Actions](https://docs.github.com/en/actions/get-started/continuous-deployment) albo [GitLab CI/CD](https://docs.gitlab.com/ci/). W GitHub Actions plan konta obejmuje pewne użycie w cenie, a [po jego wyczerpaniu płaci się](https://docs.github.com/en/billing/concepts/product-billing/github-actions) za dodatkowe.
- **Utrzymanie:** narzędzia się zmieniają, więc pipeline co jakiś czas wymaga aktualizacji, tak jak sama strona.

Warto to zestawić z ręcznym wdrażaniem: każdą publikację ktoś musi zrobić, sprawdzić i za każdym razem pamiętać o wszystkich krokach.

## Kiedy CI/CD to przesada?

Przy prostej stronie, która zmienia się dwa razy w roku. Pełny pipeline z testami, stagingiem i akceptacją się nie zwróci, jeśli nie ma czego często publikować ani testować.

Taką stronę programista może opublikować ręcznie, a zmianę pokazać Ci wcześniej w podglądzie. Przy stronie statycznej, bez bazy danych i wtyczek (różnice opisuję w artykule [Strona statyczna czy WordPress?](https://sebastianmusial.pl/blog/strona-statyczna-czy-wordpress/)), często wystarcza prosta automatyczna publikacja z repozytorium, bez rozbudowanych etapów.

CI/CD zaczyna się opłacać, gdy zmiany wychodzą regularnie, nad projektem pracuje więcej niż jedna osoba, a aplikacja ma konta użytkowników, płatności albo dane, przy których każdy błąd kosztuje.

## O co zapytać wykonawcę

- Czy każda zmiana będzie automatycznie budowana i testowana?
- Kto zatwierdza publikację na produkcji i jak to wygląda?
- Gdzie zobaczę, co i kiedy trafiło na żywo?
- Jak cofniesz wdrożenie, jeśli coś pójdzie nie tak?
- Na czyim koncie działa pipeline i gdzie są hasła do serwera?

## Najczęstsze pytania

**Czy przy CI/CD każda zmiana od razu trafia do klientów?**
Nie musi. Przy ciągłym dostarczaniu zmiana czeka na Twoją akceptację i dopiero potem idzie na produkcję. Sama trafia tam tylko przy ciągłym wdrażaniu, jeśli tak to ustalicie.

**Czy CI/CD zastępuje testy i środowisko testowe?**
Nie. CI/CD uruchamia testy i przenosi zmiany między etapami, ale testy ktoś musi napisać, a staging musi istnieć. Automat zastępuje ręczne kopiowanie plików i pamiętanie o krokach, nie zastępuje sprawdzenia przez człowieka.

**Czy CI/CD działa przy stronie na WordPressie?**
Dla kodu tak, np. własnego motywu i wtyczek pisanych na zamówienie. Teksty i zdjęcia dodane w panelu WordPressa leżą jednak w bazie danych, a nie w repozytorium, więc pipeline ich nie publikuje ani nie cofa.

---

Zaktualizowano: 2026-11-12. Sebastian Musiał, kontakt@sebastianmusial.pl, rozmowa 30 min: https://calendly.com/sebastianmusial/30min. Wycena po rozmowie, bez cennika na stronie.
Spis wszystkich stron: https://sebastianmusial.pl/llms.txt · Cała treść w jednym pliku: https://sebastianmusial.pl/llms-full.txt