W artykule CI/CD bez tajemnic czyli wprowadzenie dla testerów przybliżę zagadnienia związane z CI/CD z perspektywy TestOps, koncentrując się na praktycznej pracy z pipeline’ami. Jeśli do tej pory CI i CD pojawiały się w Twojej pracy gdzieś „obok”, a nie jako świadomie wykorzystywany element procesu, to dobry moment, aby się z nimi zapoznać i zrozumieć ich rolę w zapewnianiu jakości.
Wstęp
CI/CD coraz częściej staje się integralną częścią pracy testerów i całych zespołów wytwórczych. Pipeline’y przestają być jedynie technicznym dodatkiem, a zaczynają pełnić rolę centralnego miejsca, w którym weryfikowana jest jakość aplikacji.
Proces CI oraz/lub CD sprawia, że testy automatyczne przestają być uruchamiane „od wielkiego dzwonu” lub wyłącznie lokalnie, a zaczynają działać regularnie, w sposób powtarzalny i widoczny dla całego zespołu, na każdym etapie rozwoju oprogramowania.
W wielu zespołach na jednego specjalistę DevOps przypada kilkanaście osób – testerów i deweloperów. Oznacza to, że nie wszystko może i powinno trafiać na barki jednej roli. Świadomość tego, jak działa CI/CD i pipeline’y, pozwala testerom lepiej współpracować z DevOpsami, szybciej reagować na problemy oraz realnie usprawniać pracę całego zespołu.
Zrozumienie CI/CD to dziś nie tylko dodatkowa kompetencja techniczna, ale także krok w stronę bardziej odpowiedzialnego podejścia do jakości i procesu dostarczania oprogramowania.
CI/CD językiem testera
CI/CD to pojęcie, które bardzo często pojawia się w kontekście wytwarzania oprogramowania i bywa rozumiane na różne sposoby. Tak na prawę, nie jest ani jedno narzędzie ani konkretna technologia, lecz pod tym hasłem kryje się zestaw praktyk, które mają na celu usprawnienie pracy zespołu i zapewnienie stałej kontroli nad jakością aplikacji.
CI czyli Continuous Integration – ciągła integracja
Rozważania rozpoczniemy od Continuous Integration (CI). Skrót w tłumaczeniu na język polski oznacza ciągłą integrację zmian w kodzie. W uproszczeniu chodzi o to, aby każda zmiana wprowadzona do repozytorium była jak najszybciej automatycznie sprawdzana.
Co to oznacza dla testera?
Dla testera CI to moment, w którym testy automatyczne zaczynają działać regularnie i systematycznie, a nie tylko wtedy, gdy ktoś o nich pamięta.
W praktyce CI polega na tym, że:
🎯deweloper wykonuje commit lub tworzy merge request,
🎯uruchamia się pipeline,
🎯wykonywane są testy (np. jednostkowe, API, integracyjne),
🎯wynik pipeline’u jest widoczny dla całego zespołu.
Dzięki CI problemy są wykrywane wcześnie, a tester otrzymuje szybki sygnał zwrotny, czy dana zmiana wpłynęła na stabilność aplikacji. To także moment, w którym testy zaczynają pełnić rolę pierwszej linii kontroli jakości.
CD czyli Continuous Delivery / Continuous Deployment – ciągłe dostarczanie
CD to kolejny etap procesu, który dotyczy tego, co dzieje się z aplikacją po przejściu etapu integracji.
W zależności od przyjętego podejścia CD może oznaczać Continuous Delivery lub Continuous Deployment.
- Continuous Delivery skupia się na automatycznym przygotowaniu aplikacji do wydania. Aplikacja po przejściu testów jest gotowa do wdrożenia, ale decyzja o release nadal może być podejmowana ręcznie.
- Continuous Deployment idzie krok dalej – każda zmiana, która przejdzie wszystkie etapy pipeline’u, jest automatycznie wdrażana na kolejne środowiska.
Z perspektywy testera CD jest szczególnie istotne, ponieważ to właśnie na tym etapie testy mogą pełnić rolę bramki jakości. Jeśli testy nie przejdą, proces powinien się zatrzymać, a aplikacja nie powinna trafić dalej. Dzięki temu pipeline staje się miejscem, w którym jakość jest nie tylko deklarowana, ale realnie egzekwowana.
Przykład CI/CD w GitLab pipeline
W GitLabie konfiguracja pipeline’u znajduje się w pliku:
.gitlab-ci.yml
To właśnie tutaj definiujemy etapy (stages), zadania (jobs) oraz warunki ich uruchamiania.
Z perspektywy testera to miejsce, w którym testy stają się częścią procesu dostarczania oprogramowania, a nie tylko lokalnym skryptem odpalanym „na żądanie”.
Załóżmy, że mamy projekt z testami w Pythonie i chcemy, aby:
👍pipeline uruchamiał się przy każdym pushu,
👍instalował zależności,
👍uruchamiał testy,
👍generował raport.
Przykładowy .gitlab-ci.yml
stages:
- test
image: python:3.12
before_script:
- pip install -r requirements.txt
run_tests:
stage: test
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
script:
- pytest --api-url="https://restful-booker.herokuapp.com/booking" --junitxml=report.xml
artifacts:
when: always
reports:
junit: report.xml
paths:
- report.xml
Co się dzieje w tym pliku?
🟢 Definiujemy etap test. Jest tutaj jeden krok odpowiedzialny za uruchomienie testów.
🟢 Używamy obrazu python:3.12 – testy działają w powtarzalnym środowisku Dockera.
🟢 Instalujemy zależności z requirements.txt – przygotowujemy środowisko przed uruchomieniem testów.
🟢 Rules – w tym miejscu ustawiamy reguły, testy uruchomią się: przy commicie na main, przy Merge Requeście.
🟢 Uruchamiamy testy przy użyciu pytest. Testy API wykonują się z podanym adresem endpointu.
🟢 Generujemy raport JUnit (report.xml). Zapisujemy wyniki w standardowym formacie testowym.
🟢 Zapisujemy artifact, raport trafia do pipeline’u i jest widoczny w zakładce Tests.
🟢 when: always – raport zapisze się nawet jeśli testy nie przejdą.
Korzyści automatycznego uruchamiania testów:
✔ wynik jest widoczny dla całego zespołu
✔ raport można pobrać z poziomu pipeline’u
✔ pipeline może zablokować merge, jeśli testy nie przejdą
Jak wygląda pipeline w praktyce?
W interfejsie GitLaba zobaczysz:
✔ graficzny podział na etapy,
✔ status (passed / failed),
✔ logi wykonania,
✔ raporty testów
Dla testera to ogromna wartość – możesz szybko sprawdzić, czy problem wynika z:
✅ błędu w testach,
✅ problemu środowiskowego,
✅ błędnej konfiguracji,
✅ czy faktycznej regresji w aplikacji.
Delegowanie jobów (child / downstream pipelines)
Tak przygotowany pipeline można również wywołać w repozytorium testowanego serwisu (np. API). Mechanizm, który na to pozwala, to delegowanie jobów (child / downstream pipelines).
Dzięki temu testy mogą być utrzymywane w osobnym repozytorium, a mimo to uruchamiane jako część procesu CI/CD właściwej aplikacji.
To rozwiązanie szczególnie dobrze sprawdza się w większych organizacjach, gdzie zespoły chcą:
💡 oddzielić kod aplikacji od kodu testów,
💡 utrzymać niezależność wersjonowania testów,
💡 ponownie wykorzystywać wspólne pipeline’y,
💡centralizować logikę testową.
O delegowaniu jobów i pipeline’ach wielorepozytoryjnych pojawi się osobny wpis.
Podsumowanie
CI/CD to mechanizm, który bezpośrednio wpływa na jakość produktu i tempo pracy zespołu.
Z perspektywy testera:
✅ CI daje szybki feedback o stabilności zmian,
✅ CD pozwala traktować testy jako realną bramkę jakości,
✅ pipeline staje się miejscem, gdzie jakość jest mierzona, a nie deklarowana,
✅ znajomość konfiguracji CI/CD zwiększa samodzielność i wpływ testera na proces.
W świecie, w którym zespoły są coraz bardziej autonomiczne, a jeden specjalista DevOps wspiera kilkanaście osób, świadomość działania pipeline’ów przestaje być dodatkiem – staje się kompetencją wspierającą odpowiedzialność za jakość.
Im lepiej tester rozumie CI/CD, tym mniej „czarnej skrzynki” w procesie dostarczania oprogramowania, a tym więcej realnego wpływu na stabilność i przewidywalność wydań.
Autor
Honorata Łyczak
Testerka automatyzująca, pasjonatka jakości oprogramowania.
Specjalizuje się w testach automatycznych, a szczególną sympatią darzy testy wydajnościowe – entuzjastka Locusta 🐛⚡
Linkedin
