streamalism.org

1. Pregled

U ovom ćemo članku razumjeti osnove DevOps principa i prakse. Vidjet ćemo zašto je ovo relevantno i korisno u razvoju softvera. Također ćemo razumjeti kako možemo smisleno usvojiti DevOps i koji nam alati pomažu na ovom putu.

2. Povijesni kontekst

Nećemo moći cijeniti DevOps kakav danas stoji bez da se malo osvrnemo u povijest. Početke razvoja softvera uglavnom je karakterizirala ono što nazivamo slapom metodologijom. Što ovo učinkovito znači, to je softver je koncipiran, dizajniran, razvijen, testiran i distribuiran uzastopno.

Svaki je korak bio što detaljniji, kao povratak je bio vrlo skup. To je zapravo značilo mnogo duže razdoblje čekanja između misli i akcije. Međutim, to nije bio takav problem jer je tehnološki krajolik bio puno manje nestabilan i prekomjerni poremećaji.

Zanimljivo je da ovaj model nije dugo trajao. Kako se tempo tehnologije mijenjao, a poremećaji su se počeli često događati, tvrtke su počele osjećati vrućinu. Trebali su nove ideje koje će se brže testirati. To je značilo brže promjene u svim aspektima poslovanja, uključujući softver.

To je rodilo cijeli novi svijet metodologija za razvoj softvera koji se slabo vide pod okriljem Agilea. Agilni manifest postavlja niz načela kojih se treba pridržavati isporuka softvera u malim koracima s bržom povratnom spregom. U praksi postoji nekoliko okretnih okvira poput Scruma i Kanbana.

3. Što je DevOps?

Vidjeli smo da je postupni razvoj s bržim povratnim informacijama danas postao temelj isporuke softvera. Ali kako to postići? Iako nas tradicionalne agilne metodologije vode do razumne točke, nije li to još uvijek idealno?

Agilne metodologije se neprestano usavršavaju jer neprestano teže razbijanju silosa.

Tradicionalno, uvijek smo imali različite timove koji su bili odgovorni za razvoj i isporuku softvera. Te su ekipe često djelovale u svojim silosima. To se učinkovito prevodi u puno duži ciklus povratnih informacija, što nije nešto što želimo s agilnim metodologijama.

Dakle, ne treba puno obrazloženja da bi se shvatilo da su dobro integrirani, višefunkcionalni agilni timovi puno pogodniji za postizanje svojih ciljeva. DevOps je praksa koja potiče komunikaciju, suradnju, integraciju i automatizaciju između razvojnih i operativnih timova. To nam bolje omogućuje brži povratne informacije da ostvarimo postupni razvoj.

Sljedeći dijagram objašnjava mogući tijek rada za vježbanje DevOpsa:

Iako ćemo kasnije kroz tutorial proći kroz detalje ovih koraka, shvatimo neke od ključnih principa DevOps-a:

• Vrijednosno usmjereni pristup (kakav je ostvario krajnji korisnik)
• Kultura suradnje (s učinkovitom komunikacijom, procesima i alatima)
• Automatizacija procesa (radi povećanja učinkovitosti i smanjenja pogrešaka)
• Mjerljivi ishodi (mjeriti s ciljevima)
• Kontinuirane povratne informacije (s tendencijom brzog poboljšanja)

4. Kako započeti putovanje?

Iako je teorija izravna i privlačna, stvarni su izazovi u smislenom vježbanju DevOpsa. Kao što smo do sada skupili, DevOps se uglavnom odnosi na ljude, a ne na timove.

Zajednički ciljevi, učinkovita komunikacija i višefunkcionalne vještine obilježja su takvih timova. Budući da je velik dio ove promjene kulturološki, često je spor i ne bez trenja.

4.1. Motivacija

Samo zato što postoji popularna praksa ne znači da je nužno prikladna za nas. Moramo razumjeti svoju motivaciju za bilo koji pomak - tim više ako radimo promjenu prema okretnosti. To je korisno utvrditi definiranjem ciljeva koje želimo postići.

Ciljevi DevOps-a u bilo kojoj organizaciji ovise o ambiciji, kulturi i zrelosti te organizacije. Evo nekoliko najčešćih ciljeva DevOpsa:

