Budowa infrastruktury CI/CD dla istniejącej aplikacji z Jenkinsem, Dockerem - pomoc w wystartowaniu

Cześć. Zajmuję się głównie testami automatycznymi, ale w celach szkoleniowch chciałbym pogłębić swoją praktyczną wiedzę w szerszym obszarze, bardziej devopsowym.

Idealnie byłoby znaleźć istniejącą aplikację na githubie, z otwartym kodem źródłowym, dla której mógłbym sobie skonfigurować usługi chmurowe, CI/CD, z wykorzystaniem Jenkinsa, Dockera. Spiąć to z sonarQube, testami automatycznymi.

Ogólnie cel jest taki żebym przetrenował sobie wejście do projektu, w którym nie ma testów automatycznych, CI/CD i postawienie takiej infrastruktury od zera.

Przerabiam kurs dla devops na udemy, ale wkurza mnie fakt, że poszczególne sekcje są wykonywane w oddzieleniu względem siebie, czyli oddzielnie pokazany jenkins, docker, ansible, a całość nie skupia się na tym, aby stworzyć z tego kompleksową infrastrukturę. Chciałbym czerpać wiedzę jednocześnie wdrażając te elementy do tego swojego autorskiego projektu, bo ucząc się kaskadowo jednego po drugim, uczę się technologii nr 7, a z nr 1 już nic nie pamiętam.

Pytanie brzmi:

1. Jaką istniejącą aplikację z otwartym kodem źródłowym polecilibyście do tego?
2. Załóżmy, że mam kod źródłowy aplikacji, oddzielnie testy automatyczne frontu e2e, testy api, testy wydajnościowe. Jaka powinna być kolejność działań, aby osiągnąć stan, gdy mam pipeline składający się z builda, odpalenia testów jednostkowych, e2e, wydajnościowych i mógłbym to sobie wszystko podglądać w Jenkinsie? I aby była możliwość odpalenia tego pp zarówno z palca i aby odpalał się także automatycznie po każdym pushu do głównego brancha?

Z góry dziękuję za pomoc. Ewentualnie inne wskazówki również chętnie przyjmę

ps. proszę za mocno nie hejtować

ps.2. Zastanawiam się, czy lepszym miejscem na ten wątek nie będzie edukacja. jakby co to proszę o przesunięcie.

Ale o jaki rodzaj apki ci chodzi? Bo wiesz dla mnie "apka" to aplikacja na Androida. Dla innego apka to backend do tej aplikacji na Androida. A dla innego apka to jakiś serwis webowy otwierany w przeglądarce (dla mnie to by była "stronka" ew. "portal"). A dla innego jeszcze coś innego.

Może tu coś sobie wylosujesz? https://github.com/awesome-selfhosted/awesome-selfhosted

marian pazdzioch napisał(a):

Ale o jaki rodzaj apki ci chodzi? Bo wiesz dla mnie "apka" to aplikacja na Androida. Dla innego apka to backend do tej aplikacji na Androida. A dla innego apka to jakiś serwis webowy otwierany w przeglądarce (dla mnie to by była "stronka" ew. "portal"). A dla innego jeszcze coś innego.

Może tu coś sobie wylosujesz? https://github.com/awesome-selfhosted/awesome-selfhosted

dzięki :)

No to ładnie wątek napisałem bez kluczowej informacji

Apka webowa, najlepiej typu CRUD

Apka webowa, najlepiej typu CRUD

Spring Pet Clinic

Aczkolwiek nie wiem jak tam z testami - ale to sobie napiszesz na luzie, jakieś proste klikacze e2e w Selenide na przykład bardzo łatwo się pisze. Wydajnościowe to nawet shellem z ab ogarniesz na przykład, pytanie jak głęboko chcesz wchodzić.

nie wiem czy to przypadek ale jak zapytałem czata

can you recomend github repo for give me exaplme Apka webowa, najlepiej typu CRUD, java

to też mi pet clinic dał

Certainly! Here's a recommendation for a GitHub repository that provides a good example of a Java web application implementing CRUD operations:
Repository: spring-projects/spring-petclinic
This repository contains the source code for the Spring PetClinic application, which is a sample application demonstrating the use of the Spring Framework in a web-based CRUD application scenario. It showcases various Spring features including Spring MVC, Spring Data JPA for data access, and Thymeleaf for server-side rendering.
The Spring PetClinic application manages information about veterinarians, pets, owners, and visits to a veterinary clinic. It provides functionality for creating, reading, updating, and deleting records for these entities.

Jak się dopiero uczysz, to może zmień na gitlab?

Cały post który opisałeś to jest ogromny przerost formy nad treścią.

Pamiętaj że wszystkie narzędzia o których mówisz to jedynie środek do celu. Samo korzystanie z tych narzędzi prawie nic nie daje.

Np to:

KarnyJerzy napisał(a):

Pytanie brzmi:

1. Jaką istniejącą aplikację z otwartym kodem źródłowym polecilibyście do tego?
2. Załóżmy, że mam kod źródłowy aplikacji, oddzielnie testy automatyczne frontu e2e, testy api, testy wydajnościowe. Jaka powinna być kolejność działań, aby osiągnąć stan, gdy mam pipeline składający się z builda, odpalenia testów jednostkowych, e2e, wydajnościowych i mógłbym to sobie wszystko podglądać w Jenkinsie? I aby była możliwość odpalenia tego pp zarówno z palca i aby odpalał się także automatycznie po każdym pushu do głównego brancha?

klasyczny przerost narzędzi nad funkcję.

To od czego na prawdę należałoby zacząć, to jest: Jak dostarczać użytkownikom aplikację spełniającą ich wymagania?. Jak szybko wprowadzać zmiany, jak dbać o to żeby zmiany były dobre (czyli nie wprowadzały bugów a jednocześnie dostarczały wartościowe cechy oprogramowania). Jak dbać o to żeby użytkownicy aplikacji byli z niej zadowoleni. To powinien być Twój główny cel.

Dodawanie narzędzi o których piszesz tylko po to żeby były jest bardzo słabe. One powinny być jedynie facylitatorem osiągnięcia dobrej aplikacji.

Taki tekst i mógłbym to sobie wszystko podglądać w Jenkinsie - to jest wręcz kwintencja tego że narzędzie stało się istotniejsze niż funkcja którą pełni

KarnyJerzy napisał(a):

Pytanie brzmi:

1. Jaką istniejącą aplikację z otwartym kodem źródłowym polecilibyście do tego?
2. Załóżmy, że mam kod źródłowy aplikacji, oddzielnie testy automatyczne frontu e2e, testy api, testy wydajnościowe. Jaka powinna być kolejność działań, aby osiągnąć stan, gdy mam pipeline składający się z builda, odpalenia testów jednostkowych, e2e, wydajnościowych i mógłbym to sobie wszystko podglądać w Jenkinsie? I aby była możliwość odpalenia tego pp zarówno z palca i aby odpalał się także automatycznie po każdym pushu do głównego brancha?

Nie zaczynaj od tej strony.

Jeśli chcesz iść w tą stronę, to zacznij tak:

1. Znajdź projekt open-source losowy
2. Zagadaj do autora i zapytaj jakie ma problemy, z czym się boryka: bugi? wolny release? trudność zmiany? mało feature'ów? niska wartość feature'ów?
3. Postaraj się zrozumieć skąd ten problem się bierze, i wtedy dopiero postaraj się go jakoś rozwiązać, być może jednym z narzędzi które wymieniłeś ale nie koniecznie (bo mogą się okazać nieadekwatne).

Tak należałoby do tego podejść. A nie wciskać jenkinsa wszędzie gdzie się da tylko po to żeby były. To nie jest tak że każdy projekt musi odpalać build w chmurze żeby "był dobry". Jest wiele projektów które tego nie potrzebują i nic się nie zyska dodając to. Nie każdy projekt potrzebuje dockera, automatyzacji, pipeline'ów, etc.

Faktyczna wartość wynika ze znalezienia problemów i umiejętnego i inteligentnego naprawienia ich, a nie z bezmyślnego wrzucania narzędzi w projekt.

KarnyJerzy napisał(a):

Pytanie brzmi:

1. Jaką istniejącą aplikację z otwartym kodem źródłowym polecilibyście do tego?
2. Załóżmy, że mam kod źródłowy aplikacji, oddzielnie testy automatyczne frontu e2e, testy api, testy wydajnościowe. Jaka powinna być kolejność działań, aby osiągnąć stan, gdy mam pipeline składający się z builda, odpalenia testów jednostkowych, e2e, wydajnościowych i mógłbym to sobie wszystko podglądać w Jenkinsie? I aby była możliwość odpalenia tego pp zarówno z palca i aby odpalał się także automatycznie po każdym pushu do głównego brancha?

Bardzo dobry kierunek. Jak chcesz się nauczyć narzędzia to nie ma sensu pisać od zera swojego projekciku, bo przecież celem nie jest napisanie projektu tylko nauka narzędzia.

Zacznij tak:

1. Znajdź przykładowy projekt "demo" open-source pokazujący jak korzystać z danej technologii. Jakiś Spring Pet Clinic, eShop On Containers al;bo coś w tym stylu.
2. Zobacz jakie testy tam już są i w razie braku (a na pewno będą braki) dopisz co potrzeba - czy to testy E2E czy wydajnościowe - jak zajmujesz się testami automatycznymi to nie powinno to stanowić problemu.
3. Rzuć okiem na przykładowe pipeline'y w Jenkinsie i zacznij rzeźbić swój. Jak każdy dobrze wie, najlepsza nauka to zrobienie czegoś samemu. Więc nie sil się na wielodniowe czytanie dokumentacji i oglądanie filmików na YT/Udemy tylko zacznij klepać swoje pipeline'y i dopiero jak natrafisz na coś czego nie wiesz jak zrobić to szukaj w dokumentacji. Tutaj będziesz musiał się zastanowić jak to podzielić na pipeline'y, to już w zależności od konkretnych wymagań, ale zazwyczaj spodziewałbym się, że np. testy wydajnościowe nie będą zawsze odpalane razem z procesem budowania apki i testowania jednostkowego tylko raczej jakimś jobem odpalanym w nocy co X czasu (przydałoby się to testować na w miarę realnej infrastruktutrze). Tym sposobem nauczysz się też jak zrobić pipeline triggerowany z każdym commitem i takie triggerowane jakimś CRONem. Nie wiem jak Jenkins, ale inne toole albo umożliwiają by-design odpalenie każdego pipeline'u z palca (Azure DevOps), albo trzeba dodać dodatkowy "trigger" (GitHub Actions). To już znajdziesz w dokumentacji.

