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? Co mu przeszkadza w pracy? Z czym ma trudność?
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ć.

Ciekawa dyskusja i argumenty chłopaki @Klaun @Riddle, dziękuję za zainteresowanie wątkiem.

Jednak tutaj lepiej Klaun zrozumiał moją potrzebę, bo o ile byłbym w projekcie i dostał polecenie "znajdź odpowiedź na nasze problemy" to wtedy pewnie Riddle miałby rację, natomiast tak jak słusznie zauważył Klaun ja potrzebuję tylko dodać umiejętności do arsenału na tyle, aby umieć odpowiedzieć na pytania na interview i nie być kompletnie zielonym wchodząc do projektu np. z jenkinsem, czy dockerem.

Żeby nie było pustego postu to zacząłem sobie realizować ścieżkę w ten sposób:

1. postawiłem maszynę wirtualną z jenkinsem na azure
2. utworzyłem na swoim githubie repo z apką pet clinic.
3. zintegrowałem repo na githubie z jenkinsem

Teraz przerabiam materiały z tworzenia tasków na jenkins, napiszę testy api i zbuduję pipeline w jenkinsie, który będzie mi kompilował apkę i odpalał testy.

Dalej będę się zastanawiał jak do tej zabawy dodać dockera.

Powtarzam, że tutaj wszystko ma charakter szkoleniowy i eksperymentalny. Celem jest zrozumienie co do czego służy i poznanie funkcjonalności.

Dalej będę się zastanawiał jak do tej zabawy dodać dockera.

Możesz sobie dodać dockera jako element środowiska uruchomieniowego dla zadań. Wówczas, część automatyzacji będziesz mógł implementować jako uruchomienia obrazów dockerowych i tylko przesuwać artefakty pomiędzy tymi zadaniami, np. dla javy, zamiast instalować jdk i mavena loklanie, to używasz obrazu z mavenem i jdk. Do kontenera podpinasz wolumen ze źródłami, a na wyjściu dostajesz dostajesz app.jar który możesz dalej przekazywać. Na źródłach możesz uruchamiać skanery SAST, dla uruchomione aplikacji skanery DAST, na obrazach dockerowych security scany itd.
Do generowania dokumnetacji np. obraz dockerowy z pythonem + mkdocesm. Możesz też podnosić KINDa (Kubernates in Docker i tam deployować appkę do testów) itd. Możesz uruchamiać DINDa (docker in Docker) i tam coś działać itd.

yarel napisał(a):

Dalej będę się zastanawiał jak do tej zabawy dodać dockera.

Możesz sobie dodać dockera jako element środowiska uruchomieniowego dla zadań. Wówczas, część automatyzacji będziesz mógł implementować jako uruchomienia obrazów dockerowych i tylko przesuwać artefakty pomiędzy tymi zadaniami, np. dla javy, zamiast instalować jdk i mavena loklanie, to używasz obrazu z mavenem i jdk. Do kontenera podpinasz wolumen ze źródłami, a na wyjściu dostajesz dostajesz app.jar który możesz dalej przekazywać. Na źródłach możesz uruchamiać skanery SAST, dla uruchomione aplikacji skanery DAST, na obrazach dockerowych security scany itd.
Do generowania dokumnetacji np. obraz dockerowy z pythonem + mkdocesm. Możesz też podnosić KINDa (Kubernates in Docker i tam deployować appkę do testów) itd. Możesz uruchamiać DINDa (docker in Docker) i tam coś działać itd.

Dzięki bardzo <3

KarnyJerzy napisał(a):

...

Szefie, jakbyś znalazł chwilę i rozpisał to na małe taski co mam po kolei zrealizować bardziej łopatologicznie to pomodlę się za Ciebie do św. Piotra, bo brzmi to bardzo ciekawie, ale cholernie skomplikowane i abstrakcyjne jak na mój obecny stan wiedzy.

Tak na szybko:

Task#1 - zainstaluje dockera na virtualce z jenkinsem
Task#2 - sprawdź czy doker działa, uruchamiając np. hello-worlda
Task#3 - dodaj do jenkins plugin do integracji z dockerem i go skonfiguruj do korzystania z lokalnego dockera
Task#4 - zdefiniuj JOB#1, który skorzysta z obrazu busybox i zapisze "Hello CI/CD world!" do pliku output.txt
Task#5 - w post action joba zarchiwizuj output.txt
Task#6 - zrób JOB#2, dla którego:
a) skopiujesz output z JOB#1 (po to ta archiwizacja)
b) uruchomisz w ramach dockera prosty skrypt (użyj dla odmianu obrazu alpine), który wyprodukuje output.txt o zawartości
Greeting from previous job: <tu content ze skopiowanego artefaktu z joba#1>
c) zarchiwizujesz wyprodukowany artefakt

To czego powinieneś się nauczyć to: instalacja dockera, uruchamianie kontenera z obrazu, sprawdzenie statusu kontenera, usunięcie kontenera. Konfiguracja jenkinsa (plugin + ustawienia pluginu) do używania dockera. Uruchomienie w ramach dokera jakiejś funkcjonalności. Dzielenie artefaktów między jobami (output jednego, jest inputem dla innych).

Jadę na urlop, a Ty działaj ;-)

yarel napisał(a):

Tak na szybko:

Task#1 - zainstaluje dockera na virtualce z jenkinsem
Task#2 - sprawdź czy doker działa, uruchamiając np. hello-worlda
Task#3 - dodaj do jenkins plugin do integracji z dockerem i go skonfiguruj do korzystania z lokalnego dockera
Task#4 - zdefiniuj JOB#1, który skorzysta z obrazu busybox i zapisze "Hello CI/CD world!" do pliku output.txt
Task#5 - w post action joba zarchiwizuj output.txt
Task#6 - zrób JOB#2, dla którego:
a) skopiujesz output z JOB#1 (po to ta archiwizacja)
b) uruchomisz w ramach dockera prosty skrypt (użyj dla odmianu obrazu alpine), który wyprodukuje output.txt o zawartości
Greeting from previous job: <tu content ze skopiowanego artefaktu z joba#1>
c) zarchiwizujesz wyprodukowany artefakt

To czego powinieneś się nauczyć to: instalacja dockera, uruchamianie kontenera z obrazu, sprawdzenie statusu kontenera, usunięcie kontenera. Konfiguracja jenkinsa (plugin + ustawienia pluginu) do używania dockera. Uruchomienie w ramach dokera jakiejś funkcjonalności. Dzielenie artefaktów między jobami (output jednego, jest inputem dla innych).

Klasyczny przerost formy nad treścią - zaczynanie od obsługi narzędzi bez konkretnego celu po co to się robi.

Powinieneś zacząć od konkretnego problemu który próbujesz naprawić - co teraz się dzieje co nie powinno (albo co się nie dzieje co powinno), w czym to przeszkadza ludziom, jakie to ma negatywne konsekwencje? Takim problemem może być np: "nasze wdrożenia trwają 45 minut, a chcemy żeby trwały 15 minut". I wtedy próbujesz znaleźć najtańsze i najprostsze rozwiązanie tego problemu (jeśli możesz go rozwiązać skryptem w bashu napisanym w 15 minut, to zrób to!). Problemów może być więcej, może chodzić o ilość bugów, o problemy z integracją, etc. Ale trzeba wyjść od tych problemów, w stylu: "Mamy problem X, a potrzebujemy mieć konkretnie Y". Samo to sprecyzowanie tego co na prawdę próbujesz naprawić jest trudne. Wymaga myślenia. Wtedy można znaleźć odpowiednie narzędzie do tego celu.

Jest to całkiem inne podejście od tego w którym ktoś: nie myśli w ogóle o faktycznych problemach (tylko o potencjalnych), nie myśli o konkretnych rozwiązaniach (tylko liczy na doskonałość wdrażanego rozwiązania, że "samo się naprawi"), i dodaje takie narzędzie do projektu licząc że sama jego obecność (np. korzystanie z jenkinsa, dockera, k8s) zwiększy produktywność. Tymczasem jeśli konkretne problemy nie są zaadresowane, tylko po prostu "dodaje się" narzędzie "bo tak", to szansa jest duża że zespół dostanie tylko koszt związany z utrzymaniem kolejnego narzędzia, bez faktycznego improvementu.

