Daugelis iš jūsų gali žinoti apie visas su tuo susijusias teorijas . Bet ar žinote, kaip „DevOps“ principus įgyvendinti realiame gyvenime? Šiame tinklaraštyje aptarsiu „DevOps“ realaus laiko scenarijus, kurie padės jums trumpai suprasti, kaip viskas veikia realiuoju laiku.
Nurodymai, kuriuos aš apžvelgsiu šiuo klausimu„DevOps“ realaus laiko scenarijų straipsnisyra:
- Kas yra „DevOps“?
- „DevOps“ išspręstos problemos
- KI (nuolatinės integracijos) scenarijai
- KT (nuolatinio testavimo) scenarijai
- CD (nuolatinio pristatymo) scenarijai
- „DevOps“ duomenų scenarijai
Taigi pradėkime nuo pirmosios temos.
transformacijos informatikoje su pavyzdžiu
Kas yra „DevOps“?
„DevOps“ yra programinės įrangos kūrimo metodas, apimantis nuolatinį programinės įrangos kūrimą, nuolatinį testavimą, nuolatinį integravimą, nuolatinį diegimą ir nuolatinį stebėjimą per visą jos kūrimo gyvavimo ciklą. Ši veikla yra įmanoma tik „DevOps“, o ne judrus ar krioklys. Štai kodėl „Facebook“ ir kitos geriausios įmonės pasirinko „DevOps“ kaip kelią į priekį savo verslo tikslams pasiekti.„DevOps“ yra ypač pageidaujama kuriant aukštos kokybės programinę įrangą per trumpesnius kūrimo ciklus, o tai lemia didesnį klientų pasitenkinimą.
Kitame šio skirsnyje„DevOps“ realaus laiko scenarijų straipsnyje apžvelgsime įvairias „DevOps“ problemas.
„DevOps“ išspręstos problemos
1. Pateikite vertę klientams
- „DevOps“ sumažina laiką kad klientai gautų vertę. Ciklo laikas nuo kūrėjo pasakojimo / užduoties atlikimo iki kūrimo žymiai sumažėja, o tai leidžia kuo greičiau realizuoti vertę.
Svarbiausia vertybė, realizuota per „DevOps“, yra tai, kad tai leidžia IT organizacijoms sutelkti dėmesį į savo „pagrindinę“ verslo veiklą . Pašalindami apribojimus vertės sraute ir automatizuodami diegimo vamzdynus, komandos gali sutelkti dėmesį į veiklą. Tai padeda sukurti kliento vertę, o ne tik perkelti bitus ir baitus. Ši veikla padidina tvarų įmonės konkurencinį pranašumą ir sukuria geresnius verslo rezultatus.
2. Sumažintas ciklo laikas
„DevOps“ yra vienintelis būdas pasiekti judrumą saugiam kodui pateikti su įžvalgomis. Svarbu turėti vartus ir gerai parengtą „DevOps“ procesą. Kai pateikiate naują versiją, ji gali veikti kartu su dabartine versija. Taip pat galite palyginti metriką, kad pasiektumėte to, ko norėjote, su programos ir našumo metrika.
„DevOps“ skatina kūrėjų komandas nuolatinis tobulinimas ir greitesni paleidimo ciklai . Gerai atlikus šį kartotinį procesą, laikui bėgant, galima daugiau dėmesio skirti dalykams, kurie iš tikrųjų yra svarbūs. Tokie dalykai, kurie sukuria puikią patirtį vartotojams - ir mažiau laiko valdyti įrankius, procesus ir technologijas.
3. Laikas į rinką
Svarbiausia spręstina problema yra proceso sudėtingumo sumažinimas. Tai labai prisideda prie mūsų verslo sėkmės, nes sutrumpėja laikas į rinką, greitai pateikiama atsiliepimų apie funkcijas ir mes galime labiau reaguoti į klientų poreikius.
4. Problemos sprendimas
Didžiausia sėkmingo „DevOps“ diegimo vertė yra didesnis pasitikėjimas pristatymu, matomumas ir atsekamumas tam, kas vyksta, kad galėtumėte greičiau išspręsti problemas.
Kitas svarbus „DevOps“ pranašumas - laiko švaistymas negaišta. Organizacijos žmonių ir išteklių suderinimas leidžia greitai diegti ir atnaujinti. Tai leidžia „DevOps“ programoms išspręsti problemas, kol jos netapo nelaimėmis.„DevOps“ sukuria skaidrumo kultūrą, kuri skatina susitelkimą ir bendradarbiavimą tarp plėtros, operacijų ir saugos komandų.
KI (nuolatinė integracija)„DevOps“ realaus laiko scenarijai
1. Asmenys gali matyti neproduktyvią nuolatinę integraciją
Kūrimo komandos nariai turi skirtingus vaidmenis, atsakomybę ir prioritetus. Gali būti, kad pirmas produkto vadovo prioritetas gali būti naujų funkcijų paleidimas, projektų vadovas turi įsitikinti, kad jų komanda laikosi nustatyto termino. Programuotojai gali pagalvoti, kad jei jie sustos ištaisyti nedidelę klaidą kaskart, tai paspartins. Jie gali pajusti, kad pastato švarumas yra papildoma našta jiems ir jiems nebus naudinga jų papildomos pastangos. Tai gali pakenkti prisitaikymo procesui.
Norėdami tai įveikti:
Pirmiausia įsitikinkite, kad laive yra visa jūsų komanda, prieš priimdami nuolatinę integraciją.
CTO ir komandos vadovai turi padėti komandos nariams suprasti nuolatinės integracijos išlaidas ir naudą.
Pabrėžkite, kas ir kada bus naudinga programuotojams, jei atsidursite kitam darbo metodui, kuriam reikia šiek tiek daugiau atvirumo ir lankstumo.
2. KI integravimas į esamą plėtros srautą
Priėmus KI neišvengiamai reikia iš esmės pakeisti kai kurias savo kūrimo eigos dalis. Gali būti, kad jūsų kūrėjai gali neištaisyti darbo eigos, jei ji nėra sugadinta. Tai įmanoma daugiausia tuo atveju, jei jūsų komanda turi didesnę rutiną vykdydama dabartinę darbo eigą.
Jei norite pakeisti darbo eigą, turite tai padaryti labai atsargiai. Priešingu atveju tai gali pakenkti kūrėjų komandos produktyvumui ir produkto kokybei. Neturėdama pakankamos vadovybės paramos, kūrėjų komanda gali būti šiek tiek nenori atlikti užduoties su tokia rizika.
Norėdami tai įveikti:
Turite būti tikri, kad skiriate pakankamai laiko savo komandai sukurti naują darbo eigą. Tai daroma siekiant pasirinkti lankstų nuolatinės integracijos sprendimą, kuris galėtų palaikyti jų naują darbo eigą.
Taip pat įsitikinkite, kad įmonė turi nugarą, net jei pradžioje viskas gali būti ne taip sklandžiai.
3. Atsinaujinimas prie buvusių bandymų įpročių
Tiesioginis nuolatinės integracijos poveikis yra tai, kad jūsų komanda išbandys dažniau. Taigi, norint atlikti daugiau bandymų, reikės daugiau bandomųjų atvejų, o testų rašymas gali užtrukti. Taigi kūrėjams dažnai reikia paskirstyti laiką tarp klaidų taisymo ir bandomųjų atvejų rašymo.
Laikinai kūrėjai gali sutaupyti laiko rankiniu būdu bandydami, tačiau ilgainiui tai gali pakenkti labiau. Kuo daugiau jie vilks testų rašymą, tuo sunkiau bus pasivyti kūrimo pažangą. Blogiausiu atveju jūsų komanda gali grįžti prie savo senojo testavimo proceso.
Norėdami tai įveikti:
Turite pabrėžti, kad bandomųjų atvejų rašymas nuo pat pradžių gali sutaupyti daug laiko jūsų komandai ir užtikrinti aukštą jūsų produkto bandomąją aprėptį.
Be to, įtvirtinkite savo įmonės kultūroje idėją, kad bandomieji atvejai yra toks pat vertingas turtas kaip pati kodų bazė.
4. Kūrėjai, ignoruojantys klaidų pranešimus
Dažna problema yra ta, kad kai didesnės komandos dirba kartu, KI pranešimų skaičius tampa didžiulis, o kūrėjai pradeda juos ignoruoti ir nutildyti. Todėl gali būti, kad jie gali praleisti jiems aktualius naujinimus.
Tai gali sukelti etapą, kai programuotojai sukuria santykinį atsparumą sugadintoms versijoms ir klaidų pranešimams. Kuo ilgiau jie ignoruoja atitinkamus pranešimus, tuo ilgiau jie vystosi be grįžtamojo ryšio neteisinga linkme. Tai gali sukelti didžiulį grąžinimą, pinigų, išteklių ir laiko švaistymą.
Norėdami tai įveikti:
Turėtumėte siųsti tik kritinius naujinius.
Siųskite pranešimą tik atitinkamiems kūrėjams, kurie yra atsakingi už jo taisymą.
KT (nuolatinis testavimas) į„DevOps“ realaus laiko scenarijai
Gauti Reikalavimai Specifikacijos teisė
Jei teisingai atitiksite savo reikalavimus, laimėsite beveik pusę mūšio. Taigi, jei turite labai konkretų ir tikslų supratimą apie reikalavimus, galite geriau sukurti bandymų planus ir gerai aprėpti reikalavimus.
Tačiau daugelis komandų praleidžia daug laiko ir pastangų, kad tik paaiškintų reikalavimus. Tai yra labai dažna spąstai ir to išvengdami, komandos gali pritaikyti modeliais pagrįstus testavimo ir elgesio skatinamus kūrimo metodus. Tai padeda tiksliai ir adekvačiai sukurti bandymų scenarijus.
Ši praktika tikrai padės greičiau pašalinti ir pašalinti spragas. Be to, tai leidžia jiems automatiškai generuoti daugiau bandymų atvejų nuo pat ankstyvojo sprinto etapo.
Vamzdynų orkestravimas
Nuolatinio bandymo ir nepertraukiamas pristatymas yra glaudžiai susiję su dujotiekio orkestru. Tai tiesiogiai reiškia supratimą, kaip jis veikia, kodėl jis veikia, kaip analizuoti rezultatus ir kaip bei kada keisti mastelį. Viskas priklauso nuo dujotiekio, taigi reikia dujotiekį integruoti į automatikos rinkinį.
Tačiau priežastis, kodėl komandos vargsta, yra ta, kad nė vienas sprendimas nepateikia visos įrankių grandinės, reikalingos kompaktinių diskų vamzdynui sukurti.
Komandos paprastai turi ieškoti tinkamų galvosūkio dalių. Nėra tobulų įrankių, paprastai tik geriausių įrankių, kurie suteiktų integraciją kartu su daugeliu kitų įrankių. Žinoma, API, kuri taip pat leidžia lengvai integruotis.
skirtumas tarp perkrovos ir nepaisymo „Java“
Trumpai tariant, neįmanoma atlikti nuolatinių bandymų be standartizuoto ir automatizuoto dujotiekio greičio ir patikimumo.
Sudėtingumo didinimas ir valdymas
Kitas svarbus scenarijus yra tai, kad nuolatinis testavimas tampa sudėtingesnis, nes jis pereina prie gamybos aplinkos. Testų skaičius tampa vis sudėtingesnis, nes brandinimo kodas ir aplinka tampa vis sudėtingesni.
Testus turite atnaujinti kiekvieną kartą, kai atnaujinate skirtingas fazes ir automatinius scenarijus. Todėl bendras bandymams atlikti reikalingas laikas taip pat linkęs ilgėti leidimo link.
To sprendimas yra patobulintas bandymų orkestravimas, užtikrinantis reikiamą bandymų aprėptį per trumpesnius sprinto ciklus ir suteikiantis komandoms galimybę pasitikėti savimi. Idealiu atveju visas procesas turi būti automatizuotas atliekant KT įvairiais etapais. Tai daroma naudojant politikos vartus ir rankinį įsikišimą, kol kodas bus perkeltas į gamybą.
Grįžtamojo ryšio kūrimas
Be dažnų grįžtamojo ryšio ciklų kiekviename kūrimo ciklo etape nuolatinis testavimas neįmanomas. Tai iš dalies yra priežastis, kodėl KT sunku įgyvendinti. Jums reikia ne tik automatizuotų testų, bet ir matomumo testo rezultatams bei vykdymo.
Tradicinės grįžtamojo ryšio linijos, tokios kaip registravimo įrankiai, kodų profiliai ir našumo stebėjimo įrankiai, nebėra veiksmingos. Nei jie dirba kartu, nei teikia išsamią informaciją, reikalingą problemoms išspręsti. Realaus laiko prietaisų skydeliai, automatiškai generuojantys ataskaitas ir veikiantys atsiliepimai per visą SDLC, padeda greičiau išleisti programinę įrangą su mažesniais defektais. Realaus laiko prieiga prie informacijos suvestinių ir visų komandos narių prieiga padeda nuolatinio grįžtamojo ryšio mechanizmui.
Aplinkų trūkumas
Nuolatinis testavimas reiškia tiesiog testavimą dažniau, o tam reikia dažniau pataikyti į kelias aplinkas. Tai yra kliūtis, jei minėtos aplinkos nėra prieinamos tuo metu, kai jos reikalingos. Kai kurios aplinkos yra prieinamos per API, o kitos - per įvairias sąsajas. Kai kurias iš šių aplinkų galima sukurti naudojant šiuolaikinę architektūrą, o kitas - su monolitinėmis senomis kliento / serverio ar pagrindinio kompiuterio sistemomis.
Tačiau čia kyla klausimas, kaip jūs koordinuojate testavimą per įvairius aplinkos savininkus? Taip pat gali būti, kad jie ne visada palaiko ir veikia aplinką. Atsakymas į visa tai yra Virtualizacija . Virtualizuodami aplinką, galite išbandyti kodą per daug nesijaudindami dėl sričių, kurios nesikeičia.Padarius aplinką prieinamą ir prieinamą pagal pareikalavimą naudojant virtualizaciją, be abejo, bus pašalinta didelė kliūtis iš jūsų vamzdyno.
CD (nuolatinis pristatymas) į„DevOps“ realaus laiko scenarijai
Diegimas trunka per ilgai
Paskirstytoms programoms paprastai reikia daugiau nei „nukopijuoti ir įklijuoti“ failus į serverį. Sudėtingumas didėja, jei turite serverių ūkį. Neaiškumas, ką, kur ir kaip dislokuoti, yra gana įprastas dalykas. Rezultatas? Ilgas laukimo laikas, kad mūsų artefaktai patektų į kitą maršruto aplinką, kad viskas vėluotų, bandymai, laikas gyventi ir t. T.
Ką „DevOps“ pateikia ant stalo? Kūrimo ir IT operacijų komandos apibrėžia diegimo procesą nepriekaištingo bendradarbiavimo sesijos metu. Pirmiausia jie patikrina, kas veikia, ir tada perkelia į kitą lygį su automatizavimu, kad palengvintų nepertraukiamą pristatymą. Tai smarkiai sutrumpina dislokavimo laiką, taip pat atveria kelią dažniau dislokuoti.
Trūksta artefaktų, scenarijų ir kitų priklausomybių
Mes dažnai susiduriame su gedimais įdiegus naują veikiančios programinės įrangos versiją. Tai dažnai lemia tai, kad trūksta bibliotekų ar duomenų bazių scenarijų, kurie nėra atnaujinami. Dažniausiai tai lemia nepakankamas aiškumas, kokias priklausomybes dislokuoti ir jų vietą. Plėtojimo ir operacijų bendradarbiavimo skatinimas daugeliu atvejų gali padėti išspręsti tokio pobūdžio problemas.
Kalbant apie automatizavimą, galite apibrėžti priklausomybes, kurios labai padeda spartinti diegimą. Konfigūracijos valdymo įrankiai, pvz Lėlė arba Vyriausiasis prisidėti apibrėžiant papildomą priklausomybių lygį. Mes galime apibrėžti ne tik priklausomybes savo programoje, bet ir infrastruktūros bei serverio konfigūracijos lygiu. Pavyzdžiui, mes galime sukurti virtualią mašiną bandymui ir įdiegti / konfigūruoti runas prieš paskelbiant mūsų dirbinius.
Neefektyvus gamybos stebėjimas
Kartais stebėjimo įrankius sukonfigūruojate taip, kad būtų gaunama daug nesusijusių duomenų iš gamybos, tačiau kitais atvejais jie negamina pakankamai arba iš viso nieko. Nėra apibrėžimo, ką reikia prižiūrėti ir kokia yra metrika.
Turite susitarti, ką stebėti ir kokią informaciją pateikti, tada įdiegti valdiklius. Programos našumo valdymo įrankiai yra puiki pagalba, jei jūsų organizacija gali sau leisti tai pažvelgti į „AppDynamics“, „New Relic“ ir „AWS X-Ray“.
„DevOps“ duomenų scenarijai
„DevOps“ tikslas yra pašalinti riziką, susijusią su naujos programinės įrangos kūrimu: Duomenų analizė nustato šias rizikas. Norint nuolat matuoti ir tobulinti „DevOps“ procesą, analizė turėtų apimti visą planą. Tai suteikia neįkainojamų įžvalgų valdymui visuose programinės įrangos kūrimo gyvavimo ciklo etapuose.
1. Mažiau laiko analizuoti duomenis
Turėdamos visus bet kuriuo metu generuojamus duomenis, organizacijos turi sutikti, kad negali viso to analizuoti. Dienos metu tiesiog nepakanka laiko - ir, deja, robotai dar nėra pakankamai rafinuoti, kad visa tai darytų mums.
Dėl šios priežasties svarbu nustatyti, kurie duomenų rinkiniai yra reikšmingiausi. Daugeliu atvejų tai bus skirtinga kiekvienai organizacijai. Taigi prieš nardydami nustatykite pagrindinius verslo tikslus ir tikslus. Paprastai šie tikslai yra susiję su klientų poreikiais - pirmiausia vertingiausiomis savybėmis, kurios yra svarbiausios galutiniams vartotojams. Pavyzdžiui, mažmenininkui sąrašo viršuje yra analizė, kaip srautas sąveikauja su svetainės kasos puslapiu, ir bandymas, kaip jis veikia vidinėje pusėje.
Keli greiti patarimai, kaip nustatyti svarbiausius duomenis, kuriuos reikia analizuoti:
Sudarykite diagramą: nustatykite pertraukimų poveikį jūsų verslui, užduokite tokius klausimus: „Jei X pertraukos , kokį poveikį jis turės kitoms funkcijoms? “
Peržiūrėkite istorinius duomenis: nustatykite, kur praeityje iškilo problemų, ir toliau analizuokite bandymų ir kūrimo duomenis, kad įsitikintumėte, jog tai nepasikartos.
2. Sunkus bendravimas
Šiandien dauguma organizacijų vis dar dirba su skirtingomis komandomis ir asmenimis, nustatydamos savo tikslus ir naudodamos savo įrankius bei technologijas. Kiekviena komanda veikia savarankiškai, atjungta nuo dujotiekio ir susitinka su kitomis komandomis tik integracijos etape.
Kai reikia pažvelgti į didesnį vaizdą ir nustatyti, kas veikia ir kas neveikia, organizacija stengiasi rasti vieną sprendimą. Taip yra todėl, kad visi nesugeba pasidalinti bendrais duomenimis, todėl analizė yra neįmanoma.
Norėdami išspręsti šią problemą, patikrinkite komunikacijos srautą, kad visi bendradarbiautų SDLC, o ne tik integracijos proceso metu.
Pirmiausia įsitikinkite, kad „DevOps“ metrika yra gerai sinchronizuojama nuo pat pradžios. Kiekvienos komandos pažanga turėtų būti rodoma vienoje informacijos suvestinėje, naudojant tuos pačius pagrindinius veiklos rodiklius (KPI), kad valdymas matytų visą procesą. Tai daroma tam, kad jie galėtų surinkti visus reikalingus duomenis, kad galėtų išanalizuoti, kas nutiko ne taip (ar kas pavyko).
Be pirminio metrikos pokalbio, turėtų būti nuolat bendraujama per komandos susitikimus ar skaitmeninius kanalus, pvz., „Slack“.
3. Darbo jėgos trūkumas
Kai mums trūksta darbuotojų, mums reikia protingesnių įrankių, kurie giliai mokytųsi, kad būtų galima surinkti duomenis ir greitai priimti sprendimus. Juk niekas neturi laiko pažvelgti į kiekvieną bandymo vykdymą (o kai kurioms didelėms organizacijoms per dieną gali būti apie 75 000). Apgaulė yra pašalinti triukšmą ir rasti tinkamus dalykus, į kuriuos reikia sutelkti dėmesį.
Čia gali padėti dirbtinis intelektas ir mašininis mokymasis. Daugelis šiandien rinkoje esančių įrankių naudoja AI ir ML tokiems dalykams atlikti:
Kurkite scenarijus ir testus, kad galėtumėte perkelti ir patvirtinti skirtingus duomenis
kaip naudotis „Google“ debesies platforma
Pranešimas apie kokybę, remiantis anksčiau išmoktu elgesiu
Dirbkite reaguodami į realaus laiko pokyčius.
Taigi, mes baigėme šį straipsnį apie „DevOps“ realaus laiko scenarijus.
Dabar, kai supratote, kokie yra „DevOps“ realaus laiko scenarijai, patikrinkite tai sukūrė patikima internetinė mokymosi įmonė „Edureka“, turinti daugiau nei 250 000 patenkintų besimokančiųjų tinklą visame pasaulyje. „Edureka DevOps“ sertifikavimo mokymo kursas padeda besimokantiesiems suprasti, kas yra „DevOps“, ir įgyti patirties įvairiuose „DevOps“ procesuose ir įrankiuose, pvz., „Puppet“, „Jenkins“, „Nagios“, „Ansible“, „Chef“, „Saltstack“ ir „GIT“, skirtuose automatizuoti kelis SDLC veiksmus.
Turite mums klausimą? Prašau paminėti tai komentarų skiltyje„DevOps“ realaus laiko scenarijų straipsnisir mes su jumis susisieksime.