Paljud teist võivad olla teadlikud kõigist teooriatest, mis on seotud . Kuid kas teate, kuidas DevOpsi põhimõtteid reaalses elus rakendada? Selles blogis käsitlen DevOpsi reaalajas stsenaariume, mis aitavad teil lühidalt mõista, kuidas asjad reaalajas toimivad.
anonüümne klass javas]
Näpunäited, mida ma selles kajastanDevOpsi reaalajas stsenaariumide artikkelon:
- Mis on DevOps?
- DevOps lahendas probleemid
- CI (pidev integreerimine) stsenaariumid
- CT (pidev testimine) stsenaariumid
- CD (pidev kohaletoimetamine) stsenaariumid
- DevOpsi andestsenaariumid
Alustagem siis oma esimesest teemast.
Mis on DevOps?
DevOps on tarkvaraarenduslik lähenemisviis, mis hõlmab tarkvara pidevat arendamist, pidevat testimist, pidevat integreerimist, pidevat juurutamist ja pidevat jälgimist kogu selle arendustsükli vältel. Need tegevused on võimalikud ainult DevOpsis, mitte vilgas või juga. Seetõttu on Facebook ja teised tippettevõtted valinud DevOps'i oma ärieesmärkide edasiliikumiseks.DevOps on eelistatud peamiselt kõrgekvaliteedilise tarkvara arendamiseks lühemate arendustsüklitega, mis toob kaasa suurema klientide rahulolu.
Selle järgmises osasDevOpsi reaalajas stsenaariumide artiklis vaatleme erinevaid DevOpsi lahendatud probleeme.
DevOps lahendas probleemid
1. Pakkuge klientidele väärtust
- DevOps minimeerib aega see võtab klientidele väärtust. Tsükli aeg alates arendaja loo / ülesande valmimisest kuni tootmiseni väheneb märkimisväärselt, võimaldades väärtuse realiseerida võimalikult kiiresti.
Kõige olulisem DevOpsi kaudu realiseeritud väärtus on see, et see võimaldab IT-organisatsioonidel seda teha keskenduda oma põhitegevusele . Väärtuste voos piirangute eemaldamise ja juurutamise torujuhtmete automatiseerimise abil saavad meeskonnad keskenduda tegevustele. See aitab luua kliendi väärtust, mitte lihtsalt bitti ja baite liigutada. Need tegevused suurendavad ettevõtte jätkusuutlikku konkurentsieelist ja loovad paremaid äritulemusi.
2. Vähendatud tsükliaeg
Sisemiselt on DevOps ainus viis, kuidas saavutada teadlikkusega turvalise koodi edastamise oskus. Tähtis on väravate olemasolu ja hästi koostatud DevOps-protsess. Uue versiooni tarnimisel võib see töötada koos praeguse versiooniga. Samuti saate võrrelda mõõdikuid, et saavutada soovitud rakenduse ja toimivuse mõõdikutega.
DevOps juhib arendusmeeskondi pidev täiustamine ja kiiremad vabastamistsüklid . Kui see on hästi tehtud, võimaldab see korduv protsess aja jooksul rohkem keskenduda asjadele, mis tegelikult olulised on. Näiteks asjad, mis loovad kasutajatele suurepäraseid kogemusi - ja vähem aega tööriistade, protsesside ja tehnoloogia haldamiseks.
3. Aeg turule viia
Kõige olulisem lahendatav probleem on protsessi keerukuse vähendamine. See aitab märkimisväärselt kaasa meie edule, lühendades turule jõudmise aega, andes meile kiiret tagasisidet funktsioonide kohta ja muutes klientide vajadustele paremini vastavaks.
4. Probleemide lahendamine
DevOpsi eduka rakendamise suurim väärtus on suurem usaldus toimimise üle, nähtavus ja jälgitavus toimuvaga, nii et saate probleeme kiiremini lahendada.
DevOpsi teine oluline eelis on aja raiskamine. Organisatsiooni inimeste ja ressursside ühtlustamine võimaldab kiiret juurutamist ja värskendamist. See võimaldab DevOpsi programmidel enne katastroofiks muutumist probleemid lahendada.DevOps loob läbipaistvuskultuuri, mis edendab keskendumist ja koostööd arendus-, operatsiooni- ja turvameeskondade vahel.
CI (pidev integreerimine) aastalDevOpsi reaalajas stsenaariumid
1. Üksikisikud võivad pidevat integreerimist näha vastukarva
Arendustiimi liikmetel on erinevad rollid, vastutus ja prioriteedid. Võimalik, et tootejuhi prioriteet võib olla uute funktsioonide käivitamine, projektijuht peab veenduma, et nende meeskond täidab tähtaega. Programmeerijad võivad arvata, et kui nad peatuvad väiksema vea parandamiseks iga kord, siis see aeglustab neid. Nad võivad tunda, et ehitise puhtana hoidmine on neile lisakoormus ja nende täiendavad jõupingutused ei tule neile kasuks. See võib ohustada kohanemisprotsessi.
Sellest ülesaamiseks:
Esiteks veenduge enne pideva integratsiooni vastuvõtmist, et kogu teie meeskond oleks pardal.
CTO-d ja meeskonnajuhid peavad aitama meeskonnaliikmetel mõista pideva integratsiooni kulusid ja eeliseid.
Tooge välja, mida ja millal kooderitele kasu saab, kui pühenduda teistsugusele töömeetodile, mis nõuab natuke rohkem avatust ja paindlikkust.
2. Elutähtsate infrastruktuuride integreerimine olemasolevasse arenguvoogu
CI vastuvõtmine toob paratamatult kaasa vajaduse oma arendustöö voo mõningaid osi sisuliselt muuta. Võimalik, et teie arendajad ei pruugi töövoogu parandada, kui see pole katki. See on võimalik peamiselt siis, kui teie meeskonnal on praeguse töövoo täitmisel suurem rutiin.
Kui soovite töövoogu muuta, peate seda tegema väga ettevaatusabinõudega. Vastasel juhul võib see kahjustada arendustiimi tootlikkust ja ka toote kvaliteeti. Ilma juhtkonna piisava toetuseta võib arendusmeeskond olla pisut vastumeelne selliste riskidega ülesande täitmisel.
Sellest ülesaamiseks:
Peate veenduma, et annate oma meeskonnale piisavalt aega uue töövoo väljatöötamiseks. Seda tehakse selleks, et valida paindlik pidev integreerimislahendus, mis toetab nende uut töövoogu.
Samuti tagage neile, et ettevõttel on seljad, isegi kui asjad ei pruugi alguses väga libedalt minna.
3. Taastumine endiste testimisharjumustega
Pideva integratsiooni kasutuselevõtu kohene mõju on see, et teie meeskond testib sagedamini. Nii et rohkemate testide tegemiseks on vaja rohkem testjuhtumeid ja testjuhtumite kirjutamine võib olla aeganõudev. Seetõttu peavad arendajad sageli oma aja vigade parandamise ja testjuhtumite kirjutamise vahel jagama.
Ajutiselt suudavad arendajad käsitsi testimisega aega kokku hoida, kuid see võib pikas perspektiivis rohkem haiget teha. Mida rohkem nad testijuhtumite kirjutamist edasi lükkavad, seda raskem on arengu edusammudele järele jõuda. Halvimal juhul võib teie meeskond pöörduda tagasi oma vana testimisprotsessi juurde.
Sellest ülesaamiseks:
Peate rõhutama, et testijuhtumite kirjutamine võib algusest peale säästa teie meeskonna jaoks palju aega ja tagada teie toote kõrge katte.
Kinnitage oma ettevõttekultuuri ka idee, et testjuhtumid on sama väärtuslikud varad kui koodibaas ise.
4. Arendajad ignoreerivad veateateid
See on tavaline probleem, et kui suuremad meeskonnad teevad koostööd, muutub CI-teadete hulk valdavaks ja arendajad hakkavad neid ignoreerima ja summutama. Seetõttu on võimalik, et neil võivad puududa nende jaoks olulised värskendused.
See võib viia etappi, kus kodeerijatel tekib suhteline puutumatus katkestatud järkude ja veateadete suhtes. Mida kauem nad asjakohaseid märguandeid eiravad, seda kauem arenevad nad ilma tagasisideteta vales suunas. See võib potentsiaalselt põhjustada suuri tagasilööke, raha, ressursside ja aja raiskamist.
Sellest ülesaamiseks:
Peaksite saatma ainult kriitilisi värskendusi.
Saada teade ainult vastavatele arendajatele, kes vastutavad selle parandamise eest.
CT (pidev testimine) aastalDevOpsi reaalajas stsenaariumid
Nõuete spetsifikatsiooni saamine õige
Kui saate oma nõuded õigeks, võidetakse peaaegu pool lahingust. Nii et kui teil on nõuetest väga konkreetne ja täpne arusaam, saate testiplaanid paremini välja töötada ja nõuded hästi katta.
Kuid paljud meeskonnad kulutavad palju aega ja vaeva lihtsalt nõuete selgitamiseks. See on väga levinud lõks ja selle vältimiseks saavad meeskonnad rakendada mudelipõhiseid testimis- ja käitumispõhiseid arendustehnikaid. See aitab testistsenaariume täpselt ja adekvaatselt kujundada.
Need tavad aitavad kindlasti lünki kiiremini lahendada ja lahendada. Samuti võimaldab see genereerida automaatselt rohkem proovijuhte juba sprindi algusjärgus.
Torujuhtmete orkestratsioon
Pideva testimise ja pidev kohaletoimetamine on tihedalt seotud torujuhtmete orkestratsiooniga. See tähendab otseselt mõistmist, kuidas see töötab, miks see töötab, kuidas tulemusi analüüsida ning kuidas ja millal skaalat muuta. Kõik sõltub torujuhtmest ja seega peate torujuhtme integreerima automaatikakomplektiga.
Kuid põhjus, miks meeskonnad käivad, on see, et ükski lahendus ei paku täielikku tööriistaketti, mis on vajalik CD-gaasijuhtme ehitamiseks.
Võistkonnad peavad tavaliselt otsima neile sobivaid pusletükke. Puuduvad täiuslikud tööriistad, tavaliselt ainult tõu parimad tööriistad, mis pakuksid integreerimisi koos paljude muude tööriistadega. Ja muidugi API, mis võimaldab ka hõlpsat integreerimist.
Lühidalt öeldes on võimatu teostada pidevat testimist ilma standardiseeritud ja automatiseeritud torujuhtme kiiruse ja töökindluseta.
Keerukuse suurendamine ja haldamine
Teine oluline stsenaarium on see, et pidev testimine muutub tootmiskeskkonna poole liikudes keerukamaks. Testide arv kasvab, samuti on nende keerukus küpseva koodi ja keskkonna keerukamaks muutumisega.
Teste peate värskendama iga kord, kui värskendate erinevaid faase ja automatiseeritud skripte. Selle tulemusena kipub testide läbiviimiseks kuluv kogu aeg ka väljalaske suunas pikenema.
Selle lahendus seisneb paranenud testorkestruktsioonis, mis tagab lühikeste sprinditsüklite ajal õige koguse katseid ja võimaldab meeskondadel enesekindlalt toimetada. Ideaalis tuleb kogu protsess automatiseerida, CT viiakse läbi erinevates etappides. Selleks kasutatakse poliitikaväravaid ja käsitsi sekkumist, kuni kood on tootmisse lükatud.
Tagasiside loomine
Ilma sagedaste tagasisidetsükliteta arengutsükli igas etapis pole pidev testimine võimalik. See on osaliselt põhjus, miks CT-d on raske rakendada. Teil pole vaja mitte ainult automatiseeritud teste, vaid ka testitulemuste ja täitmise nähtavust.
Traditsioonilised tagasiside tsüklid, nagu logimise tööriistad, koodiprofiilijad ja jõudluse jälgimise tööriistad, pole enam tõhusad. Nad ei tee koostööd ega paku probleemide lahendamiseks vajalikku põhjalikku ülevaadet. Reaalajas armatuurlauad, mis genereerivad kogu SDLC-s automaatselt aruandeid ja toimivat tagasisidet, aitavad tarkvara väiksemate defektidega kiiremini tootmisse vabastada. Reaalajas juurdepääs armatuurlaudadele ja kõigi meeskonnaliikmete juurdepääs aitab pidevat tagasiside mehhanismi.
Keskkondade puudumine
Pidev testimine tähendab lihtsalt testimist sagedamini ja see nõuab mitme keskkonna sagedamini löömist. See kujutab endast kitsaskohta, kui nimetatud keskkonnad pole vajalikul ajal saadaval. Mõni keskkond on saadaval API-de kaudu ja osa erinevate liideste kaudu. Mõnda neist keskkondadest saab ehitada kaasaegse arhitektuuri abil, teisi aga monoliitsete pärandklientide / serverite või suurarvutite süsteemidega.
Kuid küsimus on selles, kuidas koordineerite testimist erinevate keskkonnaomanike kaudu? Samuti on võimalik, et need ei pruugi alati keskkondi töökorras hoida. Vastus sellele kõigele on Virtualiseerimine . Keskkonda virtualiseerides saate koodi testida, muretsemata liiga palju muutumatute alade pärast.Keskkondade juurdepääsetavaks ja nõudmisel kättesaadavaks muutmine virtualiseerimise kaudu aitab kindlasti eemaldada torujuhtmest olulise kitsaskoha.
CD (pidev kohaletoimetamine) aastalDevOpsi reaalajas stsenaariumid
Juurutamine võtab liiga kaua aega
Hajutatud rakendused nõuavad tavaliselt failide serverisse kopeerimist ja kleepimist. Kui teil on serverite farm, kipub keerukus suurenema. Ebakindlus, mida, kuhu ja kuidas paigutada, on üsna normaalne asi. Tulemus? Pikad ooteajad, et meie esemed jõuaksid marsruudi järgmisse keskkonda, viivitades kõigega, katsetades, elades aega jne.
Mida DevOps lauale toob? Arendus- ja IT-operatsioonide meeskonnad määravad laitmatu koostööseansi käigus juurutusprotsessi. Esiteks kontrollivad nad toimivat ja viivad selle automaatika abil järjepideva tarnimise hõlbustamiseks. See kärbib drastiliselt kasutuselevõtu aega ja sillutab teed ka sagedasemale kasutuselevõtule.
Artefaktid, skriptid ja muud sõltuvused puuduvad
Töötava tarkvara uue versiooni juurutamise järgselt kohtame sageli tõrkeid. Selle põhjuseks on sageli puuduvate teekide või andmebaasiskriptide värskendamata jätmine. Selle põhjuseks on tavaliselt ebaselgus, milliseid sõltuvusi ja nende asukohta rakendada. Arenduse ja operatsioonide vahelise koostöö edendamine võib enamikul juhtudel aidata selliseid probleeme lahendada.
Automatiseerimise osas saate määratleda sõltuvused, mis aitavad palju juurutamist kiirendada. Konfiguratsiooni haldamise tööriistad nagu Nukk või Pealik aidata kaasa sõltuvuste määratlemise lisatasemega. Me ei saa määratleda mitte ainult sõltuvusi oma rakenduses, vaid ka infrastruktuuri ja serveri konfiguratsiooni tasandil. Näiteks saame testi jaoks luua virtuaalse masina ja installida / konfigureerida kiisu enne meie esemete avaldamist.
Ebaefektiivne tootmise seire
Mõnikord konfigureerite seiretööriistad viisil, mis toodab tootmisel palju ebaolulisi andmeid, kuid teinekord ei tooda need piisavalt või üldse mitte midagi. Puudub määratlus selle kohta, mida peate hoolitsema ja millised on mõõdikud.
Peate kokku leppima, mida jälgida ja millist teavet toota, ning seejärel juhtnupud paika panna. Rakenduse jõudluse haldamise tööriistad on suureks abiks, kui teie organisatsioon saab endale lubada, et heidaks pilgu AppDynamics, New Relic ja AWS X-Ray.
DevOpsi andestsenaariumid
DevOps seisneb uue tarkvaraarendusega seotud riskide kõrvaldamises: andmete analüüs tuvastab need riskid. DevOpsi protsessi pidevaks mõõtmiseks ja täiustamiseks peaks analüütika hõlmama kogu torustikku. See annab juhtkonnale hindamatu ülevaate tarkvaraarenduse elutsükli kõigis etappides.
1. Vähem aega andmete analüüsimiseks
Kõigi andmete põhjal, mis igal ajahetkel genereeritakse, peavad organisatsioonid nõustuma, et nad ei saa seda kõike analüüsida. Päevas pole lihtsalt piisavalt aega - ja kahjuks pole robotid veel piisavalt keerukad, et seda kõike meie jaoks veel teha.
Seetõttu on oluline kindlaks teha, millised andmekogumid on kõige olulisemad. Enamasti on see iga organisatsiooni jaoks erinev. Nii et enne sukeldumist määrake ettevõtte peamised eesmärgid ja eesmärgid. Tavaliselt keerlevad need eesmärgid klientide vajaduste ümber - peamiselt kõige väärtuslikumad funktsioonid, mis on lõppkasutajatele kõige olulisemad. Näiteks jaemüüja jaoks on loendi ülaosas analüüsimine, kuidas liiklus suhtleb saidi kassas olevaga ja testides, kuidas see toimib.
Mõned kiired näpunäited analüüsitavate andmete tuvastamiseks:
Koostage diagramm: tehke kindlaks, milline on katkestuste mõju teie ettevõttele, esitades küsimusi, näiteks: „Kui X puruneb , millist mõju avaldab see teistele funktsioonidele? '
Vaadake ajaloolisi andmeid: tehke kindlaks, kus on probleeme varem tekkinud, ja jätkake testide ja analüüside andmete analüüsimist, et neid enam ei korduks.
2. Raske suhtlemine
Tänapäeval töötab enamik organisatsioone endiselt erinevate meeskondade ja isikutega, kes tuvastavad oma eesmärgid ning kasutavad oma tööriistu ja tehnoloogiaid. Iga meeskond tegutseb iseseisvalt, on gaasijuhtmest lahti ühendatud ja kohtub teiste meeskondadega ainult integreerumise etapis.
java erinevus hashmapi ja hashtable'i vahel
Mis puutub laiema pildi vaatamisse ja selle tuvastamisse, mis töötab ja mis ei tööta, siis organisatsioon üritab jõuda ühe lahenduseni. Selle põhjuseks on enamasti see, et kõik ei suuda üldandmeid jagada, mis muudab analüüsi võimatuks.
Selle probleemi lahendamiseks vaadake üle kommunikatsioonivoog, tagamaks, et kõik teevad koostööd kogu SDLC-s, mitte ainult integratsiooniprotsessi ajal.
Kõigepealt veenduge, et DevOps-i mõõdikutes oleks algusest peale tugev sünkroonimine. Iga meeskonna edusammud tuleks kuvada ühes juhtpaneelil, kasutades samu peamisi jõudlusnäitajaid (KPI), et juhtkond saaks kogu protsessi nähtavaks. Seda tehakse selleks, et nad saaksid koguda kõik vajalikud andmed, et analüüsida, mis valesti läks (või mis õnnestus).
Esialgse mõõdikute vestluse kõrval peaks olema pidev suhtlus meeskonna koosolekute või selliste digitaalsete kanalite kaudu nagu Slack.
3. Tööjõu puudus
Kui töötajaid on vähe, vajame nutikamaid tööriistu, mis kasutavad põhjalikku õppimist kogutavate andmete sisestamiseks ja kiireks otsustamiseks. Lõppude lõpuks pole kellelgi aega iga testi täitmist vaadata (ja mõne suure organisatsiooni puhul võib antud päeval olla umbes 75 000). Trikk on müra kõrvaldamine ja õigete asjade leidmine, millele keskenduda.
Siit saavad abi tehisintellekt ja masinõpe. Paljud tänapäeval turul olevad tööriistad kasutavad tehisintellekti ja ML-d näiteks:
Erinevate andmete teisaldamiseks ja valideerimiseks töötage välja skriptid ja testid
Aruande kvaliteedi kohta, mis põhineb varem õpitud käitumisel
Töö reaalajas toimuvate muutuste korral.
Nii oleme sellega jõudnud DevOpsi reaalajas stsenaariume käsitleva artikli lõppu.
Nüüd, kui olete aru saanud, mis on DevOpsi reaalajas stsenaariumid, vaadake seda autor Edureka, usaldusväärne veebiõppeettevõte, mille võrgustik koosneb enam kui 250 000 rahulolevast õppijast ja mis levib üle kogu maailma. Edureka DevOpsi sertifitseerimiskoolitus aitab õppijatel mõista, mis on DevOps, ning omandada teadmisi mitmesuguste DevOpsi protsesside ja tööriistade kohta, nagu Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack ja GIT SDLC mitme etapi automatiseerimiseks.
Kas teil on meile küsimus? Palun mainige seda selle kommentaaride jaotisesDevOpsi reaalajas stsenaariumide artikkelja me pöördume teie poole.