Mnogi od vas možda su svjesni svih teorija povezanih s njima . Ali znate li kako primijeniti DevOps principe u stvarnom životu? Na ovom blogu razgovarat ću o scenarijima DevOps u stvarnom vremenu koji će vam pomoći da kratko razumijete kako stvari funkcioniraju u stvarnom vremenu.
Naputci koje ću pokrivati u ovomeČlanak o scenarijima DevOps u stvarnom vremenusu:
- Što je DevOps?
- Probleme koje je riješio DevOps
- CI (kontinuirana integracija) scenariji
- CT (kontinuirano testiranje) scenariji
- CD (kontinuirana isporuka) scenariji
- Scenariji podataka DevOps
Počnimo s našom prvom temom.
Što je DevOps?
DevOps je pristup razvoju softvera koji uključuje kontinuirani razvoj, kontinuirano testiranje, kontinuiranu integraciju, kontinuiranu implementaciju i kontinuirano praćenje softvera tijekom njegovog životnog ciklusa razvoja. Te su aktivnosti moguće samo u DevOpsu, a ne u Agileu ili slapu. Zbog toga su Facebook i druge vodeće tvrtke odabrale DevOps kao put prema naprijed za svoje poslovne ciljeve.DevOps je uglavnom poželjan za razvoj visokokvalitetnog softvera u kraćim razvojnim ciklusima što rezultira većim zadovoljstvom kupaca.
U sljedećem odjeljku ovogaU članku DevOps scenariji u stvarnom vremenu, pogledati ćemo razne probleme koje je riješio DevOps.
Probleme koje je riješio DevOps
1. Dostavite vrijednost kupcima
- DevOps minimalizira vrijeme potrebno je za isporuku vrijednosti kupcima. Vrijeme ciklusa od programera dovršetka priče / zadatka do produkcije značajno se smanjuje, omogućujući da se vrijednost ostvari što je brže moguće.
Najvažnija vrijednost ostvarena kroz DevOps je ta što IT organizacijama to omogućuje usredotočiti se na njihove 'osnovne' poslovne aktivnosti . Uklanjanjem ograničenja unutar toka vrijednosti i automatizacijom cjevovoda za uvođenje, timovi se mogu usredotočiti na aktivnosti. To pomaže u stvaranju korisničke vrijednosti, a ne samo u pomicanju bitova i bajtova. Te aktivnosti povećavaju održivu konkurentsku prednost tvrtke i stvaraju bolje poslovne rezultate.
2. Skraćeno vrijeme ciklusa
Interno je DevOps jedini način za postizanje okretnosti za isporuku sigurnog koda s uvidima. Važno je imati kapije i dobro osmišljen DevOps postupak. Kada isporučujete novu verziju, ona se može izvoditi usporedo s trenutnom verzijom. Također možete usporediti mjerne podatke kako biste ostvarili ono što ste željeli s mjernim podacima aplikacije i izvedbe.
DevOps tjera razvojne timove prema kontinuirano poboljšanje i brži ciklusi oslobađanja . Ako se dobro izvede, ovaj iterativni postupak omogućuje s vremenom veću usredotočenost na stvari koje su stvarno bitne. Kao što su stvari koje korisnicima stvaraju izvrsna iskustva - i manje vremena za upravljanje alatima, procesima i tehnologijom.
3. Vrijeme za tržište
Najvažniji problem koji se rješava je smanjenje složenosti postupka. To značajno pridonosi našem poslovnom uspjehu skraćujući vrijeme na tržištu, pružajući nam brze povratne informacije o značajkama i čineći nas odgovornijim na potrebe naših kupaca.
4. Rješavanje problema
Najveća vrijednost uspješne implementacije DevOpsa je veće povjerenje u isporuku, vidljivost i sljedivost onoga što se događa, tako da možete brže riješiti probleme.
Još jedna važna prednost DevOps-a je gubljenje vremena. Usklađivanje ljudi i resursa organizacije omogućuje brzu implementaciju i ažuriranje. To omogućuje programima DevOps da riješe probleme prije nego što se pretvore u katastrofe.DevOps stvara kulturu transparentnosti koja promiče fokus i suradnju između razvojnih, operativnih i sigurnosnih timova.
CI (kontinuirana integracija) uDevOps scenariji u stvarnom vremenu
1. Pojedinci mogu vidjeti kontinuiranu integraciju kontraproduktivnom
Članovi razvojnog tima imaju različite uloge, odgovornosti i prioritete. Moguće je da je prvi prioritet voditelja proizvoda lansiranje novih značajki, a voditelji projekata moraju biti sigurni da njihov tim ispunjava rok. Programeri bi mogli pomisliti da će ih usporiti ako prestanu ispravljati manju pogrešku svaki put kad se dogodi. Mogli bi smatrati da im održavanje zgrade bude čist dodatan teret i neće im biti od koristi zbog njihovih dodatnih napora. To potencijalno može ugroziti proces prilagodbe.
Da biste to prevladali:
Prvo, provjerite je li vaš cijeli tim na brodu prije nego što usvojite kontinuiranu integraciju.
Tehnički tehničari i vođe timova moraju članovima tima pomoći da razumiju troškove i koristi kontinuirane integracije.
Istaknite što će i kada imati koristi od kodera posvećujući se drugoj radnoj metodi koja zahtijeva malo više otvorenosti i fleksibilnosti.
2. Integriranje CI-a u vaš postojeći razvojni tok
Usvajanje CI neizbježno dolazi s potrebom za suštinskom promjenom nekih dijelova vašeg razvojnog tijeka rada. Moguće je da vaši programeri možda neće popraviti tijek rada ako nije neispravan. To je moguće uglavnom ako vaš tim ima veću rutinu u izvršavanju svog trenutnog tijeka posla.
Ako želite promijeniti tijek rada, to morate učiniti s velikim mjerama opreza. U suprotnom, to bi moglo ugroziti produktivnost razvojnog tima, a također i kvalitetu proizvoda. Bez dovoljne podrške vodstva, razvojni tim mogao bi biti malo oklijevajući poduzeti zadatak s takvim rizicima.
Da biste to prevladali:
Morate osigurati dovoljno vremena da vaš tim razvije svoj novi tijek rada. To se radi kako bi se odabralo fleksibilno rješenje za kontinuiranu integraciju koje može podržati njihov novi tijek rada.
Također, osigurajte im da im tvrtka stoji uz leđa čak i ako na početku stvari možda ne idu baš glatko.
3. Vraćanje u prijašnje navike testiranja
Neposredni učinak usvajanja kontinuirane integracije je da će vaš tim češće testirati. Dakle, za više testova bit će potrebno više slučajeva, a pisanje slučajeva može potrajati. Stoga programeri često trebaju podijeliti svoje vrijeme između popravljanja programskih pogrešaka i pisanja testnih slučajeva.
Privremeno bi programeri mogli uštedjeti vrijeme ručnim testiranjem, ali dugoročno bi moglo više naštetiti. Što više odugovlače s pisanjem testnih slučajeva, to će biti teže nadoknaditi napredak razvoja. U najgorem slučaju, vaš bi se tim na kraju mogao vratiti na svoj stari postupak testiranja.
Da biste to prevladali:
Morate naglasiti da bi pisanje testnih slučajeva od početka moglo uštedjeti puno vremena za vaš tim i osigurati visoku pokrivenost vašeg proizvoda testom.
Također, ugradite ideju u kulturu svoje tvrtke da su testni slučajevi jednako vrijedna imovina kao i sama kodna baza.
4. Programeri koji ignoriraju poruke o pogreškama
Čest je problem da kada veći timovi rade zajedno, količina CI obavijesti postaje neodoljiva i programeri ih počinju ignorirati i prigušiti. Stoga je moguće da će propustiti ažuriranja koja su za njih relevantna.
To može dovesti do faze u kojoj koderi razvijaju relativni imunitet na slomljene građe i poruke o pogreškama. Što duže ignoriraju relevantne obavijesti, to se dulje razvijaju bez povratnih informacija u pogrešnom smjeru. To bi potencijalno moglo prouzročiti ogromna vraćanja, rasipanje novca, resursa i vremena.
Da biste to prevladali:
Trebali biste slati samo kritična ažuriranja.
Obavijest šaljite samo odgovarajućim programerima koji su zaduženi za njezino popravljanje.
CT (kontinuirano ispitivanje) uDevOps scenariji u stvarnom vremenu
Dobivanje ispravne specifikacije zahtjeva
Ako točno postignete svoje zahtjeve, dobiva se gotovo polovica bitke. Dakle, ako imate vrlo specifično i točno razumijevanje zahtjeva, možete bolje dizajnirati planove ispitivanja i dobro pokriti zahtjeve.
Ipak, mnogi timovi troše puno vremena i truda jednostavno razjašnjavajući zahtjeve. Ovo je vrlo česta zamka i kako bi to izbjegli, timovi mogu usvojiti testiranje temeljeno na modelu i tehnike zasnovane na ponašanju. To pomaže u preciznom i adekvatnom dizajniranju scenarija ispitivanja.
Ove će prakse zasigurno pomoći bržem rješavanju i rješavanju praznina. Također, omogućuje im da automatski generiraju više test slučajeva već u ranoj fazi sprinta.
Orkestracija cjevovoda
Prednosti kontinuiranog ispitivanja i kontinuirana isporuka usko su povezane s orkestracijom cjevovoda. To izravno znači razumijevanje kako to funkcionira, zašto funkcionira, kako analizirati rezultate te kako i kada skalirati. Sve ovisi o cjevovodu i stoga trebate integrirati cjevovod sa paketom automatizacije.
Ali razlog zašto se timovi petljaju je taj što niti jedno rješenje ne pruža cjelovit lanac alata potreban za izgradnju CD cjevovoda.
Timovi obično trebaju tražiti dijelove slagalice koji su za njih točni. Ne postoje savršeni alati, obično samo najkvalitetniji alati koji pružaju integracije zajedno s više drugih alata. I naravno, API koji omogućuje i jednostavne integracije.
Ukratko, nemoguće je provesti kontinuirano ispitivanje bez brzine i pouzdanosti standardiziranog i automatiziranog cjevovoda.
Povećavanje i upravljanje složenošću
Drugi važan scenarij je da kontinuirano testiranje postaje složenije kako se kreće prema proizvodnom okruženju. Brojevi testova rastu, kao i složenost, a kod sazrijevanja i okoliš postaju sve složeniji.
python pretvoriti decimalni u binarni
Testove morate ažurirati svaki put kada ažurirate različite faze i automatizirane skripte. Kao rezultat, ukupno vrijeme potrebno za pokretanje testova također se povećava prema izdanju.
Rješenje za ovo leži u poboljšanoj orkestraciji testa koja pruža pravu količinu pokrivenosti testom u kraćim ciklusima sprinta i omogućava timovima da samopouzdano rade. U idealnom slučaju, cjelokupni postupak mora biti automatiziran CT-om koji se provodi u različitim fazama. To se postiže upotrebom vrata politike i ručne intervencije, sve dok se kôd ne potisne u proizvodnju.
Stvaranje petlji povratnih informacija
Bez čestih petlji povratne sprege u svakoj fazi razvojnog ciklusa, kontinuirano testiranje nije moguće. To je dijelom razlog zašto je CT teško implementirati. Ne trebaju vam samo automatizirani testovi, već vam je potrebna i vidljivost rezultata ispitivanja i izvršenja.
Tradicionalne petlje povratnih informacija kao što su alati za bilježenje, profilatori koda i alati za nadzor izvedbe više nisu učinkoviti. Niti rade zajedno niti pružaju dubinu uvida potrebnog za rješavanje problema. Nadzorne ploče u stvarnom vremenu koje automatski generiraju izvješća i povratne informacije o djelovanju na cijelom SDLC-u pomažu bržem puštanju softvera u proizvodnju s manjim nedostacima. Pristup nadzornim pločama u stvarnom vremenu i pristup svim članovima tima pomažu u kontinuiranom mehanizmu povratnih informacija.
Nedostatak okruženja
Kontinuirano testiranje jednostavno znači češće testiranje, a to zahtijeva češće pogađanje više okruženja. To predstavlja usko grlo ako navedena okruženja nisu dostupna u vrijeme kada su potrebna. Neka su okruženja dostupna putem API-ja, a neka putem različitih sučelja. Neka od tih okruženja mogu se graditi pomoću moderne arhitekture, dok se druga mogu koristiti monolitnim naslijeđenim klijentom / poslužiteljem ili glavnim računalom.
Ali pitanje je ovdje kako koordinirati testiranje putem različitih vlasnika okoliša? Također je moguće da možda neće uvijek održavati okruženje u pogonu. Odgovor na sve ovo je Virtualizacija . Virtueliziranjem okoline možete testirati kôd bez previše brige oko područja koja su nepromjenjiva.Učiniti okruženja dostupnim i dostupnim na zahtjev putem virtualizacije zasigurno pomaže ukloniti značajno usko grlo s vašeg cjevovoda.
CD (kontinuirana isporuka) uDevOps scenariji u stvarnom vremenu
Uvođenje predugo traje
Distribuirane aplikacije obično zahtijevaju više od kopiranja i lijepljenja datoteka na poslužitelj. Složenost ima tendenciju povećanja ako imate farmu poslužitelja. Nesigurnost oko toga što rasporediti, gdje i kako je prilično normalna stvar. Rezultat? Duga vremena čekanja da se naši artefakti preusmjere u sljedeće okruženje rute, odgađanja svega, testiranja, vremena za život itd.
Što DevOps donosi na stol? Razvojni i IT operativni timovi definiraju proces implementacije u besprijekornoj sesiji suradnje. Prvo provjeravaju što funkcionira, a zatim ga automatizacijom podižu na sljedeću razinu kako bi olakšali kontinuiranu isporuku. To drastično smanjuje vrijeme za raspoređivanje, a ujedno otvara put za češće raspoređivanje.
Nedostaju artefakti, skripte i druge ovisnosti
Često se susrećemo s kvarovima nakon postavljanja nove verzije radnog softvera. To je često uzrokovano nedostajanjem knjižnica ili skripti baze podataka koje se ne ažuriraju. To je obično uzrokovano nedostatkom jasnoće o tome koje će se ovisnosti rasporediti i njihovo mjesto. Poticanje suradnje između razvoja i operacija može pomoći u rješavanju takvih vrsta problema u većini slučajeva.
Što se tiče automatizacije, možete definirati ovisnosti što uvelike pomaže u ubrzavanju implementacija. Alati za upravljanje konfiguracijom poput Lutka ili Glavni pridonijeti dodatnom razinom definicije ovisnosti. Možemo definirati ne samo ovisnosti unutar naše aplikacije već i na razini infrastrukture i konfiguracije poslužitelja. Na primjer, možemo stvoriti virtualni stroj za test i instalirati / konfigurirati mačak prije objavljivanja naših artefakata.
Neučinkovito praćenje proizvodnje
Ponekad alate za nadzor konfigurirate na način da iz proizvodnje proizvedu puno nebitnih podataka, međutim, drugi put ne proizvode dovoljno ili uopće ništa. Ne postoji definicija onoga na što trebate paziti i koje su metričke vrijednosti.
Morate se dogovoriti oko toga što nadzirati i koje podatke proizvoditi, a zatim uspostaviti kontrole. Alati za upravljanje izvedbom aplikacija velika su vam pomoć ako si vaša organizacija može priuštiti da pogleda AppDynamics, New Relic i AWS X-Ray.
Scenariji podataka DevOps
DevOps se bavi uklanjanjem rizika povezanih s razvojem novog softvera: Analiza podataka identificira te rizike. Da bi se kontinuirano mjerilo i poboljšavalo DevOps proces, analitika bi se trebala protezati na cijelom cjevovodu. To pruža neprocjenjive uvide menadžmentu u svim fazama životnog ciklusa razvoja softvera.
1. Manje vremena za analizu podataka
Uz sve podatke koji se generiraju u bilo kojem trenutku, organizacije moraju prihvatiti da ne mogu sve analizirati. Jednostavno nema dovoljno vremena u danu - a nažalost, roboti još nisu sasvim sofisticirani da bi to sve učinili za nas.
Iz tog razloga važno je utvrditi koji su skupovi podataka najvažniji. U većini slučajeva to će biti drugačije za svaku organizaciju. Stoga prije uranjanja odredite ključne poslovne ciljeve i ciljeve. Ti se ciljevi tipično vrte oko potreba kupaca - prvenstveno najvrjednijih značajki koje su najvažnije krajnjim korisnicima. Na primjer, za maloprodaju je na vrhu popisa analiziranje interakcije prometa sa stranicom za naplatu na web mjestu i testiranje njegovog rada u pozadini.
Nekoliko brzih savjeta za utvrđivanje podataka koje je najvažnije analizirati:
Napravite grafikon: Utvrdite utjecaj ispada na vašu tvrtku, postavljajući pitanja poput: „Ako X se lomi , kakav će učinak imati na druge značajke? '
Pogledajte povijesne podatke: utvrdite gdje su se problemi pojavili u prošlosti i nastavite analizirati podatke iz testova i izgraditi kako biste osigurali da se to više ne ponovi.
2. Teška komunikacija
Danas većina organizacija još uvijek djeluje s različitim timovima i osobama utvrđujući vlastite ciljeve i koristeći vlastite alate i tehnologije. Svaki tim djeluje neovisno, odvojen od plinovoda i sastajući se s drugim timovima samo tijekom faze integracije.
Kada je riječ o promatranju šire slike i prepoznavanju onoga što djeluje, a što ne radi, organizacija se trudi doći do jednog rješenja. To je zato što ponajviše zato što svi ne uspijevaju podijeliti sveukupne podatke, što analizu čini nemogućom.
Da biste prevladali ovaj problem, izmijenite protok komunikacije kako biste osigurali da svi surađuju tijekom SDLC-a, ne samo tijekom procesa integracije.
Prvo se pobrinite za snažnu sinkronizaciju mjernih podataka DevOps od samog početka. Napredak svakog tima trebao bi biti prikazan na jednoj nadzornoj ploči, koristeći iste ključne pokazatelje uspješnosti (KPI) kako bi se menadžmentu dao uvid u cjelokupan proces. To je učinjeno kako bi mogli prikupiti sve potrebne podatke za analizu onoga što je pošlo po zlu (ili što je uspjelo).
Osim početnog razgovora s metričkim podacima, trebala bi postojati stalna komunikacija putem sastanaka tima ili digitalnih kanala poput Slacka.
3. Nedostatak radne snage
Kad imamo kratko osoblje, trebaju nam pametniji alati koji koriste duboko učenje za uvrštavanje podataka koje prikupljamo i brzo donošenje odluka. Napokon, nitko nema vremena pogledati svako pojedinačno izvršavanje testa (a za neke velike organizacije u danu ih može biti oko 75 000). Trik je u uklanjanju buke i pronalasku pravih stvari na koje se možete usredotočiti.
Tu umjetna inteligencija i strojno učenje mogu pomoći. Mnogi alati na tržištu danas koriste AI i ML za sljedeće stvari:
Razviti skripte i testove za premještanje i provjeru valjanosti različitih dijelova podataka
Izvještaj o kvaliteti na temelju prethodno naučenog ponašanja
Radite kao odgovor na promjene u stvarnom vremenu.
Dakle, s ovim smo došli do kraja ovog članka o DevOps scenarijima u stvarnom vremenu.
Sad kad ste shvatili što su DevOpsovi scenariji u stvarnom vremenu, pogledajte ovo Edureka, pouzdane tvrtke za internetsko učenje s mrežom od više od 250 000 zadovoljnih učenika raširenih širom svijeta. Edureka DevOps certifikacijski tečaj pomaže učenicima da shvate što je DevOps i steknu stručnost u raznim DevOps procesima i alatima kao što su Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack i GIT za automatizaciju više koraka u SDLC-u.
Imate pitanje za nas? Molimo navedite ga u odjeljku za komentare ovogaČlanak o scenarijima DevOps u stvarnom vremenui javit ćemo vam se.