Jak powinno wyglądać portfolio przyszłego inżyniera devops? Możecie podać dobre przykłady, repozytoria, profile?
- Rejestracja:ponad 6 lat
- Ostatnio:2 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
5
Hm, ciekawe pytanie. IMHO devops inżynier to gość co wpada, konfiguruje i wypada . Chociaż zwykle za godzinę trzeba coś nowego konfigurować w projekcie XD
Wiec trudni mi sobie wyobrazić portfolio
Pyxis
Tym bardziej fajnie byłoby takie zobaczyć. A wydaje mi się, że można. Choćby jakiś swoje toole do automatyzacji w Pythonie czy Bashu.
- Rejestracja:ponad 2 lata
- Ostatnio:około 2 lata
- Postów:60
0
Podpinam się pod pytanie.
- Rejestracja:prawie 5 lat
- Ostatnio:dzień
- Postów:366
4
Myślę że najlepiej to napisać jakieś proste apki, jakiś monolit i mikroserwis, wszystko zdockercyzowac, podpiąć k8s i np. napisać jakiegos Terraforma do AWS, od czapy można jeszcze Vagranta wykorzystać. Dorobić automatyzację CI/CD w jakimś Github Actions albo CircleCI, load balancery na k8s itd. Opcji jest bez liku w sumie jakby się zastanowić
edytowany 1x, ostatnio: Escanor16
Pokazać tę wypowiedź komuś z poza IT i człowiek nie będzie nic rozumiał xd Masakra ile słów określających nazwę narzędzia. Kilkanaście słów kluczowych, za 5 lat to będzie X2 pewnie
Trochę tak, ale myślę, że nawet wannabe devops powinien wiedzieć o istnieniu części z tych narzędzi
Wiedzieć o istnieniu a umiec je użyć nawet na podstawowym poziomie i połączyć ze sobą to duża różnica.
- Rejestracja:ponad 2 lata
- Ostatnio:około 2 lata
- Postów:13
1
W jednej firmie DevOps będzie robił co innego, a w jeszcze innej co innego.
To jest minus tego stanowiska jak w przypadku Java Developera również, rozmyta granica odpowiedzialności i Twoich obowiązków.
Stąd też szedlbym w fundamenty czyli networking i wirtualizacja ale nie w konkretny framework czy bibliotekę.
edytowany 1x, ostatnio: fastis
- Rejestracja:ponad 11 lat
- Ostatnio:dzień
- Postów:1205
2
Nie wiem, czy devops powinien mieć portfolio. Równie dobrze możesz zapytać, co admin powinien mieć w portfolio. Jeśli już koniecznie chcesz takie portfolio przygotować, to mógłby to być jakiś config do deploymentu apki/apek, konfiguracja CI/CD, Twoja własna konfiguracja systemowa, jakieś uniwersalne pluginy/skrypty, które napisałeś, aby ułatwić sobie i innym pracę, jakieś programiki w go/pythonie/bashu, które przydają się na co dzień itd.
- Rejestracja:ponad 7 lat
- Ostatnio:około 10 godzin
1
Ja też nie znam takiego profilu, ale wydaje się to bardzo sensowny temat, by wyróżnić się spośród innych kandydatów na takie stanowisko. Może to jakieś ekstremum, ale ja bym na przykład zakodował narzędzie do CI/CD, spinające różne technologie jak Jenkins, Docker, Python. Pewnie na produkcji nikt by tego nie chciał używać, ale pokazywałoby, że się rozumie proces CI/CD.
A co to ten CI/CD?
Continuous Integration/Continuous Delivery
Ja tam jak coś rozumiem to tłumaczę od a do z. Tak żeby nie było niedomówień.
gówniane te opisy w necie
- Rejestracja:około 11 lat
- Ostatnio:około 4 godziny
- Postów:8407
0
wiciu napisał(a):
to mógłby to być jakiś config do deploymentu apki/apek, konfiguracja CI/CD, Twoja własna konfiguracja systemowa, jakieś uniwersalne pluginy/skrypty, które napisałeś, aby ułatwić sobie i innym pracę, jakieś programiki w go/pythonie/bashu, które przydają się na co dzień itd.
A potem zaraz będzie wysyp ludzi, którzy będą robić portfolio na devopsa i na siłę będą wrzucać na GH konfigi w YAMLu, które w zasadzie nie są aż tak dużą filozofią, żeby się tym chwalić jako dowodem swojej wiedzy (nawiasem mówiąc ChatGPT też umie taki konfig wygenerować) xD
Tak samo jak ludzie wrzucą kod helloworldów i tutoriali z neta chwaląc się tym jako nie wiadomo jakimi projektami xD. Napisałem w pierwszym zdaniu, że nie wiem, czy to w ogóle ma jakikolwiek sens, ale dałem OPowi jakąś propozycję, bo zawsze jest to jakaś forma edukacji co może być na plus : P.
- Rejestracja:ponad 5 lat
- Ostatnio:około 4 godziny
- Postów:853
1
Zacznij od zrobienia prostej apki, a później zrób w github actions pipeline'y, które będą budowały paczkę z tej aplikacji i jeszcze w dodatkowym kroku ta paczka jest wrzucana do dockera. Jak to zrobisz to przyjdź po więcej tipów.
Pomysł z wrzuceniem swoich dotfile'ów na GH też jest spoko.
- Rejestracja:ponad 2 lata
- Ostatnio:około 2 lata
- Postów:13
2
LukeJL napisał(a):
wiciu napisał(a):
to mógłby to być jakiś config do deploymentu apki/apek, konfiguracja CI/CD, Twoja własna konfiguracja systemowa, jakieś uniwersalne pluginy/skrypty, które napisałeś, aby ułatwić sobie i innym pracę, jakieś programiki w go/pythonie/bashu, które przydają się na co dzień itd.
A potem zaraz będzie wysyp ludzi, którzy będą robić portfolio na devopsa i na siłę będą wrzucać na GH konfigi w YAMLu, które w zasadzie nie są aż tak dużą filozofią, żeby się tym chwalić jako dowodem swojej wiedzy (nawiasem mówiąc ChatGPT też umie taki konfig wygenerować) xD
Ja zauważyłem jako programista już w 2 firmie z kolei że proste rzeczy DevOpsowe jak stawianie infry w Terraform, deploymenty K8S zleca się już programistom w Javie. Np. od trzech lat już jako Java Developer robię także rzeczy DevOpsowe i zauważam tendencje do tego aby zlecać proste DevOpsowe rzeczy programistom. Np. robię w korpo ale jestem odpowiedzialny za cały "life-cycle" aplikacji.
edytowany 1x, ostatnio: fastis
Zobacz pozostałe 12 komentarzy
Scala?
Ale co Scala? W Scali pisanie na Androida nie ma sensu ze względu na specyfikę tej technologii, nie jest to język pure functional, w javie też można pisać funkcyjnie, projekty scalowe i tak często korzystają z javowych bibliotek. W javie jest więcej kodu, ale przynajmniej wiadomo, o co chodzi. Jestem zwolennikiem dłuższego kodu explicit, niż krótszego implicit, w którym się trzeba domyślać o co chodzi. Z pragmatycznego punktu widzenia, Scala nie daje żadnych benefitów poza składnią. Scala to ciekawa technologia, ale Java jest bardziej praktyczna na serwery i na mobile.
Np. z takiej Akki można też korzystać w Javie. Dodatkowo, jak już napiszemy projekty w tej Scali, to potem nie będziemy mogli znaleźć programistów do projektu, a jak już jakichś znajdziemy, bo będą oni wołali maksymalne stawki xD. Nie wiem, czy istnieje w ogóle taki byt jak junior scala developer, co tylko potwierdza tezę z wcześniejszych zdań.
No ja seniorem na pewno nie jestem xD. Scala w kontekście fajnego języka i podważa większość punktów, które wypominałeś (nawet wykorzystuje to samo IDE). Argument że "nie mogę w niej robić nic na androida" mnie mało przekonuje, bo wcześniej nie mówiłeś o tym, co ma w języku być klepane, tylko o tym jaki jest język sam w sobie :p. I nie musisz w niej pisać nawet zbyt funkcyjnie. Może być po prostu bardziej przejrzystą Javą. Nie trzeba sobie mózgu zweglac dziwnym paradygmatem żeby coś z niej wyciągnąć :)
Może kiedyś przysiądę porządniej do tej Scali, bo na razie za słabo znam ten język, żeby mieć lepszą opinię wyrobioną, a na codzień stety/niestety mam sporo nowych tematów do opanowania związanych z pracą, które znam tak sobie, więc już na Scalę brakuje mi slotów do nauki na ten moment : P.
- Rejestracja:ponad 6 lat
- Ostatnio:około 17 godzin
- Postów:699
3
KamilAdam napisał(a):
Hm, ciekawe pytanie. IMHO devops inżynier to gość co wpada, konfiguruje i wypada . Chociaż zwykle za godzinę trzeba coś nowego konfigurować w projekcie XD
Wiec trudni mi sobie wyobrazić portfolio
To brzmi jak standardowy administrator. Ale w Dev Ops piękne jest to, że każdy rozumie ten termin inaczej. Stąd m.in. posty takie jak OPa. Bo nie jest niespotykanym widzieć wymagania konkretnych umiejętności programistycznych w ofertach wymachujących tym terminem. Czasem się zastanawiam, czy ten termin został wymyślony w wyniku zmowy firm zajmujących się HR celem sztucznego powiększenia puli kandydatów bez odgórnego wyznaczania łam co ten termin ma oznaczać – w myśl zasady "w rekrutacji już się zrobi odsiew, przy okazji może ktoś będzie pasował do innych projektów innych klientów".
- Rejestracja:około 9 lat
- Ostatnio:około 8 godzin
- Postów:5108
3
Czasem się zastanawiam, czy ten termin został wymyślony w wyniku zmowy firm zajmujących się HR celem sztucznego powiększenia puli kandydatów bez odgórnego wyznaczania łam co ten termin ma oznaczać – w myśl zasady "w rekrutacji już się zrobi odsiew, przy okazji może ktoś będzie pasował do innych projektów innych klientów".
Ja obstawiałem że DevOps wymyślili Admini aby podbić sobie stawki :D
Albo Admini którzy nauczyli się programować i w końcu porządnie zautomatyzowali swoją pracę (i podbili stawki)
edytowany 2x, ostatnio: WeiXiao
a programiści dalej klepią na dokręconym sprincie :D
- Rejestracja:ponad 9 lat
- Ostatnio:około 16 godzin
- Postów:104
4
Jestem devOpsem z 2 letnim doświadczeniem, przekrój narzędzi jest ogromny
np. z mojej perspektywy używane narzędzia w aktualnej pracy: linuxy (bash/zsh ubuntu i redhat), ansible, molecule, networking (TCP, podstawy komendy nslookup, ping, tracerout), python, docker, docker-compose, k8c, jenkins, AWS, grafana, prometheus, exportery. Nie mam żadnego portffolio, więc linka Ci nie wyślę. Ogólnie jako devOps bronię się umiejętnościami podczas rozmów kwalifikicyjnych, jak i również podejściem do problemów.
Gdybym chciał tworzyć portfolio to próbowałbym spiąć te wszystkie rozwiązania. Z realnych problemów bierzesz przykładową appke:
- Konfigurujesz serwis jenkinsowy, git (gerrit, bitbucket) w oparciu o docker; docker-compose (jak chcesz zabłysnąć tworzysz w oparciu o kubernetesa)
- Tworzysz testowe repo i robisz 1 np. branch master, 2 features
- Następnie Tworzysz webhooka do sewisu jenkinsowego + joba w jenkinsie typu multibranch (Jenkinsfile obsługujące rządania w zależności od master/feature, które buduje + testuje appke)
- Stawiasz grafane + prometheusa + exportery, aby monitorować cały system
- Kolejny wyższy level konfiguracja wszystkich kroków powyżej w oparciu o Ansible
- Opierasz Twoje rozwiązanie o clouda (np. AWS)
Myślę że na juniora opanowanie 4 kroków jest wystarczające. Jednak piąty krok łatwo udokumentować rozwiązanie i pokazać, że rozumiesz głeboko co się dzieje.
edytowany 2x, ostatnio: loki121212
Zobacz pozostałe 4 komentarze
DevOps nie jest łatwą branżą do wejścia, dużo technologii :)
I tu sie pojawia pytanie, po co Jenkins skoro mamy Pipeliny w Gitlabie albo worflow w Githubie?
Duża ilość firm wciąż używa Jenkinsa - w szczególności te związane ze sprzętem. Czy pipeline w Gitlabie są dostępne dla darmowej wersji? Bo wiem, że w poprzedniej mojej firmie nie chcieli używać płatnej wersji i dlatego spinano gitlaba z Jenkinsem.
Zalezy od wielkosci projektu. Wiem ze firmy tak robia. (moze miec to sens jesli np. ze wzgledow security, nie chcemy by pipeline mial dostep bezposrednio do produkcji, wtedy mozna tez uzyc Jenkinsa jako kroku posredniego). Nie mniej, jak sie ogarnie prace z pipelinemai to Jenkins wydaje sie rozwiazaniem z poprzedniej epoki, w szczegolnosci jesli chcemy Infrastructure as code.
Tak ma to również sens, gdy projekty są duże i mają bardzo specyficzne implementacje np. testów, czy różne rodzaje targetów, których wywołanie jest wymagane z poziomu Pipeline (mieliśmy to przesadnie skomplikowane). Ale jak projekt jest dobrze zaimplementowany, to zgadzam się, że nie warto kombinować i lepiej używać rozwiązań Infrastructure as code np. pipelininy w Gitlabie.
- Rejestracja:ponad 9 lat
- Ostatnio:3 miesiące
- Postów:2787
3
Skonfigurować system na AWS, podpiąć do niego swoją kartę, zapomnieć haseł do konta AWSowego i co miesiąc płacić ze swojej karty, pilnując żeby cały czas na niej coś było (bo w przypadku zamknięcia konta, wjedzie komornik z AWSa).
wjedzie komornik z AWSa). Chyba windykacja kolego :)
- Rejestracja:ponad 2 lata
- Ostatnio:około miesiąc
- Postów:5
1
Niestety termin DevOps znaczy wszystko i nic, a w większości przypadków jest używany niepoprawnie. Finalnie sprowadza się to do "software engineer who can build and manage infrastructure" albo "system administrators who can write good enough code". Innymi słowy, chciałbym wierzyć, że osoby pracujące na takich stanowiskach mają doświadczenie w zarządzaniu infrastrukturą, budowaniem infrastruktur oraz tworzeniem oprogramowania.
- Rejestracja:około 17 lat
- Ostatnio:około 10 godzin
- Lokalizacja:Wrocław
2
fastis napisał(a):
Ja zauważyłem jako programista już w 2 firmie z kolei że proste rzeczy DevOpsowe jak stawianie infry w Terraform, deploymenty K8S zleca się już programistom w Javie. Np. od trzech lat już jako Java Developer robię także rzeczy DevOpsowe i zauważam tendencje do tego aby zlecać proste DevOpsowe rzeczy programistom. Np. robię w korpo ale jestem odpowiedzialny za cały "life-cycle" aplikacji.
I to jest dość oczywiste i normalne, że "proste rzeczy devopsowe" robi programista, i tak było od początku tego sposobu pracy.
Jeśli programista nie utrzymuje softu, który napisał, to nie może być mowy o żadnym devopsie.
1a2b3c4d5e napisał(a):
Ja obstawiałem że DevOps wymyślili Admini aby podbić sobie stawki :D
Albo Admini którzy nauczyli się programować i w końcu porządnie zautomatyzowali swoją pracę (i podbili stawki)
Wymyślili mądrzy ludzie, którzy chcieli usunąć patologię polegającą na tym, że najpierw jedna banda piwniczaków, która nigdy nie widziała działającego softu, ma taki stworzyć, a potem druga banda piwniczaków ma ten soft wdrożyć/zainstalować/utrzymywać.
Niestety, ani większość firm, ani większość programistów, nie dojrzała do rozwiązań ułatwiających życie.
edytowany 1x, ostatnio: somekind
Zobacz pozostałe 7 komentarzy
ale co mnie obchodzą twórcy tego podejścia? to że oni widzą to inaczej niż jest, wcale nie zmienia tego jak jest :D
xD
czyżby koncept że coś mogło być zaprojektowane z inną myślą niż jest używane jest zbyt ciezki?
xDDDDDD DevOps został przemyślany i jest używany w sposób zgodny z założeniami w organizacjach, które to podejście rozumieją. To, że 95% firm na rynku tej prostej koncepcji nie umie prawidłowo skopiować i zastosować u siebie, nie zmienia definicji. To jak z piciem denaturatu - to, że to robisz, nie czyni go produktem spożywczym.
@somekind: devopsy które ja widziałem skupiały się na infrze, automatyzacji i uproszczeniu procesów, co jest jak najbardziej spójne z pryncypiami twojego "devopsu" -
It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. three computer science researchers from the CSIRO and the Software Engineering Institute—suggested defining DevOps as "a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality
- Rejestracja:około 10 lat
- Ostatnio:około 2 lata
- Lokalizacja:Chorzów
- Postów:1670
1
Na początku zadaj sobie pytanie czy robisz to dla potencjalnych klientów / działów IT, z którymi będziesz współpracował czy dla "dziuniek" z HR'ów.
W drugim przypadku z osób potencjalnie zainteresowanych współpracą z Tobą i tak nikt nic nie zrozumie z tego co w tym portfolio umieścisz a dla pierwszych prawie niemożliwe umieścić coś sensownego.
Dlatego zrób wypasione graficznie jakieś latające sygnały po sieci niech miga i lata a do tego w kilku punktach opisz wybrane technologie, których używasz i przykłady "wdrożeń" / "zrealizowanych zadań".
A jak portfolio będzie ładnie i wypasione to i u front-end'owców szacun będzie :-)
edytowany 2x, ostatnio: katakrowa