Czy jest jakaś wtyczka która umożliwia sprawdzanie endpointów ? Czyli chce w ramach testów uderzać pod adres i sprawdzać czy wszystko jest ok.
0
2
Powinieneś to robić testami automatycznymi, nawet na swojej maszynie developerskiej.
Potem w jenkinsie po prostu uruchom te testy.
0
sprawdzanie tego url jest dopiero na prodzie a wczesniej przechodzi przez test i preprod.
0
co zwracaja endpointy?
Jak jsona czy xmla to można znaleźć opowiedz pod hasłem Java rest testing
Jak htmla to możliwe że jeszcze selenium sie przyda
sprawdzanie tego url jest dopiero na prodzie a wczesniej przechodzi przez test i preprod.
Do dopisz osobny projekt ktory jest testami dla proda
2
Dev007 napisał(a):
sprawdzanie tego url jest dopiero na prodzie a wczesniej przechodzi przez test i preprod.
Nadal możesz to uruchomić na maszynie developerskiej - i właściwie powinieneś. Im szybciej dostaniesz wynik swoich testów tym lepiej.
0
A czy https://wiki.jenkins-ci.org/JENKINS/HTTP-Request-Plugin.html nie mogę użyc ?
1
Dev007 napisał(a):
A czy https://wiki.jenkins-ci.org/JENKINS/HTTP-Request-Plugin.html nie mogę użyc ?
Rozumiem że chcesz na jenkinsie sprawdzić czy aplikacja działa poprawnie? Czy po prostu chcesz sprawdzić czy się zdeployowała/nie padła?
0
zdeployowała/nie padła to już jest. Teraz chce sprawdzić czy po deployu wstawy serwisy i chce udrzyć pod jej adresy który zwraca mi jsona z informacją
2
Dev007 napisał(a):
zdeployowała/nie padła to już jest. Teraz chce sprawdzić czy po deployu wstawy serwisy i chce udrzyć pod jej adresy który zwraca mi jsona z informacją
No to powinieneś to ogarnąć testami automatycznymi w swojej aplikacji, które najpierw powinny być uruchomione na Twojej maszynie developerskiej, a dopiero potem na jenkinsie (zakładając że Ty edytujesz kod źródłowy?)
1
Takie rzeczy testuje się PRZED deployem na prod za pomoca testów automatycznych (np. integracyjnych) a nie po wdrożeniu.
Dziwne macie praktyki w firmie, takie pożarogenne ;)
0
tak to wygląda deploye mamy 1-2 razy w miesiącu w sobotę i od razy przeprowadzane są testy funkcyjne.
1
Dev007 napisał(a):
tak to wygląda deploye mamy 1-2 razy w miesiącu w sobotę i od razy przeprowadzane są testy funkcyjne.
No to to jest bardzo złe podejście.
5
I tak dobrze, że nie raz w roku 30 kwietnia.
0
Ja swojego czasu robiłem tak, że miałem docker-compose. Gdzie była odpalana moja apka, a drugi "node" to były testy pythonowe które uderzały w endpointy i było to odpalane przed każdym mergem. Całkiem fajnie to działało.
0
Problem jest w tym ze jest kilka serwisów nietkóre maja po 10lat i ciężko coś tam wprowadzić nowego dlatego to tak wygląda
1
Zakładając, że masz testy integracyjne czy endpoint działa poprawnie, możesz zacząć uruchamiać testy e2e, zależy co ten endpoint zwraca czy stronę w html czy json, czy wymagany jest jakiś setup/cleanup. Masz do wyboru Selenium, Cypress oraz Robot Framework (pewnie też inne, ale te 3 widziałem na prodzie). Testy e2e zależy co tam masz, uruchamiasz jenkinsem, github workflowem, praktycznie wszystkim się da. Od biedy jak nic nie macie to można zrobić skrypt w bashu uruchamiany zaraz po deployu.
1
mam to rozwiązać na poziomoe Jenkinsa więc testy odpadają
A testy integracyjne to gdzie się uruchamia przed wdrożeniem jak nie na jenkinsie właśnie (lub jego odpowiedniku)?
Przecież nie na komputerze developera który właśnie robi wdrożenie...
Chłopie weź ty poczytaj nieco o testowaniu i CI/CD...
0
Ciężko zrozumieć że nie ma być to w formie testów jednostkowych psianych w kodzie serwisu! Potrzebuje to zrobić w samym jenkinsie albo napisać programik do tego. @RequiredNickname Chociaż wolałbym zrobić to bez pośrednio w jenkinsie jak można ( nie jestem devopsem i nie wiem czy można dlatego też zadaje pytanie)
1
Ja nic nie pisałem o testach jednostkowych...
Serio poczytaj trochę o testowanu, piramidzie testów, CI/CD i ogólnie o tym jak to się powinno robić bo chyba nie masz o tym kompletnie pojęcia...
0
linki do endpointów mogą się zmienić. Serwisy są od siebie zależne( niektóre seerwisy, BD itp wstaja opoznione). Wartości w linku również mogą się zmienić np jak nr użytkownika itp.
Musi to być edytowalne od stronny jenkinsa, mogę ustawić uruchomienie na sam koniec kiedy wszystkie X serwisów już stanie albo uruchomoć to ręcznie.
PS: Poczytam o testach itp ale na dzin dzissiejszy potrzebuje info czy mogę to zrobić jakioś inaczej
1
Może warto dodać, zahaczając o to że ktoś wspomniał CI/CD, czyli jak rozumiem Continuous Integration oraz Continuous Delivery; to są terminy które odnoszą się do metodyki wytwarzania oprogramowania, i jego znaczna część się dzieje na komputerze developera właśnie - jednak jest to bardzo trudna metodyka do wprowadzania, wymaga miesięcy i lat praktyki.
- Continuous Integration - to jest metodyka w której udostępniamy napisany przez nas kod najszybciej jak się da do repozytorium, tak by pozostali członkowie zespołu mogli się z nim jaknajszybciej (a najlepiej ciągle - continuous) integrować, więc nie ma miejsca na feature branche - jak tylko coś napiszemy, musimy to wypchnąć; i jak tylko przyjdzie jakaś zmiana od członka zespołu, to musimy ją zintegrować ze swoimi zmianami. Większość ludzi nie lubi tak pracować, ale to właśnie do tego odnosi się termin "Continuous Integration".
- Continuous Delivery - to również metodyka która mówi o tym, że nie ma odstępu pomiędzy skończeniem feature'a a wdrożeniem feature'a, tzn. w momencie w którym on jest gotowy, to jest też wdrożony. Każdy wypchnięty commit powinien być deployowalny, a funkcjonalność, w momencie w którym pojawi się w kontroli wersji to jest wdrażana i dostarczana do klienta - stąd nazwa "continuous delivery". Znów - większość ludzi nie lubi tak pracować, obawiają się błędów, więc to można bezpiecznie praktykować tylko w otoczeniu bardzo dobrych testów automatycznych, których też większość ludzi nie pisze. Z tego powodu "Continuous delivery" jest trudno praktykować. Jeśli w Twoim projekcie wolisz odczekać kilka godzin albo dni przed wdrożeniem żeby "się upewnić", to nie praktykujesz "Continuous delivery" po prostu.
To o czym mowa jest w wątku to nie żadne CI/CD tylko po prostu uruchomienie testów na zdalnej maszynie (w tym wypadku jenkins).
PS: Zanim zostanę oskarżony o idealizowanie - ja nie mówię tutaj w tym poście, że powinniście/musicie tak robić - prowadźcie swoje projekty jak chcecie. Ja tylko wyjaśniam co te terminy znaczą. Jeśli masz pipeline który odpala testy, ale nie robi deploya to nie masz CD niestety. I jeśli masz feature branche w swoich projektach to nie masz też CI :/ Masz jedynie automatyczną odpalajkę testów.
0
Też zle wątek zatytułowałem moze dlatego takie zamieszanie
0
Chyba coś takiego można użyuć https://e.printstacktrace.blog/how-to-catch-curl-response-in-jenkins-pipeline/ ?
2
U mnie w projekcie są tego typu testy uruchamiane na jenkinsie ale po prostu w ramach uruchomienia osobnego projektu napisanego w javie który wykonuje np. requesty do aplikacji i weryfikuje response.
Kod testów to osobne repo z apką napisaną na bazie springa i tyle.
0
po czesci zgadzam sie z tym co pisze @Riddle jednak mysle ze malo kto wypuszcza nowe feat bez zadnych testowy czy to manualnych/automatycznych czy regression.
U nas wyglada to tak mamy 3 env powiedzmy
- develop
- release/qa
- master
CI/CD jest ciagle na develop i na naszym serverze developerskim, po tym jak jakas funkcjonalnosc zdaje sie do uzytku wrzucamy ja do release/qa gdzie sa testy automatycznie/manualne i regression gdy wszystko przechodzi wpada wszystko na master i potem aktualizujemy u klienta