Scenariji DevOps v realnem času - vedite, kaj se dogaja v realnem času



Ta spletni dnevnik govori o scenarijih DevOps v realnem času, ki vam pomagajo razumeti izzive, s katerimi se lahko srečate v realnem času, in kako jih premagati.

Mnogi od vas bi se morda zavedali vseh teorij, povezanih z njimi . Toda ali veste, kako načela DevOps izvajati v resničnem življenju? V tem blogu bom razpravljal o scenarijih DevOps v realnem času, ki vam bodo pomagali na kratko razumeti, kako stvari delujejo v realnem času.

Napotki, ki jih bom pokrival v temČlanek o scenarijih DevOps v realnem časuso:





Začnimo torej z našo prvo temo.

Kaj je DevOps?

devops-devops scenariji v realnem času-EdurekaDevOps je pristop k razvoju programske opreme, ki vključuje nenehen razvoj, nenehno testiranje, nenehno integracijo, nenehno uvajanje in nenehno spremljanje programske opreme skozi njen razvojni življenjski cikel. Te dejavnosti so možne samo v DevOpsu, ne v okretnosti ali slapu. Zato so Facebook in druga vrhunska podjetja izbrali DevOps kot pot naprej za svoje poslovne cilje.DevOps je v glavnem zaželen za razvoj visokokakovostne programske opreme v krajših razvojnih ciklih, kar ima za posledico večje zadovoljstvo strank.



V naslednjem poglavju tegaV članku DevOps Real Time Scenarios si bomo ogledali različne težave, ki jih je rešil DevOps.

Težave, ki jih je rešil DevOps

1. Kupcem zagotovite vrednost

  • DevOps minimalizira čas potrebno je, da kupcem ponudimo vrednost. Čas cikla od razvijalčevega zaključka zgodbe / naloge do izdelave se bistveno zmanjša, kar omogoča, da se vrednost čim hitreje uresniči.
  • Najpomembnejša vrednost, ki jo dosežemo s pomočjo DevOps, je, da IT organizacijam to omogoča osredotočiti na njihove 'osnovne' poslovne dejavnosti . Z odstranjevanjem omejitev znotraj toka vrednosti in avtomatizacijo uvajalskih cevovodov se lahko ekipe osredotočijo na dejavnosti. To pomaga pri ustvarjanju vrednosti za stranke in ne le pri premikanju bitov in bajtov. Te dejavnosti povečujejo trajnostno konkurenčno prednost podjetja in ustvarjajo boljše poslovne rezultate.



2. Skrajšan čas cikla

  • Interno je DevOps edini način za doseganje okretnosti za zagotavljanje varne kode z vpogledi. Pomembno je, da imate vrata in dobro oblikovan postopek DevOps. Ko dobavljate novo različico, se lahko izvaja vzporedno s trenutno različico. Meritve lahko primerjate tudi tako, da dosežete želeno z meritvami aplikacij in uspešnosti.

  • DevOps usmerja razvojne ekipe k nenehno izboljševanje in hitrejši cikli sproščanja . Če je dobro opravljen, ta ponovitveni postopek sčasoma omogoča večjo osredotočenost na stvari, ki so resnično pomembne. Na primer stvari, ki ustvarjajo odlične izkušnje za uporabnike - in manj časa za upravljanje orodij, procesov in tehnologije.

3. Čas za prodajo

Najpomembnejši problem, ki ga rešujemo, je zmanjšanje zahtevnosti postopka. To bistveno prispeva k našemu poslovnemu uspehu s skrajšanjem našega časa na trgu, s hitrimi povratnimi informacijami o funkcijah in s tem, da se bolj odzivamo na potrebe naših strank.

4. Reševanje težav

  • Največja vrednost uspešne implementacije DevOps je večje zaupanje v dostavo, prepoznavnost in sledljivost dogajanju, tako da lahko hitreje rešite težave.

  • Druga pomembna prednost DevOps je, da ne izgubljamo časa. Usklajevanje ljudi in virov organizacije omogoča hitro uvajanje in posodabljanje. To omogoča programom DevOps, da odpravijo težave, preden se spremenijo v katastrofe.DevOps ustvarja kulturo preglednosti, ki spodbuja osredotočenost in sodelovanje med razvojnimi, operativnimi in varnostnimi skupinami.

