Kuhu nende teadmistega minna, mida projektis teha ja kui palju teenida, mida intervjuul öelda ja küsida - ütleb Express 42 juhtivpartner ja autor Aleksandr Titov .
Tere! Kuigi mõiste DevOps on eksisteerinud alates 2009. aastast, pole vene kogukonnas siiani üksmeelt. Olete ilmselt märganud, et mõned peavad DevOpsi erialaks, teised peavad seda filosoofiaks ja teised peavad seda terminit tehnoloogiate kogumiks. Olen koos juba korduvalt esinenud selle suuna arendamise kohta, nii et ma ei hakka selles artiklis üksikasjalikult käsitlema. Lubage mul lihtsalt öelda, et Express 42-s lisame sellesse järgmise:
DevOps on spetsiifiline metoodika, digitaalse toote loomise kultuur, mil tootmises osalevad kõik meeskonna spetsialistid.
Klassikalises ettevõttearenduses käib kõik järjestikku: programmeerimine, testimine ja alles siis opereerimine ning selle protsessi kiirus ideest tootmiseni on 3 kuud. See on digitaalsete toodete jaoks ülemaailmne probleem, sest klientidelt pole võimalik kiiresti tagasisidet saada.
DevOpsis on tööriistad ja lähenemisviisid loodud selleks, et tagada arendus-, testimis- ja toimimisprotsesside samaaegne käitamine.
Mis sellest lähenemisest järeldub?
- Sa ei saa palgata mõnda “inseneri”, kes tuleb ja lahendab kõik tootmisega seotud probleemid. Kogu meeskond peab tehnikat rakendama.
- DevOps EI OLE järgmine süsteemiadministraatori vorm, millele uuendada. "DevOpsi insener" kõlab umbes samamoodi kui "Agile arendaja".
- Kui meeskond kasutab Kubernetes, Ansible, Prometheus, Mesosphere ja Docker, ei tähenda see, et seal on DevOpsi praktikad rakendatud.
Elu pärast DevOpsi pole kunagi endine
DevOps lähenemine on ennekõike teistsugune mõtteviis, arusaam arengust kui tervikust ja oma kohast protsessis. Jagasime oma veebikursuse 2 plokki:
1. Enesemääramine
Esiteks uurime üksikasjalikult DevOpsi lähenemisviisi olemust ja õpilased avastavad meeskonnas uusi rolle, näevad, milline neist reageerib rohkem, ja otsustavad ise, millises suunas areneda.
2. Vahendid ja tavad
Õpilased valdavad spetsiifilisi tehnoloogiaid DevOps meetodi vaatenurgast.
DevOpsi tööriistu saab kasutada nii DevOpsi lähenemisviisis kui ka klassikalises arenduses. Kõige ilmsem näide oleks Ansible konfiguratsioonihaldustööriista kasutamine. See loodi ja loodi DevOpsi praktika "Infrastructure as Code" rakendamiseks, mis tähendab, et kirjeldatakse süsteemi erinevaid olekuid alates operatsioonisüsteemi sätetest kuni rakendustarkvarani. Kirjeldus on jagatud kihtideks ja võimaldab hallata keerulist, pidevalt muutuvat konfiguratsiooni. Kuid insenerid kasutavad sageli Ansible'i bash-skriptide käivitamiseks mitmes masinas. See pole halb ega hea, kuid peate mõistma, et Ansible'i olemasolu ei taga DevOpsi olemasolu ettevõttes.
Oleme protsessis Sukeldute kuulsa Redditiga sarnase rakenduse arendamise protsessi, alustades selle monoliitsest versioonist, liikudes samm-sammult mikroteenusteni. Samm-sammult omandame uued tööriistad: Git, Ansible, Gitlab ning lõpetame Kubernetese ja Prometheusega.
Praktikate osas lähtume kolme DevOpsi käsiraamatus kirjeldatud tee taktikast - pidev edastamise praktikad, tagasiside praktikad ning kogu kursuse sisuks on pidev õppimise praktika koos oma süsteemiga.
Mida need teadmised igale spetsialistile annavad?
Süsteemiadministraatoritele
Praktika võimaldab teil minna haldusest eemale pideva tarnetorustiku ja taristuplatvormi loomise suunas tarkvara tarnimiseks. Asi on selles, et ta loob toote – arendajatele mõeldud taristuplatvormi, mis aitab neil muudatused kiiresti tootmisse viia.
Varem olid süsteemiadministraatorid viimane bastion, pärast mida läheb kõik tootmisse. Ja põhiliselt tegeleti pideva tuletõrjega – selle valguses on üsna raske süveneda äri vajadustesse, mõelda tootele ja kasule kasutajale.
Tänu DevOpsi meetodile mõtlemine muutub. Süsteemiadministraator mõistab, kuidas konfiguratsiooni koodiks tõlkida, millised tavad selleks eksisteerivad.
See on oluline, sest ettevõtted mõistavad üha enam, et neil pole vaja ainult kõike automatiseerida, s.t. mida vana kooli süsteemiadministraatorid olid sisuliselt harjunud tegema, kes lisaks sellele suhtlesid vähe ega teavitanud meeskonda kõigist tehtud muudatustest. Nüüd otsivad meeskonnad neid, kes hakkavad sisemise taristutoote tootjaks ja aitavad eraldatud protsessid üheks ühendada.
Arendajatele
Arendaja lõpetab mõtlemise ainult algoritmides. Ta omandab taristuga töötamise oskuse, maastiku arhitektuurse teadvustamise oskuse. Selline arendaja mõistab, kuidas rakendus töötab, kuidas see läbib pideva tarnekonveieri, kuidas seda jälgida, kuidas seda registreerida, et see kliendile kasulik oleks. Selle tulemusena võimaldavad kõik need teadmised kirjutada vastavat koodi.
Testijatele
Testimine on juba ammu liikunud automaatrežiimile, me kõik ütleme, et paljusid teste ei tohiks teha, vaid kirjutada :) Testimine saab osaks kogu teie toote tarnetorustikust. Testija ei pea mitte ainult õppima koodi kirjutama, vaid ka mõistma, kuidas seda integreerida pidevatesse edastamissüsteemidesse, kuidas saada koodilt tagasisidet edastamise kõigil etappidel ja kuidas testimist pidevalt täiustada, et tuvastada vigu. võimalikult vara.
Nii selgub, et kõik kolm etappi toimuvad samaaegselt. Näiteks võib see välja näha selline:
Arendaja kirjutab koodi, kirjutab kohe selle jaoks testid ja kirjeldab käivitatava koodi jaoks dokkeri konteinerit. Samuti kirjeldab see koheselt jälgimist, mis jälgib selle teenuse toimimist tootmises, ja teeb seda kõike.
Kui pidev integreerimine algab, käivad protsessid samaaegselt. Teenus käivitub ja on konfigureeritud. Samal ajal käivitub dokkeri konteiner ja kontrollitakse, kas see töötab. Samal ajal läheb kogu info logisüsteemi. Ja nii edasi igal arendusetapil – see osutub tõeliseks süsteemiadministraatorite, arendajate ja testijate meeskonnatööks.
Uurisin DevOpsi, mis edasi?
Nagu teate, pole põllul olev sõdalane. Kui teie ettevõte seda meetodit ei kasuta, jäävad omandatud oskused jõude. Ja pärast DevOpsi lähenemisviisidega tutvumist ei taha te tõenäoliselt olla ettevõtte arengus hammasratas. Võib olla üks erand: olete meeskonnas süsteemiadministraator ja saate kõik protsessid uuel viisil ümber ehitada. Siinkohal tasub lisada, et ettevõtteid, kes seda lähenemist kasutavad, on palju ja neid sulgemine ei puuduta ja nad otsivad spetsialiste. Sest DevOps tegeleb veebitoodete loomisega.
Ja nüüd headest asjadest: DevOpsi tavade ja tööriistade valdamine on ligikaudu +30% teie väärtusest tööturul. Palgad algavad 140 tuhandest rublast, kuid selle määrab loomulikult teie põhieriala ja funktsionaalsus.
Vaadata saab “taristukeskse” märgistusega vabu töökohti, kus on testimise automatiseerimine, pilvetehnoloogiaid kasutavate mikroteenuste rakenduste arendus, taristuinseneride vabad ametikohad ja kõikvõimalikud viited DevOpsile. Pidage vaid meeles, et iga ettevõte tähendab selle definitsiooni all midagi erinevat – lugege kirjeldust hoolikalt läbi.
Meie kursuse käivitamisel sain aru – paljud inimesed pärast kursust langevad DevOpsi inseneri lõksu. Nad leiavad vaba töökoha ülalmainitud tiitliga, saavad hea pakkumise ning tulevad siis tööle ja mõistavad, et peavad Jenkinsis üleval pidama kolmeleheküljelist bash-skripti. Kus on Kubernetes, ChatOps, Canary väljaanded ja kõik see? Aga pole midagi, sest ettevõte ei vaja DevOpsi kui metoodikat, vaid kasutab üksikuid uuendusi.
See on põhjust ettevõttelt intensiivselt uurida, kuidas tarkvara tarneprotsess toimib, tehnoloogiapinn ja milliseid kohustusi täitma hakkate.
Kui tööandja vastab teie küsimustele abstraktselt, justkui raamatust, ilma üksikasjadeta, siis tõenäoliselt DevOpsi protsessi ettevõttes veel ei ole, kuid see pole põhjus keeldumiseks, uurige ettevõtet ja selle tooteid, kas Internetis on teenused, mida ettevõte ise arendab, mobiilirakendused , tooteideed.
Kui jah, siis selgitage, kas peate nende süsteemidega otse töötama või on võimalik nende teenuste meeskondadele horisontaalselt liikuda, näidates samal ajal häid tulemusi DevOpsi praktikas. Kui jah, siis tasub minna ja olla aktiivne ja kasulik ning meie kursuse läbimisel on viimane garanteeritud.
Oluline on märkida, et Devopsi praktikud omandavad tõelise väärtuse ainult arendus-/haldus-/testimiskogemusega. Ainult sel juhul ei ole teadmised abstraktsed, vaid rikastavad spetsialisti (igas mõttes). Seetõttu on idee "õppida DevOps nullist" umbes sama, kui õppida "nullist objektiive kasutama", kui te pole kunagi kaamerat käes hoidnud ega võtet suunanud. Et aidata teil otsustada, kas kursus teile sobib, oleme teinud sisseastumiskatse, mis kontrollib teie piisavat teadmiste taset.
Ma arvan, et üks nippe — et koolituse käigus otsustab iga õpilane ise, millises suunas ta areneda soovib. Tihti näeme üleminekuid, kui arendajast saab taristuinsener ja administraator mõistab, et teda huvitab koodi kirjutamine – siis õpib ta keelt edasi ja täiendab seda omandatud DevOpsi oskustega. Seetõttu ootame eelkõige neid, kes tunnevad, et nende karjäär on takerdunud ristteele. Kursus algab 28. mail, kuid liituda saab 2 nädalat peale tundide algust. Saate vaadata programmi ja sooritada testi . Kohtumiseni OTUS!
Allikas: www.habr.com