• Bolje iskustvo za krajnje korisnike
• Brže vrijeme za plasiranje na tržište
• Poboljšano srednje vrijeme za oporavak

4.2. Posvajanje

Imajte na umu da DevOps nije krajnje stanje već kontinuirani proces poboljšanja za postizanje ciljeva. Stoga svi u timu moraju težiti kako bi identificirali prepreke i brzo ih uklonili. Evo nekoliko aktivnosti koje nam mogu pomoći da započnemo:

• Jasno razumjeti trenutno stanje ideja proizvodnog ciklusa
• Skupite neka očita uska grla i upotrijebite mjerne podatke za donošenje stvarnih odluka
• Dajte prednost uskim grlima koja će dodati najviše vrijednosti kada se uklone
• Definirajte iterativni plan za postupnu isporuku vrijednosti za stavke s prioritetom
• Slijedite kratke cikluse Develop-Deploy-Measure kako biste postigli ciljeve

5. DevOps prakse

Postoji nekoliko praksi koje treba slijediti, ali ideja ih ne bi trebala koristiti kao zlatni standard. Trebali bismo pažljivo ispitati svaku praksu u pozadini našeg stanja i ciljeva, a zatim donijeti utemeljene odluke. Međutim, gotovo se sve prakse uglavnom usredotočuju na automatizaciju procesa što je više moguće.

5.1. Agilno planiranje

Agilno planiranje je praksa definiranja djela u kratkim koracima. Iako bi krajnji cilj trebao biti jasan, nije potrebno unaprijed definirati i detaljno definirati cjelokupnu aplikaciju. Ključ je ovdje da prioritet postavi na temelju vrijednosti koju može pružiti.

Zatim ga treba razbiti u iteraciji kratkih, ali funkcionalnih priraštaja.

5.2. Infrastruktura kao kod (IaC)

Ovo je praksa upravljanja i pružanja infrastrukture putem strojno čitljivih konfiguracijskih datoteka. Također upravljamo ovim konfiguracijama u sustavu za kontrolu verzija kao što upravljamo našom bazom kodova. Dostupno je mnogo jezika specifičnih za domenu za deklarativno stvaranje ovih konfiguracijskih datoteka.

5.3. Test automatizacija

Testiranje softvera tradicionalno je ručni napor koji se često provodi u silosima. To se ne vjenčava dobro s agilnim načelima. Stoga je neophodno da pokušamo za automatizaciju testiranja softvera na svim razinama, poput jedinstvenog testiranja, funkcionalnog testiranja, sigurnosnog testiranja i ispitivanja performansi.

5.4. Kontinuirana integracija (CI)

Kontinuirana integracija je praksa češćeg spajanja radnog koda u malim koracima u zajedničko spremište. Obično se na ovom zajedničkom spremištu često pokreću automatizirane izrade i provjere kako bi nas što prije upozorili na bilo kakve prekide koda.

5.5. Kontinuirana isporuka / postavljanje (CD)

Kontinuirana dostava je praksa izdavanja softvera u malim koracima čim prođe sve provjere. To se često prakticira zajedno s kontinuiranom integracijom, a može imati koristi od automatiziranog mehanizma otpuštanja (naziva se kontinuirano postavljanje).

5.6. Kontinuirano praćenje

Nadzor - možda središte DevOps-a - omogućuje brže povratne petlje. Identificiranje prava je metrika za praćenje svih aspekata softvera, uključujući infrastrukturu, presudna. Ako imate prave mjerne podatke, zajedno s učinkovitom analitikom u stvarnom vremenu, možete brže prepoznati i riješiti probleme. Štoviše, hrani se izravno u agilnom planiranju.

Ovaj popis daleko nije potpun i neprestano se razvija. Timovi koji vježbaju DevOps neprestano pronalaze bolje načine za postizanje svojih ciljeva. Neke druge prakse koje vrijedi spomenuti su kontejnerizacija, razvoj u oblaku i mikroservisi, da nabrojimo samo neke.

6. Alati trgovine

Nijedna rasprava o DevOpsu ne može biti cjelovita bez razgovora o alatima. To je jedno područje na kojem je posljednjih nekoliko godina došlo do eksplozije. Kad završimo s čitanjem ovog vodiča, možda postoji novi alat! Iako je ovo istovremeno primamljivo i neodoljivo, potrebno je biti oprezan.