CI (nenehna integracija) vScenariji v realnem času DevOps

1. Posamezniki lahko vidijo nenehno vključevanje kontraproduktivno

Člani razvojne skupine imajo različne vloge, odgovornosti in prednostne naloge. Možno je, da je na prvem mestu vodja izdelka uvajanje novih funkcij, vodja projekta pa mora poskrbeti, da bo njihova ekipa izpolnila rok. Programerji bi morda mislili, da jih bodo upočasnili, če se bodo ustavili in odpravili manjšo napako vsakič, ko se bo pojavila. Morda se jim zdi čiščenje zgradbe dodatno breme in jim dodatni napori ne bodo koristili. To lahko ogrozi proces prilagajanja.

Da bi to premagali:

  • Najprej se prepričajte, da je celotna ekipa na krovu, preden sprejmete nenehno integracijo.

  • Tehnični direktorji in vodje skupin morajo članom ekipe pomagati razumeti stroške in koristi stalne integracije.

  • Poudarite, kaj in kdaj bodo koderi imeli koristi, če se boste posvetili drugačni metodi dela, ki zahteva nekoliko več odprtosti in prilagodljivosti.

2. Vključitev CI v vaš obstoječi razvojni tok

Sprejetje CI neizogibno prinaša potrebo po bistveni spremembi nekaterih delov vašega razvojnega poteka dela. Možno je, da razvijalci morda ne bodo popravili poteka dela, če ni pokvarjen. To je mogoče predvsem, če ima vaša ekipa večjo rutino pri izvajanju trenutnega poteka dela.

Če želite spremeniti potek dela, morate to storiti z velikimi previdnostnimi ukrepi. V nasprotnem primeru lahko ogrozi produktivnost razvojne ekipe in tudi kakovost izdelka. Brez zadostne podpore vodstva se razvojna skupina morda neradi loti naloge s takšnimi tveganji.

prednosti in slabosti vdora

Da bi to premagali:

  • Poskrbite, da boste imeli dovolj časa, da bo ekipa razvila svoj novi potek dela. To se naredi, da se izbere prilagodljiva rešitev za neprekinjeno integracijo, ki lahko podpira njihov nov potek dela.

  • Zagotovite jim tudi, da ima podjetje hrbet, tudi če na začetku stvari ne bodo šle prav gladko.

3. Vračanje k nekdanjim preizkusnim navadam

Takojšnji učinek sprejetja stalne integracije je, da bo vaša ekipa pogosteje testirala. Več testov bo torej zahtevalo več testnih primerov, pisanje testnih primerov pa je lahko dolgotrajno. Zato morajo razvijalci svoj čas pogosto razdeliti med odpravljanje napak in pisanje testnih primerov.

Začasno lahko razvijalci prihranijo čas z ročnim testiranjem, dolgoročno pa lahko bolj škodijo. Bolj ko odlašajo s pisanjem testnih primerov, težje bo dohitevati napredek razvoja. V najslabšem primeru se bo vaša skupina na koncu vrnila k staremu postopku testiranja.

Da bi to premagali:

  • Poudariti morate, da bi lahko pisanje testnih primerov od začetka prihranilo veliko časa vaši ekipi in lahko zagotovilo visoko pokritost vašega izdelka s testi.

  • V kulturo vašega podjetja vdelajte tudi idejo, da so testni primeri enako dragocena sredstva kot sama kodna baza.

4. Razvijalci ignorirajo sporočila o napakah

Pogosta težava je, da ko večje ekipe sodelujejo skupaj, količina obvestil o vmesnikih postane izjemna in jih razvijalci začnejo ignorirati in utišati. Zato je možno, da bodo zamudili ustrezne posodobitve.

Lahko privede do stopnje, ko kodirniki razvijejo relativno odpornost na zlomljene gradnje in sporočila o napakah. Dlje ko ignorirajo ustrezna obvestila, dlje se razvijajo brez povratnih informacij v napačno smer. To bi lahko povzročilo velike povratke, izgubo denarja, virov in časa.