Większośc ludzi nie lubi myśleć, nie chce im się zastanawiać jaki faktycznie problem potrzebują rozwiązać, tylko woli z automatu powiedzieć "nie wiem jaki macie problem, ale wrzucę tutaj po prostu narzędzie X".

Riddle napisał(a):

yarel napisał(a):

Tak na szybko:

Task#1 - zainstaluje dockera na virtualce z jenkinsem
Task#2 - sprawdź czy doker działa, uruchamiając np. hello-worlda
Task#3 - dodaj do jenkins plugin do integracji z dockerem i go skonfiguruj do korzystania z lokalnego dockera
Task#4 - zdefiniuj JOB#1, który skorzysta z obrazu busybox i zapisze "Hello CI/CD world!" do pliku output.txt
Task#5 - w post action joba zarchiwizuj output.txt
Task#6 - zrób JOB#2, dla którego:
a) skopiujesz output z JOB#1 (po to ta archiwizacja)
b) uruchomisz w ramach dockera prosty skrypt (użyj dla odmianu obrazu alpine), który wyprodukuje output.txt o zawartości
Greeting from previous job: <tu content ze skopiowanego artefaktu z joba#1>
c) zarchiwizujesz wyprodukowany artefakt

To czego powinieneś się nauczyć to: instalacja dockera, uruchamianie kontenera z obrazu, sprawdzenie statusu kontenera, usunięcie kontenera. Konfiguracja jenkinsa (plugin + ustawienia pluginu) do używania dockera. Uruchomienie w ramach dokera jakiejś funkcjonalności. Dzielenie artefaktów między jobami (output jednego, jest inputem dla innych).

Klasyczny przerost formy nad treścią.

Twój komentarz nic nie wnosi do dyskusji. Jeśli chcesz by był wartościowy, to zaproponuj alternatywne ćwiczenia do nauki narzędzi.

yarel napisał(a):

@Riddle: jak nie znasz narzędzia, to trudno żebyś rozważał jego użycie. Jak poznać narzędzie?

Jesteśmy ludźmi, którzy są dobrzy w ogarnianiu systemów IT, ale nadal ludźmi. Kiedy myślimy "co teraz zrobić", musimy się czegoś złapać. Jeśli nie mamy nic konkretnego, łapiemy się tego co jest. Dlatego kiedy ktoś wchodzi do projektu, i "nie wiem nic", to łapie się tego co już zna, np. znanych narzędzi, i patrzy na projekt przez ich pryzmat (bo to jest łatwiejsze) - nie ważne czy te narzędzia są faktycznie pomocne albo wartościowe w tym przypadku.

Nie warto ulegać tej pokusie.

Warto zrobić bardzo nieprzyjemną rzecz - zacząć myśleć. Zacząć się zastanawiać - jaki faktycznie problem próbuję rozwiązać. Za mało dowozimy. Za wolne deploye. Za dużo bugów. Za dużo ticketów. Za dużo nadgodzin. Za dużo niezadowolonych klientów. Za dużo "work in progress". Jakikolwiek problem. Zwróć uwagę na jeden konkretny problem, weźmy np. "za wolne deploye". Krok pierwszy, sprawdź ile teraz trwają. Sprawdzasz, powiedzmy że trwają 45 minut. Zaczynasz myśleć (to jest trudna rzecz, a jednocześnie główny powód Twojego zatrudnienia w firmie - że myślisz). Zaczynasz się zastanawiać ile powinny trwać. Załóżmy że dochodzisz do wniosku, że dobrze by było żeby trwały 10 minut. Więc masz konkretny cel:

• Jak zrobić, żeby skrócić czas deploy'ów z 45 minut do 10 minut.

I tyle. To jest Twoje jedyne zadanie na ten moment.

