Jak powinno wyglądać portfolio przyszłego inżyniera devops? Możecie podać dobre przykłady, repozytoria, profile?
0
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
0
Podpinam się pod pytanie.
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ć
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ę.
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.
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.
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
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.
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.
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".
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)
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.
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).
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.
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.
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 :-)