Da bi to premagali:

  • Pošiljajte samo kritične posodobitve.

  • Obvestilo pošljite samo ustreznim razvijalcem, ki so odgovorni za njegovo odpravo.

CT (neprekinjeno testiranje) vScenariji v realnem času DevOps

  1. Kako pravilno določiti zahteve

    Če pravilno izpolnite svoje zahteve, je skoraj polovica bitke dobljena. Če torej zelo natančno in natančno razumete zahteve, lahko bolje načrtujete načrte preskusov in dobro pokrivate zahteve.

    Kljub temu številne ekipe porabijo veliko časa in truda za preprosto razjasnitev zahtev. To je zelo pogosta pasta in da bi se temu izognili, lahko ekipe sprejmejo testiranje na podlagi modelov in tehnike, ki temeljijo na vedenju. To pomaga natančno in ustrezno oblikovati testne scenarije.

    Te prakse bodo zagotovo pomagale hitreje odpraviti in odpraviti vrzeli. Omogoča jim tudi, da samodejno ustvarijo več testnih primerov že v zgodnjih fazah šprinta.

  2. Orkestracija cevovodov

    Prednosti stalnega testiranja in neprekinjena dostava so tesno povezane z orkestracijo cevovodov. To neposredno pomeni razumevanje, kako deluje, zakaj deluje, kako analizirati rezultate ter kako in kdaj meriti. Vse je odvisno od cevovoda, zato morate cevovod integrirati z avtomatizacijskim paketom.

    Razlog za to, da se ekipe spopadajo, pa je, da nobena rešitev ne ponuja celotne verige orodij, ki je potrebna za izdelavo cevovoda CD.

    Ekipe morajo običajno iskati koščke sestavljanke, ki so zanje pravi. Ni popolnih orodij, običajno le najboljših orodij, ki omogočajo integracije skupaj z več drugimi orodji. In seveda API, ki omogoča tudi enostavne integracije.

    Skratka, nemogoče je izvajati stalno preskušanje brez hitrosti in zanesljivosti standardiziranega in avtomatiziranega cevovoda.

  3. Razširitev in upravljanje kompleksnosti

    Drug pomemben scenarij je, da postane nenehno testiranje bolj zapleteno, ko se premika v proizvodno okolje. Preizkusi rastejo tako v številu kot tudi v zapletenosti, saj postajajo kode zorenja in okolje vse bolj zapletene.

    Preizkuse morate posodobiti vsakič, ko posodobite različne faze in samodejne skripte. Posledično se celotni čas, potreben za izvajanje testov, prav tako povečuje proti izdaji.

    Rešitev za to je v izboljšani preizkusni orkestraciji, ki zagotavlja pravo količino pokritosti s preizkusi v krajših ciklih sprinta in ekipam omogoča samozavestno izvedbo. V idealnem primeru je treba celoten postopek avtomatizirati s CT, ki se izvaja v različnih fazah. To se naredi z uporabo vrat politike in ročnega posredovanja, dokler koda ne bo potisnjena v produkcijo.

    kako narediti paket v javi
  4. Ustvarjanje zank povratnih informacij

    Brez pogostih zank povratnih informacij na vsaki stopnji razvojnega cikla neprekinjeno testiranje ni mogoče. To je delno razlog, zakaj je CT težko izvesti. Ne potrebujete samo avtomatiziranih testov, temveč tudi vidnost rezultatov in izvedbe testov.

    Tradicionalne zanke povratnih informacij, kot so orodja za beleženje, profili kod in orodja za spremljanje učinkovitosti, niso več učinkovite. Niti ne sodelujejo niti ne zagotavljajo globine vpogleda, potrebnega za odpravljanje težav. Nadzorne plošče v realnem času, ki samodejno generirajo poročila in povratne informacije o celotnem SDLC, pomagajo hitreje sprostiti programsko opremo v proizvodnjo z manjšimi napakami. Dostop do nadzornih plošč v realnem času in dostop za vse člane ekipe pomaga mehanizmu neprekinjenih povratnih informacij.

  5. Pomanjkanje okolja

    Neprekinjeno testiranje preprosto pomeni pogostejše testiranje, kar zahteva pogostejše poseganje v več okolij. To predstavlja ozko grlo, če omenjena okolja niso na voljo v času, ko so potrebna. Nekatera okolja so na voljo prek API-jev, druga pa prek različnih vmesnikov. Nekatera od teh okolij je mogoče zgraditi s sodobno arhitekturo, druga pa z monolitnimi zapuščenimi odjemalskimi / strežniškimi ali mainframe sistemi.

    Toda vprašanje je, kako usklajujete testiranje prek različnih lastnikov okolja? Možno je tudi, da okolja ne bodo vedno vzdrževala in delovala. Odgovor na vse to je Virtualizacija . Z virtualizacijo okolja lahko kodo preizkusite, ne da bi se preveč obremenjevali s področji, ki se ne spreminjajo.Zagotavljanje dostopnosti in dostopnosti okolij na zahtevo z virtualizacijo zagotovo pomaga odstraniti pomembno ozko grlo iz vašega cevovoda.

