IT Industrija
🔥 Najčitanije
🔥 Najčitanije
Više od godinu dana sam u timu u kome se u potpunosti pridržavamo principa agilnog razvoja softvera koristeći Scrum kao šablon, čime sam ja u potpunosti oduševljen. Agile/Scrum su prilično dobro pokriveni u online literaturi, međutim postoji još jedan bitan pokret koji negde proizilazi iz Scrum-a kao njegova glavna podrška, a o kome se vrlo malo piše na ovim prostorima. U pitanju je DevOps, metodologija koja je inicijalno nastala spajanjem dve reči: Development i Operations, ali koja suštinski obuhvata mnogo više.
S obzirom da se u poslednje vreme baš zanimam za čitavu oblast i da sam pritom i sam bio zbunjen oko toga šta tačno predstavlja ovaj termin, reših da svoja saznanja podelim sa vama.
Šta je DevOps?
U našem timu pored frontend/backend developera i testera, postoje i ljudi koji su na poziciji DevOps inženjera i zbog toga je moja prva pomisao, kada sam ušao u tim, bila da je DevOps zanimanje. Iako i to ima potpunog smisla, kao što sam u uvodu spomenuo, na DevOps se pre svega posmatra kao na metodu razvoja softvera koja je svoj naziv dobila kombinacijom dva zanimanja Development i (IT) Operations (kod nas mnogo popularniji termin – administracija sistema) i koja kao jedan od svojih ciljeva ima poboljšanje komunikacije i kolaboracije između programera i sistem administratora.
Stvar je u tome da u agilnom razvoju programeri veoma često komituju svoj kod, nekoliko puta dnevno, tražeći učestale build-ove, dodatna konfigurisanja okruženja i testiranja što je, sa druge strane, veoma često protiv volje sistem administratora jer potencijalno dovodi do konfliktnog, nestabilnog koda ili čak čitavog sistema u smislu pada servera nakon deployment-a i slično. Iz ovog razloga je i nastao DevOps – da međusobno približi i ujedini sve koji učestvuju u procesu razvoja i deployment-a, ali ne samo sistem administratore i programere, već i testere i krajnje korisnike u jedinstven i automatizovan proces razvoja kvalitetnog softvera, pri čemu čitav sistem mora ostati stabilan.
Da bi se ovo postiglo, postoje neke osnovne prakse koje DevOps usvaja i koje želim da objasnim jer su na prvi pogled veoma nejasne, a sa druge strane jako popularne u novijoj literaturi. U pitanju su: automatizacija, kontinuirana integracija (continuous integration),kontinuirana isporuka (continuous delivery), kontinuirano testiranje (continuous testing) i monitoring. Voleo bih da napomenem da ovo nije neka definitivna lista – kada biste pitali više ljudi, verovatno biste dobili različite odgovore, međutim ovo spisak praksi na koji često nailazim i zaista ih primećujem u svom timu.
Automatizacija
DevOps se u potpunosti oslanja na automatizaciju i alate koji omogućavaju njenu realizaciju. Ukoliko postoje zadaci koji se obavljaju često, na isti način i daju identične rezultate, onda nema razloga gubiti vreme i obavljati ih ručno svaki put. Na taj način se štedi vreme, ali i izbegava moguća ljudska greška.
Kada je development u pitanju, ima puno prostora za automatizaciju. Podsetimo se, ponovo, prethodnog članka u kome sam pisao o Vagrant-u kao alatu za brzo i jednostavno podešavanje development okruženja. Od izuzetne je vrednosti za svakog programera da dobije gotov image sa preinstaliranim sistemom i svim neophodnim komponentama koje će mu dozvoliti da se u roku od 15 minuta fokusira na development.
Pored toga, jedan od alata koji je defacto standard među DevOps inženjerima je Jenkins – alat koji omogućava kreiranje takozvanih job-ova za kontinuiranu integraciju, kontinuiranu isporuku, kontinuirano testiranje i slično. Iako ću o svim ovim tačkama pisati u nastavku, želim samo da napomenem da je veoma česta praksa u današnjim timovima da se na svaki push na source control sistemu automatski pokrene build na definisanom okruženju (QA/UAT itd). Neke druge kompanije rade buildove ređe, jednom u 6h, jednom dnevno ili kao mi na primer, pokreću ručno kada je dovoljan broj taskova rešen, te QA može da otpočne sa testiranjem. Takođe, pre samog build-a ne bi bilo loše proveriti da li se kod kompajlira uopšte, ili da li je u skladu sa coding standardima u firmi (recimo, da li postoji linija duža od xxx karaktera, da li su promenljive i funkcije nazivane adekvatno i sl).
Kontinuirana integracija (Continuous Integration)
Ovo je jedna od najbitnijih praksi u DevOps-u, koja suštinski znači: što češće komitovati, push-ovati i merge-ovati kod na kome radimo. Za svaki zadatak (feature) developer kreira zasebni, takozvani feature branch, koji se nakon željenih izmena i najosnovnijih testiranja sa njegove strane pre svega push-uje na remote repozitorijum, kako bi branch bio vidljiv i ostalima, ali i merge-uje u neki veći codebase (po poznatom git branching modelu koji se danas najčešće primenjuje, to obično bude develop branch).
Ovaj ciklus se u agilnom razvoju ponavlja i po nekoliko puta dnevno, naravno – sve u zavisnosti od obimnosti posla u konkretnom zadatku. To zapravo znači da svaki developer treba aktivno da prati šta ostali u timu rade kako bi mogao da bez većih problema integriše svoj kod sa ostalima, ali sa druge strane, ovaj pristup značajno poboljšava komunikaciju u timu i omogućava da se bagovit kod identifikuje i ispravi najranije moguće. Možete misliti koliko problema može biti ako svaki developer radi mesec dana na svojim zadacima i tek onda, pred kraj sprint-a merge-uje svoj kod u glavni codebase.
Kontinuirano testiranje
Kako to već Scrum nalaže, pred release je uvek bar jedna sedmica predviđena za testiranje aktivnih feature-a. Međutim, kao što je to slučaj i sa prethodnim tezama, testiranje treba biti kontinuirana saradnja između developera i QA inženjera. Takođe, pod testiranjem u DevOps konketsktu ne podrazumevamo klasično klik-klik testiranje – automatizacija je ključ. Naravno, nema ništa pogrešno u tome, svaki tim mora imati QA ljude koji će kontinuirano prolaziti kroz aplikaciju i utvrditi da se ona ponaša u skladu sa zahtevima.
Ipak, novija prakse podrazumevaju i test-driven development, odnosno postojanje automatizovanih testova koji se takođe pokreću kroz neki alat, npr Jenkins i to obično nakon svakog build-a. Na taj način je zgodnije odmah utvrditi kritični feature i eliminisati ga iz codebase-a pre nego što dođe do većih šteta. Sa druge strane, ne testiraju se samo novi feature-i, tu su i load, stress, verovatno i neki drugi testovi koji će na automatizovani način pokazati kako se aplikacija ponaša kad je izložena određenim okolnostima.
Kontinuirana isporuka (Continuous Delivery)
Ova praksa se nadovezuje na prethodne dve i predstavlja deployment stabilnog i potpuno testiranog koda na produkciju, s tim što se gleda da to bude u što kraćim vremenskim intervalima. Iskreno, nisam siguran koliki vremenski period bi trebalo da bude između dva deployment-a – to najčešće zavisi od release plana pojedinačnog proizvoda. Konkretno, u mom timu deployment se dešava na kraju svakog sprint-a, što znači jednom mesečno ili jednom u mesec i po dana.
Monitoring
Nakon deployment-a i puštanja u rad, sledeći korak je monitoring. Naravno, sve se svodi ponovo na automatizaciju i alate – vaše custom alate, open-source alate, proprietary alate, potpuno je nebitno. Suština je da morate konstantno nadgledati rad na produkciji i imati merljive rezultate koje možete iskoristiti kako biste sprečili mnoge neželjene stvari, ili unapredili okruženje u narednom ciklusu. Međutim, monitoring nije samo na leđima Ops tima – svaki član tima bi mogao da nadgleda produkciono okruženje i da na osnovu prikazanog zaključi kako se okruženje ponaša i šta radi u tom trenutku.
Primera radi, ukoliko je u pitanju web aplikacija, vi možete jednostavno pratiti rad svih servera koji su trenutno aktivni (mi koristimo Graphite za iscrtavanje grafika, Carbon i StatsD za prikupljanje/sistematizaciju podataka) i po potrebi pokretati scale-up/down da biste očuvali željenu responzivnost uz minimalne troškove. Sa druge strane, uvek treba obezbediti alerting sisteme koji će obavestiti Ops tim kada dođe do zastoja ili problema na ključnim tačkama vašeg sistema (npr detekcija dead lokova i sl).
Zaključak
Ovaj tekst, kada se malo osvrnem, predstavlja lep uvod u nove termine i prakse koje nas pre ili kasnije čekaju negde iza ćoška kada se upustimo u profesionalni timski rad na konkretnom proizvodu ili usluzi. Meni je cela oblast jako interesantna i trudiću se da u najskorije vreme napišem novi tekst koji će zapravo predstavljati praktičnu simulaciju gore navedenog – iskoristiću Jenkins i napraviti jedan job koji će pokupiti kod sa nekog git repozitorijuma i odraditi build na mom development okruženju. Po završetku će pokrenuti jednostavne testove i ukoliko je sve u redu, poslati mi mail da je build uspešno završen i recimo obrisati cache.
Do tad, ko voli najtoplije preporučujem NewRelic knjižicu koja me je zapravo i inspirisala na ovaj post: Navigating DevOps. Takođe, preporučujem i blog The Agile Admin jer sam na njemu našao pregršt dobrih tekstova (posebno ističem What is DevOps). Za one koji žele još više, manje-više preporučujem i knjigu koju sam nedavno pročitao, Continuous delivery and DevOps: A Quickstart Guide – zapravo, očekivao sam više od ove knjige, ali se na kraju ispostavilo da obrađuje više konceptualno celu oblast, uz gotovo ni malo praktičnih primera i preporuka.
Hvala Milanu na dozvoli za prenošenje njegovog članka, a pozivamo sve vas da se prijavite za Devops meetup 3. marta u Domu Omladine od 18h.