DevOps është bërë një temë shumë e njohur gjatë viteve të fundit. Shumë njerëz ëndërrojnë t'i bashkohen, por, siç tregon praktika, shpesh vetëm për shkak të nivelit të pagave.
Disa njerëz rendisin DevOps në rezymenë e tyre, megjithëse jo gjithmonë e dinë ose e kuptojnë thelbin e termit. Disa njerëz mendojnë se pasi të keni studiuar Ansible, GitLab, Jenkins, Terraform dhe të ngjashme (lista mund të vazhdohet sipas shijes tuaj), do të bëheni menjëherë një "devopsist". Kjo, natyrisht, nuk është e vërtetë.
Vitet e fundit, unë jam përfshirë kryesisht në zbatimin e DevOps në kompani të ndryshme. Para kësaj, ai ka punuar për më shumë se 20 vjet në pozicione duke filluar nga administratori i sistemit deri te drejtor i IT. Aktualisht, inxhinieri kryesor i DevOps në Playgendary.
Kush është DevOps
Ideja për të shkruar një artikull lindi pas një pyetjeje tjetër: "kush është DevOps?" Ende nuk ka një term të përcaktuar se çfarë ose kush është. Disa nga përgjigjet janë tashmë në këtë . Së pari, unë do të nënvizoj pikat kryesore prej tij, dhe më pas do të ndaj vëzhgimet dhe mendimet e mia.
DevOps nuk është një specialist që mund të punësohet, as një grup shërbimesh, dhe as një departament zhvilluesish me inxhinierë.
DevOps është një filozofi dhe metodologji.
Me fjalë të tjera, është një grup praktikash që i ndihmon zhvilluesit të ndërveprojnë në mënyrë aktive me administratorët e sistemit. Domethënë të lidhin dhe integrojnë proceset e punës në njëra-tjetrën.
Me ardhjen e DevOps, struktura dhe rolet e specialistëve mbetën të njëjta (ka zhvillues, ka inxhinierë), por rregullat e ndërveprimit kanë ndryshuar. Kufijtë midis departamenteve janë zbehur.
Qëllimet e DevOps mund të përshkruhen në tre pika:
- Softueri duhet të përditësohet rregullisht.
- Softueri duhet të bëhet shpejt.
- Softueri duhet të vendoset në mënyrë të përshtatshme dhe në një kohë të shkurtër.
Nuk ka asnjë mjet të vetëm për DevOps. Konfigurimi, shpërndarja dhe studimi i disa produkteve nuk do të thotë që DevOps është shfaqur në kompani. Ka shumë mjete dhe të gjitha përdoren në faza të ndryshme, por i shërbejnë një qëllimi të përbashkët.
Dhe kjo është vetëm një pjesë e mjeteve DevOps
Unë kam intervistuar njerëz për pozicionin e inxhinierit DevOps për më shumë se 2 vjet tani dhe kam kuptuar se sa e rëndësishme është të kuptojmë qartë thelbin e termit. Kam grumbulluar përvoja, vëzhgime dhe mendime specifike që dua të ndaj.
Nga përvoja e intervistës, unë shoh foton e mëposhtme: specialistët që e konsiderojnë DevOps një titull pune zakonisht kanë keqkuptime me kolegët.
Kishte një shembull të mrekullueshëm. Një i ri erdhi në një intervistë me shumë fjalë të zgjuara në rezymenë e tij. Në tre punët e tij të fundit, ai kishte 5-6 muaj përvojë. I lashë dy startup sepse ata "nuk u ngritën". Por për kompaninë e tretë, ai tha se askush nuk e kupton atë atje: zhvilluesit shkruajnë kodin në Windows dhe drejtori e detyron këtë kod të "mbështillet" në Docker të rregullt dhe të futet në tubacionin CI/CD. Djali tha shumë gjëra negative për vendin e tij aktual të punës dhe kolegët e tij - thjesht doja të përgjigjesha: "Kështu që ju nuk do të shisni një elefant."
Më pas i bëra një pyetje që është lart në listën time për çdo kandidat.
— Çfarë do të thotë DevOps për ju personalisht?
- Në përgjithësi apo si e perceptoj?
Më interesonte mendimi i tij personal. Ai e njihte teorinë dhe origjinën e termit, por nuk ishte plotësisht dakord me to. Ai besonte se DevOps ishte një titull pune. Këtu qëndron rrënja e problemeve të tij. Si dhe specialistë të tjerë me të njëjtin mendim.
Punëdhënësit, pasi kanë dëgjuar shumë për "magjinë e DevOps", duan të gjejnë një person që do të vijë dhe do të krijojë këtë "magji". Dhe aplikantët nga kategoria "DevOps është një punë" nuk e kuptojnë se me këtë qasje ata nuk do të jenë në gjendje të përmbushin pritshmëritë. Dhe, në përgjithësi, ata shkruan DevOps në rezymenë e tyre sepse është një trend dhe ata paguajnë shumë për të.
Metodologjia dhe filozofia e DevOps
Metodologjia mund të jetë teorike dhe praktike. Në rastin tonë, është i dyti. Siç e përmenda më lart, DevOps është një grup praktikash dhe strategjish të përdorura për të arritur qëllimet e deklaruara. Dhe në secilin rast, në varësi të proceseve të biznesit të kompanisë, mund të ndryshojë ndjeshëm. Që nuk e bën atë më mirë apo më keq.
Metodologjia DevOps është vetëm një mjet për të arritur qëllimet.
Tani për atë që është filozofia e DevOps. Dhe kjo është ndoshta pyetja më e vështirë.
Është mjaft e vështirë të formulosh një përgjigje të shkurtër dhe të përmbledhur, sepse ende nuk është zyrtarizuar. Dhe duke qenë se adhuruesit e filozofisë DevOps janë më të angazhuar në praktikë, thjesht nuk ka kohë për të filozofuar. Megjithatë, ky është një proces shumë i rëndësishëm. Për më tepër, ajo lidhet drejtpërdrejt me aktivitetet inxhinierike. Ekziston edhe një fushë e specializuar e njohurive - .
Nuk kishte një lëndë të tillë në universitetin tim, më duhej të studioja gjithçka vetë duke përdorur materialet që gjeja në vitet '90. Tema është fakultative për arsimin inxhinierik, prandaj edhe mungesa e formalizimit të përgjigjes. Por ata njerëz që janë zhytur seriozisht në DevOps fillojnë të ndiejnë një "shpirt" të caktuar ose "gjithëpërfshirje të pavetëdijshme" të të gjitha proceseve të kompanisë.
Duke përdorur përvojën time, u përpoqa të zyrtarizoja disa nga "postulatat" e kësaj filozofie. Rezultati është si më poshtë:
- DevOps nuk është diçka e pavarur që mund të ndahet në një zonë të veçantë njohurish ose aktiviteti.
- Të gjithë punonjësit e kompanisë duhet të udhëhiqen nga metodologjia DevOps kur planifikojnë aktivitetet e tyre.
- DevOps ndikon në të gjitha proceset brenda një kompanie.
- DevOps ekziston për të reduktuar kostot kohore për çdo proces brenda një kompanie për të siguruar zhvillimin e shërbimeve të saj dhe komoditetin maksimal të klientit.
- DevOps, në gjuhën moderne, është pozicioni proaktiv i çdo punonjësi të kompanisë, që synon të reduktojë kostot e kohës dhe të përmirësojë cilësinë e produkteve të IT përreth nesh.
Mendoj se “postulatat” e mia janë një temë më vete për diskutim. Por tani ka diçka për të ndërtuar.
Çfarë bën DevOps
Fjala kyçe këtu është komunikimi. Ka shumë komunikime, iniciatori i të cilave duhet të jetë pikërisht i njëjti inxhinier DevOps. Pse eshte ajo? Sepse kjo është filozofi dhe metodologji, dhe vetëm atëherë njohuri inxhinierike.
Nuk mund të flas me 100% besim për tregun perëndimor të punës. Por unë di shumë për tregun e DevOps në Rusi. Përveç qindra intervistave, gjatë një viti e gjysmë të kaluar kam marrë pjesë në qindra parashitje teknike për shërbimin "Zbatimi i DevOps" për kompanitë dhe bankat e mëdha ruse.
Në Rusi, DevOps është ende një temë shumë e re, por tashmë në trend. Me sa di unë, vetëm në Moskë mungesa e specialistëve të tillë në vitin 2019 ishte më shumë se 1000 njerëz. Dhe fjala Kubernetes për punëdhënësit është pothuajse si një leckë e kuqe për një dem. Adhuruesit e këtij mjeti janë të gatshëm ta përdorin atë edhe aty ku nuk është i nevojshëm dhe ekonomikisht fitimprurës. Punëdhënësi nuk e kupton gjithmonë se në cilat raste çfarë është më e përshtatshme për t'u përdorur, dhe me vendosjen e duhur, mbajtja e një grupi Kubernetes kushton 2-3 herë më shumë sesa vendosja e një aplikacioni duke përdorur një skemë konvencionale të grupimeve. Përdoreni aty ku ju nevojitet vërtet.
Zbatimi i DevOps është i shtrenjtë për sa i përket parave. Dhe justifikohet vetëm aty ku sjell përfitime ekonomike në fusha të tjera dhe jo më vete.
Inxhinierët e DevOps janë, në fakt, pionierë - janë ata që duhet të jenë të parët që do ta zbatojnë këtë metodologji në kompani dhe do të ndërtojnë procese. Që kjo të jetë e suksesshme, specialisti duhet të ndërveprojë vazhdimisht me punonjësit dhe kolegët e të gjitha niveleve. Siç them zakonisht, të gjithë punonjësit e kompanisë duhet të përfshihen në procesin e zbatimit të DevOps: nga pastruesi deri te CEO. Dhe ky është një parakusht. Nëse anëtari më i ri i ekipit nuk e di dhe nuk kupton se çfarë është DevOps dhe pse kryhen veprime të caktuara organizative, atëherë zbatimi i suksesshëm nuk do të funksionojë.
Gjithashtu, një inxhinier DevOps duhet të përdorë një burim administrativ herë pas here. Për shembull, për të kapërcyer "rezistencën mjedisore" - kur ekipi nuk është gati të pranojë mjetet dhe metodologjinë e DevOps.
Zhvilluesi duhet të shkruajë vetëm kode dhe teste. Për ta bërë këtë, ai nuk ka nevojë për një laptop super të fuqishëm në të cilin do të vendosë dhe do të mbështesë në nivel lokal të gjithë infrastrukturën e projektit. Për shembull, një zhvillues front-end mban të gjithë elementët e aplikacionit në laptopin e tij, duke përfshirë bazën e të dhënave, emulatorin S3 (minio), etj. Kjo do të thotë, ai shpenzon shumë kohë për të mirëmbajtur këtë infrastrukturë lokale dhe lufton i vetëm me të gjitha problemet e një zgjidhjeje të tillë. Në vend të zhvillimit të kodit për pjesën e përparme. Njerëz të tillë mund të jenë shumë rezistent ndaj çdo ndryshimi.
Por ka ekipe që, përkundrazi, janë të lumtur të prezantojnë mjete dhe metoda të reja dhe marrin pjesë aktive në këtë proces. Edhe pse edhe në këtë rast, komunikimi midis inxhinierit DevOps dhe ekipit nuk u anulua.
Kur DevOps nuk është i nevojshëm
Ka situata kur DevOps nuk është i nevojshëm. Ky është një fakt - duhet kuptuar dhe pranuar.
Para së gjithash, kjo vlen për çdo kompani (sidomos bizneset e vogla), kur fitimi i tyre nuk varet drejtpërdrejt nga prania ose mungesa e produkteve të IT-së që ofrojnë shërbime informacioni për klientët. Dhe këtu nuk po flasim për faqen e internetit të kompanisë, qoftë një "kartë biznesi" statike ose me blloqe dinamike të lajmeve, etj.
DevOps kërkohet kur kënaqësia e klientit tuaj dhe dëshira e tij për t'u kthyer përsëri tek ju varen nga disponueshmëria e këtyre shërbimeve të informacionit për ndërveprimin me klientin, cilësia dhe synimi i tyre.
Një shembull i mrekullueshëm është një bankë e njohur. Kompania nuk ka zyra tradicionale të klientëve, qarkullimi i dokumenteve kryhet përmes postës ose korrierëve dhe shumë punonjës punojnë nga shtëpia. Kompania ka pushuar së qeni thjesht një bankë dhe, për mendimin tim, është kthyer në një kompani IT me teknologji të zhvilluara DevOps.
Shumë shembuj dhe leksione të tjera mund të gjenden në regjistrimet e takimeve dhe konferencave tematike. Disa prej tyre i vizitova personalisht - kjo është një përvojë shumë e dobishme për ata që duan të zhvillohen në këtë drejtim. Këtu janë lidhjet me kanalet YouTube me leksione dhe materiale të mira në DevOps:
Tani shikoni biznesin tuaj dhe mendoni për këtë: Sa varet kompania juaj dhe fitimet e saj nga produktet e TI-së për të mundësuar ndërveprimin me klientët?
Nëse kompania juaj shet peshk në një dyqan të vogël dhe i vetmi produkt IT është dy konfigurime 1C: Enterprise (Accounting dhe UNF), atëherë vështirë se ka kuptim të flasim për DevOps.
Nëse punoni në një ndërmarrje të madhe tregtare dhe prodhuese (për shembull, prodhoni pushkë gjuetie), atëherë duhet të mendoni për këtë. Ju mund të merrni iniciativën dhe t'i transmetoni menaxhmentit tuaj perspektivat për zbatimin e DevOps. Epo, dhe në të njëjtën kohë, drejtojeni këtë proces. Një pozicion proaktiv është një nga parimet e rëndësishme të filozofisë DevOps.
Madhësia dhe vëllimi i qarkullimit financiar vjetor nuk është kriteri kryesor për të përcaktuar nëse kompania juaj ka nevojë për DevOps.
Le të imagjinojmë një ndërmarrje të madhe industriale që nuk ndërvepron drejtpërdrejt me klientët. Për shembull, disa prodhues automjetesh dhe kompani të prodhimit të automobilave. Nuk jam i sigurt tani, por nga përvoja ime e kaluar, për shumë vite i gjithë ndërveprimi me klientët bëhej përmes emailit dhe telefonit.
Klientët e tyre janë një listë e kufizuar e tregtarëve të makinave. Dhe secilit i caktohet një specialist nga prodhuesi. I gjithë fluksi i brendshëm i dokumenteve ndodh përmes SAP ERP. Punonjësit e brendshëm janë në thelb klientë të sistemit të informacionit. Por ky IS kontrollohet nga mjetet klasike të menaxhimit të sistemeve të grupimeve. E cila përjashton mundësinë e përdorimit të praktikave DevOps.
Prandaj përfundimi: për ndërmarrje të tilla, zbatimi i DevOps nuk është diçka kritike, nëse kujtojmë qëllimet e metodologjisë që nga fillimi i artikullit. Por nuk e përjashtoj që ata përdorin disa mjete DevOps sot.
Nga ana tjetër, ka shumë kompani të vogla që zhvillojnë softuer duke përdorur metodologjinë, filozofinë, praktikat dhe mjetet e DevOps. Dhe ata besojnë se kostoja e zbatimit të DevOps është kostoja që u lejon atyre të konkurrojnë në mënyrë efektive në tregun e softuerit. Shembuj të kompanive të tilla mund të shihen .
Kriteri kryesor për të kuptuar nëse nevojiten DevOps: çfarë vlere kanë produktet tuaja të IT për kompaninë dhe klientët.
Nëse produkti kryesor i kompanisë që gjeneron fitim është softueri, ju keni nevojë për DevOps. Dhe nuk është aq e rëndësishme nëse fitoni para të vërteta duke përdorur produkte të tjera. Këtu përfshihen edhe dyqanet online ose aplikacionet celulare me lojëra.
Çdo lojë ekziston falë financimit: direkt ose indirekt nga lojtarët. Në Playgendary, ne zhvillojmë lojëra celulare falas me mbi 200 njerëz të përfshirë drejtpërdrejt në krijimin e tyre. Si i përdorim DevOps?
Po, saktësisht e njëjta gjë siç përshkruhet më sipër. Unë komunikoj vazhdimisht me zhvilluesit dhe testuesit dhe kryej trajnime të brendshme për punonjësit mbi metodologjinë dhe mjetet e DevOps.
Tani po përdorim në mënyrë aktive Jenkins si një mjet për tubacionet CI/CD për ekzekutimin e të gjitha tubacioneve të montimit me Unity dhe vendosjen e mëvonshme në App Store dhe Play Market. Më shumë nga paketa klasike e veglave:
- Asana - për menaxhimin e projektit. Integrimi me Jenkins është konfiguruar.
- Google Meet - për takime me video.
- Slack - për komunikime dhe sinjalizime të ndryshme, duke përfshirë njoftimet nga Jenkins.
- Atlassian Confluence - për dokumentacion dhe punë në grup.
Planet tona të menjëhershme përfshijnë prezantimin e analizës statike të kodit duke përdorur SonarQube dhe kryerjen e testimit të automatizuar të UI duke përdorur Seleniumin në fazën e Integrimit të Vazhdueshëm.
Në vend të një përfundimi
Do të doja ta mbyllja me mendimin e mëposhtëm: për t'u bërë një inxhinier shumë i kualifikuar DevOps, është jetike të mësosh se si të komunikosh drejtpërdrejt me njerëzit.
Një inxhinier DevOps është një lojtar ekipi. Dhe asgjë tjetër. Iniciativa në komunikimin me kolegët duhet të vijë nga ai, dhe jo nën ndikimin e disa rrethanave. Një specialist i DevOps duhet të shohë dhe të propozojë zgjidhjen më të mirë për ekipin.
Dhe po, zbatimi i çdo zgjidhjeje do të kërkojë shumë diskutime dhe deri në fund mund të ndryshojë fare. Duke u zhvilluar në mënyrë të pavarur, duke propozuar dhe zbatuar idetë e tij, një person i tillë ka një vlerë në rritje si për ekipin ashtu edhe për punëdhënësin. E cila, në fund të fundit, reflektohet në masën e shpërblimit të tij mujor ose në formën e shpërblimeve shtesë.
Burimi: www.habr.com