I zaczynasz szukać rozwiązania pod ten jeden konkretny cel. Załóżmy że tak jak mówisz ktoś nie zna narzędzi. Nie ma problemu! Ja też wielu narzędzi nie znam. Więc zaczynam szukać w google informacji jak skrócić czas deployów - programiści i ludzie w IT są względnie dobrzy w szukaniu informacji. Natrafiam na artykuły, filmy, tutoriale, przykłady, opinie, posty na SO. Jeśli jakiś pomysł albo narzędzie uznam za warte wprowadzenia, to spróbuję.

• Dla przykładu: nie znam jenkinsa, ale słyszałem że jest dobry. Dodaję go więc do projektu, i widzę że deploye trwają 45 minut tak jak trwaly. Nie trafiony pomysł, usuwam to.
• Drugi przykład: widzę że 60% czasu deploya schodzi na budowanie obrazów dockerowych. Zastanawiam się czy jest jakiś sposób zeby to skrócić? Np. zaczynając budowanie obrazów wcześniej przed deployem, tak żeby podczas deploya, ten obraz był już gotowy. Wprowadzam takie rozwiązanie - teraz, ponieważ obraz jest już gotowy, deploy trwa tylko 20 minut. Krok w dobrą stronę, zostawiam to.

I tak dalej, aż osiągniesz swój cel 10 minut. Kiedy to zrobisz, to faktycznie rozwiązałeś istotny problem. I tak należy postępować ze wszystkimi problemami.

Podsumowanie

Mam wrażenie, że zarówno Ty @yarel jak i autor wątku @KarnyJerzy, jak i niektórzy również rekruterzy, wychodzą z założenia ze "sama znajomość narzędzia" jest wszystkim. Że jak znasz narzędzie, to wygrałeś.

Tymczasem to jest tylko część układanki. Musisz również wiedzieć kiedy warto go zastosować a kiedy nie; oraz musisz wiedzieć jak należy rozwiązywać problemy które musisz rozwiązać. Nic Ci nie da znajomość narzędzia jeśli używasz go w złym kontekście. Co Ci da znajomość narzędzia, jeśli nie ma potrzeby go stosować? Nic.

Na rynku jest pierdylion projektów do których dowalone są wszelkie jenkinsy, dockery, k8sy, terraformy, które w niczym totalnie nie pomagają (bo zostały dodane "na pałe", albo "bo modne"), a dodają tylko dodatkowe komplikacje.

Mam wrażenie, że zarówno Ty @yarel jak i autor wątku @KarnyJerzy, jak i niektórzy również rekruterzy, wychodzą z założenia ze "sama znajomość narzędzia" jest wszystkim. Że jak znasz narzędzie, to wygrałeś.

No ale to jest Twoje wrażenie. Nie wiem jak ma się do to rekruterów, czy kolegi @KarnyJerzy , ale nie uważam, że "sama znajomość narzędzia" jest wszystkim. IMO warto znać narzędzia i do tego różnorodne. To, że potrafię posługiwać się multimetrem, to nie znaczy, że "wygrałem".

Kolega @KarnyJerzy chce się uczyć nowych narzędzi, ja popieram taką postawę uczenia się nowych rzeczy, dlatego zasugerowałem minimalny zestaw ćwiczeń na pierwsze kroki w temacie. Kolega chce przećwiczyć wykorzystanie narzędzi. Jeśli chcesz, żeby wyszedł od use case'y -> narzędzia (a nie narzędzia -> use case'y), to zaproponuj mu konkretne scenariusze, do których będzie mógł dobrać narzędzia. Myślę, że to będzie wartościowe i komplementarne podejście.

yarel napisał(a):

Mam wrażenie, że zarówno Ty @yarel jak i autor wątku @KarnyJerzy, jak i niektórzy również rekruterzy, wychodzą z założenia ze "sama znajomość narzędzia" jest wszystkim. Że jak znasz narzędzie, to wygrałeś.

No ale to jest Twoje wrażenie. Nie wiem jak ma się do to rekruterów, czy kolegi @KarnyJerzy , ale nie uważam, że "sama znajomość narzędzia" jest wszystkim. IMO warto znać narzędzia i do tego różnorodne. To, że potrafię posługiwać się multimetrem, to nie znaczy, że "wygrałem".