Naše DevOps putovanje ne smijemo započeti s alatima kao prvom stvari u našim mislima. Mi moramo istražiti i uspostaviti naše ciljeve, ljude (kulturu) i prakse prije pronalaska pravih alata. Jasno nam je, pogledajmo koji su nam vremenski testirani alati dostupni.

6.1. Planiranje

Kao što smo vidjeli, zreli DevOps uvijek započinje s agilnim planiranjem. Iako su jasni ciljevi, potrebno je samo odrediti prioritete i definirati rad za nekoliko kratkih ponavljanja. Povratne informacije od ovih ranih ponavljanja neprocjenjive su u oblikovanju budućih i cjelokupnog softvera. Učinkovit alat ovdje bi nam pomogao da ovaj proces provedemo s lakoćom.

Jira je najbolje ocijenjen proizvod za praćenje izdanja koji je razvio Atlassian. Ima puno ugrađenih agilnih alata za planiranje i praćenje. Uglavnom je to komercijalni proizvod koji možemo pokrenuti lokalno ili ga koristiti kao hostiranu aplikaciju.

6.2. Razvoj

Ideja agilnosti je brži prototip i traženje povratnih informacija o stvarnom softveru. Programeri moraju unijeti promjene i brže se spojiti u zajedničku verziju softvera. Još je važnije da komunikacija između članova tima bude tečna i brza.

Pogledajmo neke sveprisutne alate u ovoj domeni.

Git je distribuirani sustav kontrole verzija. Prilično je popularan, a postoje brojne usluge koje pružaju git spremišta i funkcije s dodanom vrijednosti. Izvorno razvijen od strane Linusa Torvaldsa, čini suradnju između programera prilično praktičnom.

Confluence je alat za suradnju koji je razvio Atlassian. Suradnja je ključ uspjeha bilo kojeg agilnog tima. Stvarna semantika suradnje prilično je kontekstualna, ali alat koji se trudi neometano je ipak neprocjenjiv. Sliv točno odgovara ovom mjestu. Štoviše, dobro se integrira s Jirom!

Slack je platforma za razmjenu trenutnih poruka koju su razvili Slack Technologies. Kao što smo razgovarali, okretan timovi bi trebali biti u mogućnosti surađivati ​​i komunicirati, po mogućnosti u stvarnom vremenu. Osim razmjene trenutnih poruka, Slack nudi mnogo načina za komunikaciju s jednim korisnikom ili skupinom korisnika - i dobro se integrira s drugim alatima poput Jire i GitHub-a!

6.3. Integracija

Promjene koje su spojili programeri trebali bi se kontinuirano pregledavati radi usklađenosti. Što predstavlja usklađenost specifično je za tim i aplikaciju. Međutim, uobičajeno je statičku i dinamičku analizu koda, kao i funkcionalna i nefunkcionalna metrička mjerenja, vidjeti kao komponente usklađenosti.

Pogledajmo ukratko nekoliko popularnih alata za integraciju.

Jenkins je uvjerljiv, otvoren i besplatan poslužitelj za automatizaciju. U industriji je godinama i sazrio je dovoljno da servisira širok spektar slučajeva automatizacije. Nudi deklarativni način definiranja rutine automatizacije i razne načine za automatsko ili ručno pokretanje. Štoviše, ima bogat set dodataka koji služe nekoliko dodatnih značajki za stvaranje moćnih cjevovoda za automatizaciju.

SonarQube je platforma za kontinuirani pregled otvorenog koda koju je razvio SonarSource. SonarQube ima bogat set pravila statičke analize za mnoge programske jezike. To pomaže otkriti mirise koda što je ranije moguće. Štoviše, SonarQube nudi nadzornu ploču koja može integrirati druge mjerne podatke poput pokrivanja koda, složenosti koda i mnogih drugih. I to dobro funkcionira s Jenkins poslužiteljem.

6.4. Dostava

Važno je brzo isporučiti promjene i nove značajke softveru. Čim utvrdimo da su promjene spojene u spremištu u skladu s našim standardima i pravilima, trebali bismo biti u mogućnosti dostaviti ih krajnjim korisnicima brzo. To nam pomaže prikupiti povratne informacije i bolje oblikovati softver.