CD (neprekinjena dostava) vScenariji v realnem času DevOps

  1. Uvajanje traja predolgo

    Distribuirane aplikacije običajno zahtevajo več kot 'kopiranje in lepljenje' datotek na strežnik. Zapletenost se navadno povečuje, če imate farmo strežnikov. Negotovost glede tega, kaj uporabiti, kje in kako, je povsem običajna stvar. Rezultat? Dolge čakalne dobe, da naše artefakte spravimo v naslednje okolje poti, da vse odložimo, testiramo, čas za življenje itd.

    Kaj DevOps prinese na mizo? Skupine za razvoj in informacijsko tehnologijo opredeljujejo postopek uvajanja v brezhibnem sodelovanju. Najprej preverijo, kaj deluje, in nato z avtomatizacijo dvignejo na naslednjo stopnjo, da olajšajo neprekinjeno dostavo. To drastično skrajša čas za uvajanje in tudi utira pot pogostejšim uvajanjem.

  2. Manjkajoči artefakti, skripti in druge odvisnosti

    Po uvedbi nove različice delovnega dela programske opreme pogosto naletimo na napake. To je pogosto posledica manjkajočih knjižnic ali skriptov baze podatkov, ki niso posodobljeni. To je običajno posledica pomanjkanja jasnosti glede odvisnosti, ki jih je treba razviti, in njihove lokacije. Spodbujanje sodelovanja med razvojem in operacijami lahko v večini primerov pomaga rešiti tovrstne težave.

    Ko gre za avtomatizacijo, lahko določite odvisnosti, ki veliko pomagajo pri pospeševanju uvajanja. Orodja za upravljanje konfiguracije, kot so Lutka ali Šef prispevati z dodatno stopnjo opredelitve odvisnosti. Ne moremo določiti samo odvisnosti znotraj naše aplikacije, temveč tudi na ravni infrastrukture in konfiguracije strežnika. Na primer, lahko ustvarimo navidezni stroj za test in ga namestimo / konfiguriramo mačka preden bodo naši artefakti objavljeni.

  3. Neučinkovito spremljanje proizvodnje

Včasih orodja za nadzor konfigurirate tako, da iz proizvodnje ustvarijo veliko nepomembnih podatkov, drugič pa ne dajo dovolj ali sploh nič. Ni definicije, na kaj morate biti pozorni in kakšne so meritve.

Dogovoriti se morate, kaj spremljati in katere podatke pripraviti, nato pa vzpostaviti nadzor. Orodja za upravljanje zmogljivosti aplikacij so v veliko pomoč, če si vaša organizacija lahko privošči, da si ogleda AppDynamics, New Relic in AWS X-Ray.

Podatkovni scenariji DevOps

DevOps je namenjen odpravljanju tveganj, povezanih z razvojem nove programske opreme: analiza podatkov prepozna ta tveganja. Za stalno merjenje in izboljševanje postopka DevOps se mora analitika raztezati po celotnem cevovodu. To daje neprecenljiv vpogled v upravljanje na vseh stopnjah življenjskega cikla razvoja programske opreme.

1. Manj časa za analizo podatkov

Z vsemi podatki, ki so ustvarjeni v danem trenutku, morajo organizacije sprejeti, da ne morejo vsega analizirati. V dnevu preprosto ni dovolj časa - in na žalost roboti še niso dovolj izpopolnjeni, da bi to še lahko storili za nas.

