Witam, pracuje jako fullstack java+spring, js+angular, rok doświadczenia, w wielu ofertach widze że dobrze jest znać obszar CI/CD.
Tutaj pytania,
Abyś wiedział co to Jenkins, jak powinien być skonfigurowany i potrafił napisać Dockerfile. Wątpię, żeby więcej było trzeba jak w ofercie jest CI/CD.
Tak jak napisał @tsz, a dokładniej:
Ad. 1.
CI/CD to bardzo szeroki temat i jest wiele różnego serwerów do CI/CD, ale szczęśliwie dla Javy najpopularniejszy jest Jenkins.
IHMO popularny jest też TravisCI dla OpenSource (bo jest wtedy za darmo), ale to też jest proste. Jeden plik yaml do konfiguracji
Ad. 2.
Docker to dość mała ilość w wiedzy. Kubernetes to ogromna ilość wiedzy.
Zacznij od Dockera. Zwykle jest potrzebna umiejętność wyciągania logów i logowania się do Dockera. W teorii wiem jak pisać docker-compose w praktyce nigdy nie musiałem tego robić. Nie wiem czy mam szczęście czy pecha.
Kubernetesa lepiej uczyć się w miarę potrzeb lub kupić sobie jakąś prostą przekrojową książkę jak Kubernetes. Tworzenie niezawodnych systemów rozproszonych
Ja bym najpierw zaczął od tego, czym faktycznie jest CI/CD. Jenkins i Docker to narzędzia do CI/CD. Choć pewnie rekruterowi i tak chodzi tylko o to, czy ogarniasz Jenkinsa :)
https://en.wikipedia.org/wiki/Continuous_integration
Dodałbym do tego co wyminił @tsz podstawy linuksa jak poruszać sie po konsoli i obsługa cp/mv/rm/ln/ls/cat/more/less/mkdir/ssh/scp/sudo/ps/grep. Podstawy podstaw z sieci. Wymiana kluczy aby logować się bez haseł, generowanie kluczy. Ustawianie zmiennych środowiskowych. Gdzie ustawia sie klucze dla gradla czy mavena jeśli mamy zabezpieczone artifactory. Znajomość procesu publikacji do artifactory. I to samo dla docker tj proces budowania, publikacji i co to jest docker trusted registry.
Ja bym się zestanowil czy chcesz być Developerem aka Klepaczem czy wolisz pretendowac do miana Software Engineer.
CI/CD to dla mnie oczywista oczywistość, wymagam tego od ludzi z zespołu jak oddychania gdy mamy na myśli jakiekolwiek pipelines.
Bo nie zamierzam nianczyc lamusów. Jak ktoś nie rozumie pipeline, jak buduje się applikacja, jak są puszczane testy i jak deployuje to wypad, nie powinien przejść rekrutacji.
Żyjemy w czasach gdzie już nie potrzeba nam Jenkinsa, są dużo lepsze narzędzia. Jenkins to jest syf, kto kiedyś to własnoręcznie utrzymywał to zrozumie.
Powinieneś rozumieć dockera i jak JVM zachowuje się w dockerze. Co do Kubernetesa powinieneś wiedzieć jak deployowac i znać podstawowe rzeczy jak pod, service, deployment, ingress I że jest to narzędzie do orchestracji microservices.
Znając dockera to compose jest do ogarnięcia przez intuicję.
Ja od zawsze dążę do rozumienia full cycle of software development, od A do Z I brac pełna odpowiedzialność za to co się dostarcza.
@karsa: Tak tak i jeszcze frytki do tego :). Zastanawia mnie czy w zespole też jesteś takim bucem ? Jeśli tak to współczuje zespołowi.
Doczytałeś ty może pierwszy post a mianowicie ten fragment -> "rok doświadczenia" ?
Jeżeli po osobie z rocznym doświadczeniem oczekujesz biegłości z sieci, przynajmniej dwóch systemów budujących pewnie jeszcze kwestie security + java, spring. Do tego dokładasz, że taka osoba powinna znać dobrze dockera, kubernetesa i do tego jeszcze zachowanie JVM na dockerze może jeszcze ma znać różnice w zachowaniu Azula od Oracla? A to dopiero początek bo nawet nie tkneliśmy frontendu gdzie jest drugie tyle kwestii. Zastanów się człowieku co ty pieprzysz.
Schadoow napisał(a):
@karsa: Tak tak i jeszcze frytki do tego :). Zastanawia mnie czy w zespole też jesteś takim bucem ? Jeśli tak to współczuje zespołowi.
Doczytałeś ty może pierwszy post a mianowicie ten fragment -> "rok doświadczenia" ?
Jeżeli po osobie z rocznym doświadczeniem oczekujesz biegłości z sieci, przynajmniej dwóch systemów budujących pewnie jeszcze kwestie security + java, spring. Do tego dokładasz, że taka osoba powinna znać dobrze dockera, kubernetesa i do tego jeszcze zachowanie JVM na dockerze może jeszcze ma znać różnice w zachowaniu Azula od Oracla? A to dopiero początek bo nawet nie tkneliśmy frontendu gdzie jest drugie tyle kwestii. Zastanów się człowieku co ty pieprzysz.
Opisuje rzeczy które powinniśmy wiedzieć jako programiści i do czego należy dążyć. Nie napisałem, że wymagam tego od razu od OP.
W ciągu roku doświadczenia powinno dotknąć CI mimo wszystko. Jako junior też.
Nigdzie nie opisałem, że programista ma znać dobrze k8s, opisałem rzeczy do opanowania w 1 dzień. Żaden programista web nie zna dobrze k8s, to praca na pełen etat a nie z doskoku.
Sieci to warstwa na której bazujemy więc wypada mieć przygotowanie choćby teoretyczne.
W mojej pracy teoretycznie nie ma juniorów więc mogę pewnych rzeczy wymagać.
Nie rozumiem też umniejszania i jakby to było tak bardzo dużo, a nie jest.
mariusz00 napisał(a):
Tutaj pytania,
- Jaki obszar CI/CD powinien znać fullstack?
Fullstack? Potrafić dłubnąć sobie Dockerfile i go odpalić. Samo obrabianie frontu i backendu zwalnia Cię z dalszej zabawy w kierunku CI/CD. Fajnie jakbyś znał teorię od momentu gdy kod wisi na master do momentu gdy wisi w formie aplikacji online.
Jak chcesz zmienić kierunek i porzucić front na rzecz CI/CD to cóż mogę doradzić. Przejrzyj oferty powiązane z Java i zobacz co w nich występuje. Jak chcesz coś więcej to https://landscape.cncf.io/
- Jeśli byśmy mówili o Dockerze/Kubernetes(dockerfile, compose etc), jaki obszar wiedzy powinien mieć na ten temat fullstack?
Dockerfile - najtrudniejszeDockerfile vs docker-compose
Kubernetes nie powinien Ciebie interesować. Tak samo jak cała reszta. To jest oczywiście tylko moje zdanie i osobiście bym się tego trzymał. Nie da się ogarniać pisania kodu jako full-stack, ogarnianai 20 narzędzi do CI/CD i być w czymś ekspertem.
Zyskaj dobrą teorię + ogólne rozeznanie tak żeby znać cały pipeline od początku budowania aplikacji do końca.
Do Dockera polecam ten kurs: https://www.udemy.com/course/docker-tutorial/
Generalnie nie wszystko z niego wykorzystałem bo nie miałem jeszcze potrzeby , ale daje solidne podstawy
Schadoow napisał(a):
Doczytałeś ty może pierwszy post a mianowicie ten fragment -> "rok doświadczenia" ?
Jeżeli po osobie z rocznym doświadczeniem oczekujesz biegłości z sieci, przynajmniej dwóch systemów budujących pewnie jeszcze kwestie security + java, spring. Do tego dokładasz, że taka osoba powinna znać dobrze dockera, kubernetesa i do tego jeszcze zachowanie JVM na dockerze może jeszcze ma znać różnice w zachowaniu Azula od Oracla? A to dopiero początek bo nawet nie tkneliśmy frontendu gdzie jest drugie tyle kwestii.
Rok doświadczenia w zarządzaniu CI/CD utrzymywaniu build serwerów - nie przesadzajmy, że tylko wyklikanie najprostszego pipeline z gotowych klocków, Bo to jest do opanowania w parę godzin, na zasadzie znalezienia odpowiednich guzików w UI. Ale faktycznie sensowne zarządzanie pipeline as code (pamiętajmy, że różne wersje np. TeamCity mogą mieć nieco różne API, warto trzymać rękę na pulsie), do tego konfiguracja serwera (jeśli self-hosted), build agentów (może trzeba sobie napisać własny Dockerfile dla agenta - zahaczamy o znajomość Dockera), ogarnięcie jobów żeby nie było problemów z docker-in-docker, idealnie dobrze by było mieć doświadczenie z pisaniem pluginów.
Rok doświadczenia z dockerem / docker-compose - nie, że napiszesz na pałę Dockerfile i już pchasz do Dockerhub / Artifactory / ECR jakby jutra nie było, tylko umiesz wybrać odpowiedni base image do zadania, żeby obraz nie był zbyt ciężki, potrafisz w razie czego trochę odchudzić finalny obraz (w końcu jak się uzbierają setki artefaktów to te megabajty się kumulują), ogarniasz koncepcję multi-stage build, networking, volumes, zarządzanie obrazami i kontenerami. Compose też musisz napisać jak należy, a nie w ciemno i trzymać kciuki żeby jeden kontener nie wstał przed drugim do którego ma zależność. Dochodzą oczywiście kwestie security - spróbuj tylko przepychać secrety i klucze przez env, to zaraz ktoś je wyciągnie inspectem.
Rok doświadczenia z k8s - wiadomo, nie wystarczy wrzucić "jakiś" pod, deployment, service i ingress do YAMLa i wypchnąć. Dobrze by było umieć pracować z konsolą, dashboardami, wesprzeć się dodatkowymi narzędziami (np. helm). Umieć to skonfigurować tak, żeby dało się przeprowadzić upgrade bez downtime i jednocześnie nie wyżreć wszystkich dostępnych zasobów - przede wszystkim wiedzieć, jak może przebiegać taki upgrade, znać kilka rodzajów, umieć je konfigurować. Umieć przydzielać zasoby, skonfigurować readiness / liveness probes, podpiąć do wszystkiego monitoring etc. Umieć w skalowanie np. poprzez HPA. Jak już zahaczamy o temat k8s, warto też znać jakieś podstawowe wzorce/pojęcia które mogą się przewijać, umieć ich użyć np. dostawić sidecar, wiedzieć kiedy to się może przydać.
Rok doświadczenia z co najmniej jednym cloud providerem - umieć skonfigurować zasoby pod aplikację, aspekty security, dostępy, monitoring, alerty, może funkcje / lambdy zależnie od tego czego się używa, wszystko tak żeby "klałd" nie żarł dziesiątek tysięcy dolarów za hostowanie deva, perfa i proda dla CRUDowej apki z 10k userów (bo to oczywiste, że taka apka koniecznie musi być w klałdzie - takie mamy czasy). Mile widziane certyfikaty.
Rok doświadczenia z Java + Spring - tutaj oczywiście mamy do czynienia ze stricte kodowaniem, a nie ogarnianiem CI i k8s i udawaniem, że to też się liczy do doświadczenia w programowaniu w Javie. Wiadomo, co tu dużo mówić - znajomość samego języka i bebechów frameworka, narzędzi deweloperskich i do debugowania, przydatnych bibliotek (jak choćby Jackson / Gson etc), obycie z maven / Gradle, dobrze by było znać w miarę dobrze JPA i Hibernate (ewentualnie co inne - JDBCTemplates, jooq, ale to może dyskfalifikować tu i tam, bo jednak musi być Hibernate), umieć rozwiązywać typowe problemy (podbijamy wersję zależności i nagle kontekst aplikacji nie wstaje, AOP czegoś nie łapie). Oczywiście, podobnie jak w poprzednich punktach przewija się nam aspekt security, znać OWASP top 10, wiedzieć skąd się może wziąć SQLi albo XSS vuln w mojej aplikacji, umieć się przed tym zabezpieczyć, idealnie coś-tam potestować choćby z palucha, ograniczać dostępy do zasobów tak żeby nawet w razie wycieku tokenów minimalizować straty, skonfigurować autentykację i autoryzację, najlepiej na kilka sposobów, znać różnice między popularnymi OAuth providerami np. Okta, Azure. Plus dokumentacja - zarządzanie Swaggerami i innymi takimi, wersjonowanie API etc.
Rok doświadczenia z bazami danych, skoro już jesteśmy przy JPA/Hibernate - dobra znajomość SQL i smaczków danego DBMS to podstawa, do tego tematy takie jak optymalizacja zapytań, indeksy (wiedzieć, kiedy jakiego użyć, jaki jest koszt), normalizacja / denormalizacja, wersjonowanie schemy i zarządzanie wersjami, migracje, orientowanie się w tematyce replikacji i partycjonowaniu bazy (i z czym się to wiąże), transakcje, różne poziomy izolacji. Dobrze by było mieć doświadczenie bojowe z jakimś NoSQL do porównania.
Rok doświadczenia w testowaniu - to jest temat rzeka sam w sobie. Testy jednostkowe, integracyjne, trzeba umieć pisać je dobrze - i znać narzędzia do testowania, umieć je odpowiednio zastosować, a nie tylko JUnit, Mockito, mockujesz klasę za klasą i do przodu. Nie mówiąc o testach API / e2e / wydajnościowych i tak dalej. W temacie narzędzi do testowania i klałda, prawdopodobnie przydatna będzie znajomość np. Wiremock, TestContainers i tym podobnych.
Na front-end się nie znam, więc nie będę się tu rozmieniał na drobne, przyjmijmy asekuracyjnie że na froncie wystarczy rok doświadczenia sumarycznie - jako plan minimum.
Oczywiście dla niektórych zagadnień można by skrócić kadencję do np. pół roku albo 3 miesięcy rzeczywistej pracy (robota z doskoku?), ale jeśli mówimy o roku to niech już będzie rok na wszystko - kto miał do czynienia z odpowiedzią "no ale Pan ma rok i 11 miesięcy a nie 2 lata" ten wie. Druga sprawa, że cały front sprowadziłem do "jednego" aspektu do opanowania, także trochę się nam to równoważy.
Podsumowując, nie jest źle - wystarczy tylko ok. 8 lat pracy i już można być całkiem sensownym juniorem z rocznym doświadczeniem w najbardziej kluczowych kwestiach.
Uważam, że większość z tego to koloryzowanie i dopisywanie filozofii do tej "wielkiej znajomości" a wiekszosc to copy paste i odrobina zdrowego rozsądku. Programista web/backend musi umieć stosunkowo niewiele i mało się wymaga.
superdurszlak napisał(a):
Podsumowując, nie jest źle - wystarczy tylko ok. 8 lat pracy i już można być całkiem sensownym juniorem z rocznym doświadczeniem w najbardziej kluczowych kwestiach.
Scenka firmowa, szukanie ludzi do pracy
karsa napisał(a):
Uważam, że większość z tego to koloryzowanie i dopisywanie filozofii do tej "wielkiej znajomości" a wiekszosc to copy paste i odrobina zdrowego rozsądku. Programista web/backend musi umieć stosunkowo niewiele i mało się wymaga.
Copy pasta i powstaje kod w którym dodanie checkboxa trwa 2 tygodnie.
karsa napisał(a):
Uważam, że większość z tego to koloryzowanie i dopisywanie filozofii do tej "wielkiej znajomości" a wiekszosc to copy paste i odrobina zdrowego rozsądku. Programista web/backend musi umieć stosunkowo niewiele i mało się wymaga.
Ustalmy, gdzie leży granica między developerem / klepaczem a inżynierem, oraz co nazywamy znajomością i zrozumieniem. Nie zgodzę się, że inżynier miałby się różnić od klepacza umiejętnością kopiowania czegoś więcej, niż kodu w Javie, bo w webie akurat tyle wystarcza i od ogarniania jest kto inny - inżynier lepszego sortu, albo coś.
Może faktycznie masz zespół wymiataczy, którzy po paru dniach czytania przykładów z docsów i zrobieniu copy-paste posiadają już szeroką wiedzę i są gotowi na każdą ewentualność, możesz im dać dowolną aplikację a oni raz-dwa, od ręki zrobią tip-top deployment i już nie trzeba będzie wracać do tematu. Jeśli tak, to gratuluję i zazdroszczę.
Niemniej jednak dla mnie "znajomość" oznacza, że wiem z czym mam do czynienia, co robię, jakie mam przed sobą opcje i z czym się wiąże wybranie każdej z nich, widziałem je już w akcji, wiem co może pójść źle, jak tego mogę uniknąć itd. Nie będę się kłócił, klecenie YAMLi żeby zdeployować aplikację to może i są absolutne podstawy, ale nawet to po paru dniach oglądania tutoriali i czytania docsów zrobiłbym co najwyżej jakoś i jak mi się wydaje, a nie jak należy. I to dotyczy również wszystkiego innego - jeśli mam w wymaganiach znajomość CI/CD, to trochę dziwnie byłoby zakładać, że firmie zależy jedynie, bym miał już za sobą tą najgorszą godzinę pracy z danym build serwerem, gdy pierwszy raz widzisz UI. Jeśli w wymaganiach jest dobra znajomość baz danych, to też nie uznam, że poczytam sobie o różnicach między btree a brin i już wymiatam.
superdurszlak napisał(a):
Ustalmy, gdzie leży granica między
developerem / klepaczemainżynierem, oraz co nazywamyznajomościąizrozumieniem. Nie zgodzę się, że inżynier miałby się różnić od klepacza umiejętnością kopiowania czegoś więcej, niż kodu w Javie, bo w webie akurat tyle wystarcza i od ogarniania jest kto inny - inżynier lepszego sortu, albo coś.Może faktycznie masz zespół wymiataczy, którzy po paru dniach czytania przykładów z docsów i zrobieniu copy-paste posiadają już szeroką wiedzę i są gotowi na każdą ewentualność, możesz im dać dowolną aplikację a oni raz-dwa, od ręki zrobią tip-top deployment i już nie trzeba będzie wracać do tematu. Jeśli tak, to gratuluję i zazdroszczę.
Niemniej jednak dla mnie "znajomość" oznacza, że wiem z czym mam do czynienia, co robię, jakie mam przed sobą opcje i z czym się wiąże wybranie każdej z nich, widziałem je już w akcji, wiem co może pójść źle, jak tego mogę uniknąć itd. Nie będę się kłócił, klecenie YAMLi żeby zdeployować aplikację to może i są absolutne podstawy, ale nawet to po paru dniach oglądania tutoriali i czytania docsów zrobiłbym co najwyżej
jakośijak mi się wydaje, a niejak należy. I to dotyczy również wszystkiego innego - jeśli mam w wymaganiach znajomość CI/CD, to trochę dziwnie byłoby zakładać, że firmie zależy jedynie, bym miał już za sobą tą najgorszą godzinę pracy z danym build serwerem, gdy pierwszy raz widzisz UI. Jeśli w wymaganiach jest dobra znajomość baz danych, to też nie uznam, że poczytam sobie o różnicach międzybtreeabrini już wymiatam.
Nie mam obecnie dobrych ludzi w zespole i piszę z perspektywy, że większość wcale tej wiedzy nie ma ani nie jest to szczegolnie od nich wymagane. Większość egzystuje w danym environment.
Jak to realnie wyglada w praktyce, ktos nowy przychodzi do projektu:
Generalnie by sobie rączek nie połamali. Gdy sie setupuje troche tych aplikacji z biegiem czasu to nabywa sie odpowiedniej wiedzy i intuicji. Nie uwazam, że to jest tak dużo wiedzy. Juz w swojej pierwszej pracy setupowalem rzeczy od A do Z i poprzez analogie nie powiedzialbym, że sie wiele zmienilo.
"Seniorzy" z kilkuletnim doswiadczeniem nie wiedza czym jest jakis "graceful shutdown" - coś co jest przeciez kodem aplikacyjnym. Od niedawna zreszta jest defaultowa implementacja w springu. Albo "czemu dockera nie moge odpalac z roota?"
Bazy danych są mega ciężkie i wiekszosc ludzi jak mowi, że zna X to jest to bardzo powierzchowne i w wiekszosci programisci maja wiedze powierzchowna na wiele tematow. Wiekszosc applikacji jest źle zsetupowana tak czy inaczej, wszedzie znalazlbym jakies braki.... i nikomu to nie przeszkadza zazwyczaj.
Najczesciej "cos juz ktos zrobil" i tylko ludzie tego "używaja" mniej lub bardziej z rozmysłem. Czesto jednak powierzchowna wiedza + intuicja wystarcza.
To tez nie jest wszystko kwestia niewiedzy programistów, ale priorytetów.
Biorąc przykład z dużych firm produktowych:
Zespoły czysto produktowe mają priorytet dostarczać na produkcje, co sie wydaje ok... ale to nie do końca idzie w parze z utrzymaniem w ryzach tej produkcji w sensownym stanie.
Zazwyczaj takie rzeczy są priorytetem zespołów "platformowych".
Żeby to nie działało jak dwa silosy to musi byc jasna definicja production readyness, jakies NFRy, cokolwiek.
Czy jak w przypadku podejscia SRE - definiowanie SLA/SLO/SLI oraz Error Budgets... żeby to było wpisane w PRODUKT.
Bo jeżeli nie będzie to wpisane w produkt... to kto o to będzie dbał? To tylko będzie przepychanka. No można się czasem położyć jak Rejtan ale komu by się chciało walczyć z wiatrakami?