CI/CD projektów PHP na Jenkinsie – Ciągła Integracja

W tym artykule poszerzymy plik Anta build.xml o testy jednostkowe przeprowadzane przy pomocy PHPUnit.

Przed uruchomienie testów jednostkowych powinniśmy sprawdzić czy kod PHP nie zawiera błędów składniowych. Kod poniżej implementuje cel, który używa zadania <apply> Apache Ant do wywołania PHP lint checker (-l) dla każdego pliku z kodem źródłowym w katalogach src i tests. Zadanie <apply> działa tak jak <exec> ale może działać na wielu plikach przekazanych jako <fileset>.

 

Do przeprowadzania testów jednostkowych wykorzystamy PHPUnit. Plik konfiguracyjny phpunit.xml.dist wygląda następująco:

Wywołanie phpunit bez argumentów w katalogu projektu (tam gdzie znajduje się plik phpunit.xml.dist) spowoduje uruchomienie PHPUnit dokładnie w taki sposób jak określono w konfiguracji przedstawionej powyżej. Teraz możemy dodać cel do pliku build.xml, który wywoła PHPUnit do przeprowadzenia testów jednostkowych.

 

Przy okazji dodajmy dwa inne cele. Clean to target odpowiedzialny za czyszczenie (usuwanie) artefaktów wyprodukowanych przez poprzedni build. Ten cel uruchamiany jest przez target prepare, ale może być także wywoływany niezależnie.

Cel prepare uruchamia target clean i tworzy katalogi, w których PHPUnit zapisuje logi i raporty.

 

Cała zawartość build.xml:

 

  • full-build – to domyślny target. Uruchamia on wszystkie narzędzia w taki sposób, że logi XML pisane są do domyślnych lokalizacji. Full-build powinien być przeprowadzany w nocy ze względu na długi czas wykonywania.
  • full-build-paralel – robi to samo co full-build z tą różnicą, że statyczne narzędzia analizy uruchamiane są równolegle. Nawet na maszynie z wieloma procesorami pełny build może trwać dużo czasu dlatego ten target powinien być uruchamiany również w nocy.
  • quick-build – target uruchamiany przez “dżoby” wyzwalane w czasie wgrywania nowego kodu do repozytorium.
  • clean – używany do kasowania artefaktów (np. logów i innych rzeczy generowanych w czasie buildu).
  • lint – używany do testowania składni kodu projektu (php -l). To zadanie może być używane przed commitem.
  • phpcs – używany do odnajdywania naruszeń standardu kodowania. Wyświetla wyniki czytelne dla człowieka. To zadanie może być używane przed commitem.
  • phpcpd – używany do odnajdywania zduplikowanego kodu. Wyświetla wyniki czytelne dla człowieka. To zadanie może być używane przed commitem.
  • phpmd – używany do odnajdywania bałaganu w projekcie. Wyświetla wyniki czytelne dla człowieka. To zadanie może być używane przed commitem.
  • phpunit – używany do uruchamiania testów jednostkowych. To zadanie może być używane przed commitem.
  • phpdox – używany do generowania dokumentacji projektu.
  • phploc – używany do obliczania rozmiaru projektu.

Uruchomienie build.xml spowoduje wygenerowanie katalogu o poniższej zawartości:

Artefakty te będą następnie przetwarzane przez Jenkinsa.

Ze strony http://jenkins-php.org pobieramy szablon nowego “job” Jenkinsa. Katalog domowy Jenkinsa ($JENKINS_HOME) to w systemach RedHat-opodobnych /var/lib/jenkins:

Przeładowujemy konfigurację Jenkinsa:

W przypadku błędów przy próbie przeładowania można zrestartować serwer Jenkinsa. Następnie w Jenkinsie:

  1. Klikamy “New Item”.
  2. Wpisujemy nazwę w polu  “Enter an item name”.
  3. W polu “Copy from”  wpisujemy “php-template”.
  4. Klikamy “OK”.
  5. Odznaczamy (odhaczamy) opcję “Disable Build”.
  6. Wpisujemy URL do projektu PHP na GIT w “Source Code Management”.
  7. Konfigurujemy “Build Trigger” na “Poll SCM”.
  8. Klikamy “Save”.

 

Leave a Reply

Your email address will not be published. Required fields are marked *