Zato je pomembno ugotoviti, kateri nabori podatkov so najpomembnejši. V večini primerov bo to drugače za vsako organizacijo. Pred potapljanjem torej določite ključne poslovne cilje in cilje. Ti cilji se običajno vrtijo okoli potreb strank - predvsem najbolj dragocenih funkcij, ki so za končne uporabnike najpomembnejše. Za prodajalca je na primer na vrhu seznama analiza, kako promet vpliva na stran za plačilo na spletnem mestu in preizkus, kako deluje.

Nekaj ​​hitrih nasvetov za ugotavljanje, katere podatke je najpomembneje analizirati:

  • Naredite grafikon: Ugotovite, kakšen vpliv bodo imeli izpadi na vaše podjetje, in postavite vprašanja, na primer: »Če X se zlomi , kakšen učinek bo imel na druge funkcije? '

  • Oglejte si zgodovinske podatke: ugotovite, kje so se pojavile težave v preteklosti, in še naprej analizirajte podatke iz testov in gradite, da se ne bo več ponovilo.

2. Težka komunikacija

Danes večina organizacij še vedno deluje z različnimi skupinami in osebami, ki opredeljujejo lastne cilje in uporabljajo lastna orodja in tehnologije. Vsaka ekipa deluje neodvisno, odklopljena od plinovoda in se sestaja z drugimi skupinami samo v fazi integracije.

Ko gre za pogled na širšo sliko in ugotavljanje, kaj deluje in kaj ne deluje, se organizacija trudi priti do ene rešitve. To je zato, ker večinoma zato, ker si vsi ne delijo skupnih podatkov, kar onemogoča analizo.

Da bi odpravili to težavo, prenovite komunikacijski tok, da zagotovite, da vsi sodelujejo v celotnem SDLC, ne samo med integracijskim postopkom.

  • Najprej poskrbite za močno sinhronizacijo meritev DevOps že od samega začetka. Napredek vsake ekipe bi moral biti prikazan na eni sami nadzorni plošči z uporabo istih ključnih kazalnikov uspešnosti (KPI), da bi vodstvo imelo vpogled v celoten postopek. To se naredi tako, da lahko zberejo vse potrebne podatke za analizo, kaj je šlo narobe (ali kaj je uspelo).

  • Poleg začetnega pogovora o metriki bi morala obstajati stalna komunikacija prek sestankov ekipe ali digitalnih kanalov, kot je Slack.

3. Pomanjkanje delovne sile

Če imamo kratko osebje, potrebujemo pametnejša orodja, ki uporabljajo globoko učenje, da vnesemo podatke, ki jih zbiramo, in hitro sprejmemo odločitve. Navsezadnje nihče nima časa, da bi si ogledal vsako posamezno izvedbo preizkusa (in pri nekaterih velikih organizacijah jih je na dan mogoče približno 75.000). Trik je v odpravi hrupa in iskanju pravih stvari, na katere se lahko osredotočite.

Tu lahko pomagata umetna inteligenca in strojno učenje. Številna orodja na trgu danes uporabljajo AI in ML za:

  • Razvijte skripte in teste za premikanje in preverjanje različnih podatkov

  • Poročajte o kakovosti na podlagi predhodno naučenega vedenja

  • Delajte kot odziv na spremembe v realnem času.

S tem smo prišli do konca tega članka o scenarijih DevOps v realnem času.

Zdaj, ko ste razumeli, kaj so DevOpsovi scenariji v realnem času, si oglejte to Edureka, zaupanja vredno podjetje za spletno učenje z mrežo več kot 250.000 zadovoljnih učencev, ki se širijo po vsem svetu. Tečaj Edureka DevOps Certification Training pomaga učencem, da razumejo, kaj je DevOps, in pridobijo strokovno znanje v različnih procesih in orodjih DevOps, kot so Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack in GIT za avtomatizacijo več korakov v SDLC.

Imate vprašanje za nas? Prosimo, navedite to v oddelku za komentarje tegaČlanek o scenarijih DevOps v realnem časuin se bomo oglasili pri vas.