Znaš onaj momenat u karijeri kad shvatiš da je 30-50% tvog posla moguće automatizovati i da možeš da se isključivo baviš pisanjem koda i ne razmišljaš dalje? Nema razmišljanja o servisima, okruženjima, deploy-ovima, i ostalim … Samo ti, šoljica kafe pored tebe, tvoj kod, commit+push, pull request review (eventualno još jedan klikić na jedno dugmence) i onda opet ti, tvoj kod… Ne znaš? E, pa red je da saznaš.
Ako je agilni razvoj softvera tatko, continuous delivery je sinče. Prosto je, scrum, kanban, extreme programming, šta god da tvoj tim koristi (a sigurno koristi nešto), očekivano je da na 2-3 nedelje imaš novi deploy. A tu je još i gomila okruženja, te razvojno, te QA, te live okruženja, i još gomila raznih stvari o kojima treba da brineš. Pa onda kreću serveri…
I tu dođu dragi nam pipeline-ovi, Docker, Jenkins, Kubernetes i sve ostale fensi alatke koje su toliko tražene u svakom oglasu za posao nowadays.
Prvo da napravimo razliku između pojmova: continuous integration znači da ćeš svaki sitan feature, bugfix i ostale stvari da što ranije (iliti čim je kod gotov, bilda se kako dolikuje i testovi prolaze) da gurneš na master. Na ovaj način izbegavaš mogućnost da merge traje 12 dana (o, dešavalo se nekima) i da imaš hiljade i hiljade konflikata. Dakle, stalno push-ovanje i pull-ovanje mastera je cela poenta - ali je važno da taj kod na masteru bude čist i lep i da radi, inače "ode mast u propast".
Continuous delivery je proces kroz koji se prolazi da bi došlo do deploymenta. Deploy svih promena je automatizovan određenim granama (obično određena grana uključuje master). E sad, ovo može da bude fully automatizovan proces ili možeš da sam odlučiš kad se radi deploy i gde i to postižeš klikom na jedno dugmence - jednostavno, zar ne?
Continuous deployment može da se gleda kao nadogradnja na continuous delivery - onaj push koji prođe sve faze u pipeline-u, automatski je deploy-ovan kao nova verzija production-a. Može da bude strašno ako je poslednji push na master bio neđe malo loš, a petak popodne je. U ostalim slučajevima obično je fantastična stvar.
Kako se ovo postiže? Verovali ili ne, par dana postavljanja DevOps alatki i par skriptica, i voila! Imate gotovo rešenje.
Pre svega ti treba repo sa master granom za koji ćeš da kreiraš pipeline, bilo da koristiš github, gitlab, bitbucket, možeš da setup-uješ Jenkins, AzureDevops ili nešto treće da build-a određenu granu. Postoje vrlo jasna uputstva na svakom od ovih servisa kako se povezuje, setup-uje i postavlja ceo proces, ali mahom se sve svodi na klikanje po interfejsu servisa za automatizaciju i dodavanje skripte koja mu govori šta radi na master grani.
Trebaće ti verovatno i Docker i mala skriptica za njega kako da izbilda projekat i napravi docker image.
Sada, na primer ako koristite Jenkins (nisam sigurna za druga rešenja), čitav ovaj proces može da uključuje npr. Checkstyle provere kvaliteta koda (takođe editabilno i prilagodljivo projektu i potrebama istog), proveru pokrivenosti testovima i razne druge stvari. Zvuči jednostavno, zar ne?
Ako želiš da znaš više o svemu ovome, uvek možeš da posetiš dokumentaciju za Docker, Rancher, Kubernetes, Jenkins, Azure DevOps, pročitaš malo o pipeline-ovima, poigraš se sa različitim servisima i eto, znaš mnogo više.
A možeš i da nađeš DevOps inženjera, koji se sigurno u sve ovo razume značajno mnogo više od mene, da ti objasni dodatno. Ili da ga uposliš.
A da li, i zašto ih treba integrisati u svoj projekat? Da, da i hiljadu puta da.
Prvo, ne razmišljaš o serverima, okruženjima, deploy-ovima i ostalim peripetijama na dnevnom nivou. Drugo, svi ovi servisi i načini dostave softvera te teraju da pišeš kvalitetniji kod, teraju da ne grešiš, teraju da misliš na bug-ove i rešavaš ih unapred - prosto, napinju te na dnevnom nivou da radiš svoj posao bolje. Drugo, sve stiže brže klijentu, veće su šanse da će se bug-ovi počistiti kroz prolazak kroz sva okruženja, treće, klijent vidi promene in real time. To uvek čini klijenta srećnim. A srećan klijent = više posla = bolji uslovi i više plate.
E sad, da li svi treba da znamo sve ovo i postavimo sve ovo sami? Odgovor je isključivo moje lično mišljenje - bilo bi lepo, ali nije neophodno. Za to postoje ljudi kojima je to posao i koji će te rado naučiti kako to da uradiš sam. Ok je da na najvišem nivou znaš šta šta radi, kako je povezano, ako pukne build da pronađeš gde je log i grešku, da umeš da je popraviš. Ali dalje od toga, ne moraš da znaš. Samo bi bilo lepo.
A šta vi mislite o ovome?
2 komentara