@yarel Twój post Budowa infrastruktury CI/CD dla istniejącej aplikacji z Jenkinsem, Dockerem - pomoc w wystartowaniu mówi tylko i wyłącznie o narzędziach, więc takie wrażenie sprawiasz.

yarel napisał(a):

Kolega @KarnyJerzy chce się uczyć nowych narzędzi, ja popieram taką postawę uczenia się nowych rzeczy, dlatego zasugerowałem minimalny zestaw ćwiczeń na pierwsze kroki w temacie. Kolega chce przećwiczyć wykorzystanie narzędzi.

Też popieram znajomość wielu narzędzi.

Ale czym innym jest znać wiele narzędzi w otoczeniu umiejętności rozwiązywania problemów (którą to znajomość zdobyło się korzystając z nich do rozwiązywania faktycznych problemów); a czym innym jest uczenie się narzędzi na pałę, bez wiedzy po co to się robi (co zdaje się @KarnyJerzy oczekiwać, i co zdajesz się Ty sugerować).

Także:

• Uczenie się nowych narzędzi - słabe (nic to nie wnosi).
• Rozwiązywanie prawdziwych problemów, w skutek czego poznaje się nowe narzędzia - jak najbardziej.

yarel napisał(a):

Jeśli chcesz, żeby wyszedł od use case'y -> narzędzia (a nie narzędzia -> use case'y), to zaproponuj mu konkretne scenariusze, do których będzie mógł dobrać narzędzia. Myślę, że to będzie wartościowe i komplementarne podejście.

No przecież napisałem i to dwa razy w tym wątku.

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

Riddle napisał(a):

yarel napisał(a):

Mam wrażenie, że zarówno Ty @yarel jak i autor wątku @KarnyJerzy, jak i niektórzy również rekruterzy, wychodzą z założenia ze "sama znajomość narzędzia" jest wszystkim. Że jak znasz narzędzie, to wygrałeś.

No ale to jest Twoje wrażenie. Nie wiem jak ma się do to rekruterów, czy kolegi @KarnyJerzy , ale nie uważam, że "sama znajomość narzędzia" jest wszystkim. IMO warto znać narzędzia i do tego różnorodne. To, że potrafię posługiwać się multimetrem, to nie znaczy, że "wygrałem".

@yarel Twój post Budowa infrastruktury CI/CD dla istniejącej aplikacji z Jenkinsem, Dockerem - pomoc w wystartowaniu mówi tylko i wyłącznie o narzędziach, więc takie wrażenie sprawiasz.

Nawiązuje to dokładnie do prośby kolegi, który poprosił o ćwiczenia z konkretnych narzędzi (wymienia je nawet w pierwszym poście).

yarel napisał(a):

Kolega @KarnyJerzy chce się uczyć nowych narzędzi, ja popieram taką postawę uczenia się nowych rzeczy, dlatego zasugerowałem minimalny zestaw ćwiczeń na pierwsze kroki w temacie. Kolega chce przećwiczyć wykorzystanie narzędzi.

Też popieram znajomość wielu narzędzi.

Ale czym innym jest znać wiele narzędzi w otoczeniu umiejętności rozwiązywania problemów (którą to znajomość zdobyło się korzystając z nich do rozwiązywania faktycznych problemów); a czym innym jest uczenie się narzędzi na pałę, bez wiedzy po co to się robi (co zdaje się @KarnyJerzy oczekiwać, i co zdajesz się Ty sugerować).

Także:

• Uczenie się nowych narzędzi - słabe (nic to nie wnosi).

Idąc tym tropem rozumowania, to np. nie warto uczyć się nowych języków programowania, bo jest to słabe i nic nie wnosi ;-) Alternatywą byłoby stosowanie języka, którego się nie zna do napisania produkcyjnego systemu? Odważnie.

• Rozwiązywanie prawdziwych problemów, w skutek czego poznaje się nowe narzędzia - jak najbardziej.

OK. Osobiście nie ograniczam się tylko do tego.

No przecież napisałem i to dwa razy w tym wątku.

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

Jaki zestaw narzędzi zaproponowałbyś do rozwiązania tego use case'a? Tak by op mógł je sobie przećwiczyć.