Dzięki temu poznasz narzędzie i jego możliwości i następnym razem będziesz już wiedział co w nim da się zrobić, a do czego może nie jest najlepszy i trzeba szukać czegoś innego.

Warto dodać że nieumiejętne dodanie narzędzia do projektu może przysporzyć więcej szkody niż pożytku. Np dokeryzacja projektu może się okazać wartościowa, ale może się okazać że to tylko spowalnia zespół i nie zwraca się czasowo. Więc warto dodać narzędzia do projektu wtedy kiedy faktycznie jest na nie potrzeba, a nie tylko po to żeby były. Każda narzędzie dostarcza potencjalną wartość, ale ma też koszt (który może się okazać mniejszy lub większy niż wartość, zależnie od projektu).

Warto dodać, że nikt chyba nie wyobraża sobie obecnie nowoczesnego projektu bez serwera automatyzacji jak Jenkins/GitHub/GitLab/Azure DevOps, więc nauka takiego narzędzia zawsze będzie wartością dodaną
Zarówno dla ciebie osobiście, bo poszerzysz swoją wiedzę, jak i dla każdego zespołu, który być może jeszcze z takiego narzędzie nie korzystał (ciężko mi to sobie wyobrazić w 2024 roku), a ty to wprowadzisz.

Klaun napisał(a):

Warto dodać, że nikt chyba nie wyobraża sobie obecnie nowoczesnego projektu bez serwera automatyzacji jak Jenkins/GitHub/GitLab/Azure DevOps, więc nauka takiego narzędzia zawsze będzie wartością dodaną

No właśnie takie przekonanie że "warto dodawać bezmyślnie narzędzia", bo "tak się robi" to jest często to co spowalnia projekt.

Zgodzę się że dodanie kontroli wersji faktycznie zawsze się przyda (czyli dodanie gita). Mogę się zgodzić że wrzucenie repo gitowego do github/gitlab/bitbucket/azure się przyda w 98-99% projektów (bo też nie wszystkich). Ale pozostałe rzeczy, jak jenkins albo ci/cd w azure - dodanie tego bezmyślnie, bez konkretnego celu, słabe.

Jenkins i AzureDevOps to są dobre narzędzia - ale pod warunkiem że używasz ich do jakiegoś konkretnego celu, kiedy masz na nie potrzebe, a nie dodaje się je z automatu "bo tak".

No właśnie takie przekonanie że "warto dodawać bezmyślnie narzędzia", bo "tak się robi" to jest często to co spowalnia projekt.

Nikt nie napisał, żeby dodawać bo "tak się robi". Bredzisz po raz 342422 w tym wątku.

Te narzędzia mają bardzo prosty w założeniu i zrozumiały przez wszystkich (chyba? bo zaczynam powoli wątpić) cel, jakim jest automatyzacja procesów, co ma zapewnić lepszą jakość i wdrażanie zmian w bardziej kontrolowany/szybszy/bezpieczniejszy sposób. A że w każdym projekcie te cele są wartościowe to i w każdym projekcie używa się takich narzędzi.

Klaun napisał(a):

Te narzędzia mają bardzo prosty w założeniu i zrozumiały przez wszystkich (chyba? bo zaczynam powoli wątpić) cel, jakim jest automatyzacja procesów, co ma zapewnić lepszą jakość i wdrażanie zmian w bardziej kontrolowany/szybszy/bezpieczniejszy sposób. A że w każdym projekcie te cele są wartościowe to i w każdym projekcie używa się takich narzędzi.

No właśnie o tym mówię.

Nie koniecznie zawsze w projekcie jest potrzeba żeby wdrażać coś w w bardziej kontrolowany/szybszy/bezpieczniejszy sposób. Jest wiele projektów które mają tylko kontrolę wersji i testy, i to w 100% spełnia wymagania biznesowe, i nie ma żadnych problemów z takim softwarem. Wtedy dodawanie dodatkowych narzędzi w imię co ma zapewnić lepszą jakość i wdrażanie zmian w bardziej kontrolowany/szybszy/bezpieczniejszy sposób jest niepotrzebnym kosztem i się mija z celem. Wtedy to jest rozwiązywanie problemów których nie ma.

Wszystko się sprowadza do tego czy masz potrzebę rozwiązać jakiś problem - jeśli masz, to dobierz do tego odpowiedni środek. Jeśli nie, to wygrałeś i nie musisz nic robić.