Rafał Krząpa

W dzisiejszym wpisie, zaproponuję trzy pluginy które możemy zainstalować na jenkinsie i ułatwić sobie pracę przy testach automatycznych.
Elementy te wyszukiwałem na https://plugins.jenkins.io/ gdzie znajduje się wiele przydatnych dodatków które mogą pomóc Wam w codziennej pracy.

W ramach nowego projektu chciałem by tworzone testy automatyczne informowały nas szybko o błędach. W ramach pracy używamy slacka, więc wybór padł na wskazaną w tytule wtyczkę.
W pierwszej kolejności tradycyjnie instalujemy plugin i restartujemy jenkinsa.
W ramach slacka konieczne jest zainstalowanie bota i dodawanie go do konkretnego kanału gdzie alerty mają wpadać gdyż to ten bot będzie odpowiedzialny za przekazywanie nam wszelkich wiadomości.
Kolejną kwestią jest integracja Slacka z jenkinsem.
Całość szczegółowej konfiguracji jest dostępna na stronie pluginu (link na samym dole wpisu)

Gdy już masz dokonaną instalację, sprawdzone połączenie pozostaje skonfigurować wtyczkę dla swojego joba.
W dolnej części konfiguracji joba dodaj Post-build Actions i wybierz Slack Notification.
W ramach tych opcji możesz ustawić o czym mamy otrzymywać powiadomienia, wszystkie opcje na screenie poniżej.

Gdy wybierzemy już odpowiednią konfigurację, to slack przesyła nam wiadomości na slacka jak na poniższych screenach.

Podsumowanie:
Dla mnie plugin bardzo przydatny, który może nam pomóc wyłapywać szybko te najbardziej krytyczne problemy (czy też wszystkie - nasza wola). Dzięki niemu możemy szybko otrzymywać informacje czy np. nasza aplikacja odpowiada prawidłowo, czy jakieś najważniejsze z punktu biznesowego kwestie działają niepoprawnie.

Wtyczka która została pobrana ponad 10.000 razy. Dzięki tej wtyczce możemy analizować wyniki naszych poszczególnych test casów w ramach całego joba na przestrzeni czasu.
Po instalacji wtyczki podstawową rzeczą którą powinieneś ustawić to liczba buildów które mamy zapamiętać  + liczbę dni z których trzymamy logi (Discard old build and set Days to keep builds and Max # of builds to keep).

W ogólnej konfiguracji jenkinsa (zdjęcie nr 3) możesz ustawić wszystkie niezbędne dla Ciebie elementy - randomowo ilość buildów, jak graficznie chciałbyś to mieć przedstawione i wiele innych). Ustawienie to powoduje, że nie musisz zmieniać ustawień per job w przypadku gdy masz dziesiątki czy setki jobów.

Zapraszam do zdjęcia nr 2.
Tutaj widzimy trochę węższe ustawienia per job - jeżeli potrzebujesz  inne zakresy i dane dla swojego joba.

Zdjęcie nr 1 pokazuje jeden z raportów jaki widzimy dla joba (pierwszy widok) który pokazuje jakie elementy (dokładne test case się wywala na określonym przez Ciebie okresie buildów). Możemy szybko i wyraźnie odczytać np. który element nam słabo działa.

Podsumowanie:
Dla mnie plugin, prosty, przejrzysty i dość przydatny. W łatwy i przyjemny sposób agreguje błędy które występują podczas odpalania testów i pozwala na szerszą analizę bez monotonnego liczenia czy śledzenia częstotliwości, ilości i wagi błędów.

To coś więcej niż zwykłe powiadomienia e-mailowe które są w standardzie. Pisząc coraz więcej testów i zakładając coraz więcej jobów a także mając dużo codziennych obowiązków niewystarczające dla mnie były powiadomienia e-mailowe typu:
Jenkins build became unstable + nazwa joba, zaś w treści joba tylko link do danego builda.

Ruszając dalej przedmiotowa wtyczka na jenkinsie to Email Extension którą należy zainstalować i zrestartować jenkinsa. Następnie w ramach konfiguracji globalnej lub per job ustawić co chcemy otrzymywać z danego joba.
By uniknąć pisania długich wiadomości w konfiguracji, są zmienne które pomagają nam wyciągać dane.

Wszystkich niezbędnych zmiennych możesz używać + dodawać dowolny komentarz by szybko móc uzyskiwać informacje w swoim e-mailu z danego joba.
Możemy również "oszukiwać system" i wysyłać spakowane logi które na jenkinsie np. przechowujemy tylko przez 14 dni czy 30 dni, zaś na e-mailu będziemy je mieć dowolnie długo.

Podsumowanie:
Plugin który pozwala mi, ale także zespołowi (jeżeli czytają 😉 ) w szybki sposób zobaczyć co nie działa poprawnie w ramach joba, przeczytać które logi i zobaczyć też czy np. na joba posiadającego 50 przypadków testowych nie działa jeden, dwa czy więcej elementów i już w ramach emaila ocenić czy warto błyskawicznie zareagować na takie powiadomienie.