Fundamenty CI/CD w testowaniu oprogramowania
CI/CD, czyli Continuous Integration i Continuous Deployment, to fundament nowoczesnego podejścia do wytwarzania oprogramowania. Continuous Integration oznacza, że zmiany w kodzie trafiają do wspólnego repozytorium często i są od razu automatycznie weryfikowane. Continuous Delivery to etap, w którym kod jest gotowy do wdrożenia, ale wymaga jeszcze ręcznej akceptacji. Continuous Deployment idzie o krok dalej. Wdrożenie następuje automatycznie po przejściu testów.
Wdrożenie CI/CD rozwiązuje wiele typowych problemów w projektach. Zmniejsza liczbę defektów na produkcji, pozwala szybciej znaleźć i naprawić błędy, automatyzuje procesy i eliminuje błędy ludzkie, a także skraca czas reakcji na problemy.
Dla testerów to oznacza natychmiastową informację zwrotną, mniej powtarzalnych i ręcznych zadań, większą stabilność aplikacji, spójne środowiska testowe i więcej czasu na testy, które mają większą wartość.
Jenkins jako serce CI/CD
Jenkins to otwartoźródłowy serwer automatyzacji, który powstał w 2011 roku jako rozwinięcie projektu Hudson. Jego zadaniem jest monitorowanie repozytoriów kodu i automatyczne uruchamianie zadań po wprowadzonych zmianach.
Dlaczego Jenkins?
- pozwala zautomatyzować cały proces CI/CD,
- szybko wykrywa defekty i pozwala na szybką reakcję,
- integruje się z narzędziami do testów automatycznych,
- ma ogromny system wtyczek (ponad 1500),
- umożliwia tworzenie pipeline’ów jako kodu (Pipeline-as-Code),
- wspiera współpracę w duchu DevOps,
- jest skalowalny i elastyczny (model Controller-Agent)
Z perspektywy testera Jenkins to świetne narzędzie do organizowania testów (unit, integracyjnych, e2e, regresji), generowania raportów testowych i szybkiej oceny jakości kodu.
Jak działa Jenkins?
Model Controller-Agent
W Jenkinsie znajdziemy dwa główne typy węzłów:
- Controller (dawniej Master), który zarządza konfiguracją, planuje zadania i zbiera wyniki
- Agent (dawniej Slave), wykonujący zadania, często na osobnych maszynach lub kontenerach.
Dzięki tej architekturze można równolegle uruchamiać wiele zadań na różnych systemach, co znacznie przyspiesza cały proces. Coraz częściej wykorzystuje się do tego kontenery Docker, które zapewniają izolowane, spójne środowiska.
Najważniejsze pojęcia i elementy
- Job – podstawowa jednostka pracy w Jenkinsie, która może obejmować build, test, deploy itp.
- Pipeline – sekwencja kroków (Stages i Steps), która opisuje cały proces dostarczania oprogramowania. Zapisuje się go w pliku Jenkinsfile, co pozwala na wersjonowanie
- Deklaratywny vs. Skryptowy Pipeline – ten pierwszy jest prostszy i bardziej czytelny, drugi daje większą elastyczność.
Buildy mogą być uruchamiane ręcznie (z poziomu interfejsu), harmonogramowo (z użyciem składni cron) albo automatycznie (po zmianach w repozytorium – webhooki).
Przydatne wtyczki dla testera
Jenkins można rozszerzyć o wiele przydatnych wtyczek, do których należą m.in.
- Git (służący do integracji z repozytoriami)
- Maven/Gradle (integracja z narzędziami budowania)
- JUnit (raportowanie wyników testów)
- SonarQube (analiza jakości kodu)
- Mailer, Email Extension (powiadomienia mailowe)
- Slack Notification (komunikaty w komunikatorach)
- Blue Ocean (nowoczesny interfejs pipeline’ów)
- Credentials (bezpieczne przechowywanie danych wrażliwych).
Praktyczna implementacja testów
Integracja z systemami kontroli wersji i budowania
Typowy proces zaczyna się od commitów do repozytorium (np. Git/GitHub), które Jenkins monitoruje. Po wykryciu zmian automatycznie uruchamia zdefiniowane zadania.
Konfiguracja integracji z Git:
- W sekcji „Source Code Management” wybrać „Git”
- Podać URL repozytorium i gałąź
- Skonfigurować uwierzytelnianie (np. klucze SSH).
Po pobraniu kodu można uruchomić budowanie z Mavenem lub Gradle:
stage('Build') {
steps {
echo 'Building...'
sh 'mvn clean compile'
}
}
Uruchamianie testów automatycznych
Testy najczęściej są wydzielone w osobnym etapie:
stage('Test') {
steps {
echo 'Running Tests...'
sh 'mvn test'
junit(testResults: 'target/surefire-reports/*.xml', allowEmptyResults: true)
}
}
Ten etap pozwala:
- uruchomić testy (np. JUnit, TestNG, Selenium)
- publikować wyniki w Jenkinsie
Analiza wyników i raportowanie
Jenkins daje opcję wizualizacji wyników testów (np. za pomocą plugina JUnit), pokazując statusy testów (udane, pominięte, nieudane). Blue Ocean pozwala na przejrzyste śledzenie przebiegu pipeline’a. Raporty można dodatkowo wzbogacić dzięki wtyczkom, np. Allure, które generują szczegółowe podsumowania wraz ze zrzutami ekranu i logami.
Powiadomienia o niepowodzeniach można wysyłać mailowo lub przez Slack:
post {
failure {
mail to: 'team@example.com',
subject: "Failed Pipeline: ${currentBuild.fullDisplayName}",
body: "Something is wrong with ${env.BUILD_URL}"
}
}
Rozwiązywanie problemów i optymalizacja testów
Diagnozowanie niestabilnych testów
Flaky tests, czyli testy o nieprzewidywalnych wynikach, są dużym wyzwaniem. Z pomocą przychodzi stosowanie oznaczenia niestabilnych testów, wdrażanie narzędzi (np. Flaky Test Handler), wykonywanie testów równolegle na różnych agentach, a także grupowanie testów według poziomu i czasu wykonania.
Konfiguracja środowiska
Aby ograniczyć problemy ze środowiskiem, używaj kontenerów Docker do izolacji. Zarządzaj zależnościami za pomocą Maven/Gradle, zapewnij spójne konfiguracje w środowiskach dev i testowych, a przede wszystkim regularnie odświeżaj środowiska.
Monitorowanie i debugowanie
Do analizy Jenkins oferuje:
- szczegółowe logi
- Blue Ocean do wizualnego śledzenia pipeline’ów
- bloki post w pipeline’ach do reagowania na wyniki
- archiwację artefaktów do dalszej analizy
Przy występowaniu problemów warto sprawdzić konfigurację środowiska, ewentualne zależności stanu, kwestie współbieżności, wydajność i dostępne zasoby.
Podsumowanie
Jenkins to potężne narzędzie, elastyczne, przewidywalne i dające szybki feedback. Choć wymaga nauki i konfiguracji, to naprawdę się opłaca. Jeśli jeszcze go nie znasz, zacznij od podstaw i stopniowo rozwijaj pipeline'y. A potem sprawdź, jak bardzo może ułatwić Twoją codzienną pracę testera.
Chcesz poznać Jenkinsa od mniej oczywistej strony? Zajrzyj do poprzedniego artykułu Marka Żukowicza „Wybrane przypadki zastosowania obiektu cause w Jenkinsie”.
Redakcja