Ovdje postoji nekoliko alata koji nam mogu pomoći u automatizaciji nekih aspekata isporuke do točke u kojoj postižemo kontinuiranu implementaciju.

Docker je najčešći alat za brzo kontejniranje bilo koje vrste aplikacija. Koristi virtualizaciju na razini OS-a kako bi izolirao softver u pakete koji se nazivaju spremnici. Kontejnerizacija ima neposrednu korist u smislu pouzdanije isporuke softvera. Docker kontejneri međusobno razgovaraju kroz točno definirane kanale. Štoviše, ovo je prilično malo u usporedbi s drugim načinima izolacije poput Virtualnih strojeva.

Chef / Lutka / Ansible su alati za upravljanje konfiguracijom. Kao što znamo, stvarna pokrenuta instanca softverske aplikacije kombinacija je gradnje baze podataka i njegovih konfiguracija. I dok je gradnja baze podataka često nepromjenjiva u svim okruženjima, konfiguracije nisu. Ovo je gdje potreban nam je alat za upravljanje konfiguracijom da bismo s lakoćom i brzinom implementirali našu aplikaciju. U ovom je prostoru nekoliko popularnih alata, od kojih svaki ima svoje hirove, ali Chef, Lutka i Ansible prilično pokrivaju osnove.

HashiCorp Terraform može nam pomoći u pružanju infrastrukture, što je dosadan i dugotrajan zadatak još od vremena privatnih podatkovnih centara. No, sa sve više i više usvajanja oblaka, infrastruktura se često doživljava kao konstrukcija za jednokratnu upotrebu i ponavljanje. Međutim, to se može postići samo ako imamo alat s kojim možemo deklarativno definirati jednostavnu do složenu infrastrukturu i stvoriti je klikom na gumb. Možda zvuči kao slijed snova, ali Terraform aktivno pokušava premostiti tu prazninu!

6.5. Praćenje

Napokon, presudno je biti sposoban promatrati raspoređivanje i mjeriti ga s ciljevima. Može biti mnoštvo mjernih podataka koje možemo prikupiti iz sustava i aplikacija. Uključuju neke poslovne mjerne podatke koji su specifični za našu aplikaciju.

Ideja je ovdje biti u mogućnosti prikupiti, kurirati, pohraniti i analizirati ove mjerne podatke u gotovo stvarnom vremenu. U ovom je prostoru dostupno nekoliko novih proizvoda, otvorenih i komercijalnih.

Elastic-Logstash-Kibana (ELK) skup je tri projekta otvorenog koda - Elasticsearch, Logstash i Kibana. Elasticsearch je visoko skalabilni mehanizam za pretraživanje i analitiku. Logstash nam nudi cjevovod za obradu podataka na strani poslužitelja koji može trošiti podatke iz širokog spektra izvora. Konačno, Kibana nam pomaže vizualizirati ove podatke. Zajedno, ovaj stog može biti koristi se za prikupljanje podataka poput dnevnika iz svih aplikacija i njihovu analizu u stvarnom vremenu.

Prometheus je alat za praćenje i upozoravanje sustava otvorenog koda izvorno razvio SoundCloud. Dolazi s višedimenzionalnim podatkovnim modelom, fleksibilnim jezikom upita i može povući podatke vremenskih serija preko HTTP-a. Grafana je još jedno rješenje za analitiku i nadzor otvorenog koda koji radi s nekoliko baza podataka. Zajedno, Prometej i Grafana mogu dajte nam u stvarnom vremenu pristup gotovo svim mjernim podacima koje su naši sustavi sposobni proizvesti.

7. DevOps ekstenzije (ili su stvarno!)

Vidjeli smo da se DevOp u osnovi neprestano trudi ukloniti prepreke prema bržoj i iterativnoj isporuci softvera temeljenoj na vrijednosti. Sad je jedan od neposrednih zaključaka da ovdje ne može biti krajnja država.

Ono što su ljudi shvatili kao trenje između razvojnih i operativnih timova nije jedino trenje. Razbijanje silosa unutar organizacije radi povećanja suradnje središnja je ideja. Ljudi su to ubrzo počeli shvaćati slična trenja postoje između razvojnih i ispitnih timova te između razvojnih i sigurnosnih timova. Mnoge tradicionalne postavke imaju posvećene timove za sigurnost i izvedbu.

Puni potencijal DevOps-a nikada se neće moći ostvariti dok ne probijemo gotovo sve granice između timova i pomognemo im da mnogo učinkovitije surađuju. Ovo samo po sebi znači dovođenje timova poput testiranja, sigurnosti i performansi.

Zbrka je uglavnom u njezinoj nomenklaturi. DevOps nam daje do znanja da se uglavnom radi o razvojnim i operativnim timovima. Stoga su se s vremenom pojavili novi pojmovi koji su obuhvaćali druge timove. Ali uglavnom se samo DevOps realizira učinkovitije!

7.1. DevTestOps

Kamen temeljac DevOpsa je isporuku visokokvalitetnog softvera u malim koracima i češće. Ovdje postoji mnogo aspekata naglaska na kvaliteti. U određenom smislu, često pretpostavljamo da će nam DevOps prakse koje usvojimo pomoći pomoći da to postignemo. Tačno je i da se mnoge prakse o kojima smo ranije razgovarali usredotočuju na osiguravanje visoke kvalitete u svakom trenutku.

Ali funkcionalno testiranje softvera ima puno širi opseg. Često imamo tendenciju da testiranje višeg reda, poput end-to-end testiranja, zadržimo pri kraju isporuke softvera. Još važnije, to je često odgovornost odvojenog tima koji se kasno uključi u proces. Tu stvari počinju odstupati od principa DevOps.

Ono što bismo radije trebali učiniti je da integrirati testiranje softvera na svim razinama od samog početka. Već u fazi planiranja, testiranje softvera trebalo bi se smatrati integralnim aspektom isporuke. Štoviše, isti bi tim trebao biti odgovoran za razvoj i testiranje softvera. To je ono što je praksa DevTestOps nadaleko poznata. To se često naziva i kontinuiranim ispitivanjem i pomicanjem ulijevo.

7.2. DevSecOps

Sigurnost je sastavni dio svakog razvoja softvera i ima svoj udio u složenosti. To često znači da imamo zaseban tim sigurnosnih stručnjaka s kojima stupamo u kontakt odmah kad smo spremni za isporuku proizvoda. Ranjivosti koje identificiraju u ovoj fazi mogu biti skupe za otklanjanje. Ovo opet ne rezonuje dobro s načelima DevOpsa.

U to bismo vrijeme već trebali imati rješenje koje trebamo primijeniti, a to je i trebalo uvesti sigurnosne probleme i osoblje na početku igre. Morali bismo motivirati timove da razmišljaju o sigurnosti u svakoj fazi. Sigurnost je bez sumnje vrlo specijalizirana domena, pa ćemo stoga možda trebati dovesti stručnjaka u tim. Ali ideja je ovdje razmotriti neke od najboljih praksi od samog početka.

Kako se krećemo, ima ih nekoliko dostupnih alata koji mogu automatizirati skeniranje za veći broj ranjivosti. To također možemo uključiti u naše cikluse kontinuirane integracije kako bismo dobili brzu povratnu informaciju! Sada ne možemo sve integrirati u kontinuiranu integraciju jer moramo to održavati laganim, ali uvijek mogu postojati druga povremena skeniranja koja se rade zasebno.

8. Zaključak

U ovom smo članku prošli kroz osnove DevOps principa, praksi i alata dostupnih za upotrebu. Razumjeli smo kontekst u kojem je DevOps relevantan i razloge zbog kojih nam može biti od koristi. Također smo kratko razgovarali o tome gdje započeti putovanje usvajanjem DevOpsa.

Nadalje, dotaknuli smo se nekih od popularnih praksi i alata dostupnih za korištenje na ovom putovanju. Također smo razumjeli i neke druge popularne izraze oko DevOps-a poput DevTestOps i DevSecOps.

Napokon, moramo shvatiti da DevOps nije krajnje stanje, već putovanje koje možda nikada neće završiti! Ali zabavan dio ovdje je samo putovanje. Cijelo to vrijeme nikada ne smijemo izgubiti iz vida svoje ciljeve i trebali bismo se usredotočiti na ključne principe. Prilično je lako nasjesti na sjaj popularnog alata ili izraza u industriji. Ali uvijek moramo imati na umu da je sve korisno samo ako nam pomaže da učinkovitije isporučujemo vrijednost svojoj publici.