Daudzi no jums, iespējams, zina visas ar to saistītās teorijas . Bet vai jūs zināt, kā īstenot DevOps principus reālajā dzīvē? Šajā emuārā es apspriedīšu DevOps reālā laika scenārijus, kas palīdzēs jums īsi saprast, kā lietas darbojas reāllaikā.
Norādes, kuras es šeit apskatīšuDevOps reāllaika scenāriju rakstsir:
- Kas ir DevOps?
- DevOps atrisinātās problēmas
- CI (nepārtrauktas integrācijas) scenāriji
- CT (nepārtrauktas testēšanas) scenāriji
- CD (nepārtrauktas piegādes) scenāriji
- DevOps datu scenāriji
Tāpēc sāksim ar mūsu pirmo tēmu.
Kas ir DevOps?
DevOps ir programmatūras izstrādes pieeja, kas ietver programmatūras nepārtrauktu attīstību, nepārtrauktu testēšanu, nepārtrauktu integrēšanu, nepārtrauktu ieviešanu un nepārtrauktu uzraudzību visā tā izstrādes dzīves ciklā. Šīs darbības ir iespējamas tikai DevOps, nevis veikls vai ūdenskritums. Tāpēc Facebook un citi labākie uzņēmumi ir izvēlējušies DevOps kā turpmāko ceļu savu biznesa mērķu sasniegšanai.DevOps galvenokārt dod priekšroku augstas kvalitātes programmatūras izstrādei īsākos izstrādes ciklos, kas nodrošina lielāku klientu apmierinātību.
Nākamajā sadaļāDevOps reālā laika scenāriju rakstā mēs aplūkosim dažādas DevOps atrisinātās problēmas.
DevOps atrisinātās problēmas
1. Piegādājiet vērtību klientiem
- DevOps samazina laiku tas nepieciešams, lai sniegtu vērtību klientiem. Cikla laiks no izstrādātāja stāsta / uzdevuma pabeigšanas līdz producēšanai ievērojami samazinās, ļaujot vērtību realizēt pēc iespējas ātrāk.
Vissvarīgākā vērtība, kas tiek realizēta, izmantojot DevOps, ir tā, ka tā ļauj IT organizācijām koncentrēties uz viņu “pamatdarbību” . Noņemot ierobežojumus vērtību plūsmā un automatizējot izvietošanas cauruļvadus, komandas var koncentrēties uz darbībām. Tas palīdz radīt klienta vērtību, nevis tikai pārvietot bitus un baitus. Šīs darbības palielina uzņēmuma ilgtspējīgas konkurences priekšrocības un rada labākus uzņēmējdarbības rezultātus.
2. Samazināts cikla laiks
Iekšēji DevOps ir vienīgais veids, kā panākt veiklību piegādāt drošu kodu ar ieskatiem. Ir svarīgi, lai būtu vārti un labi izstrādāts DevOps process. Piegādājot jaunu versiju, tā var darboties blakus pašreizējai versijai. Varat arī salīdzināt metriku, lai sasniegtu vēlamo ar lietojumprogrammu un veiktspējas rādītājiem.
DevOps virza attīstības komandas nepārtraukta uzlabošana un ātrāki atbrīvošanas cikli . Ja tas tiek izdarīts labi, šis iteratīvais process laika gaitā ļauj vairāk koncentrēties uz lietām, kas patiešām ir svarīgas. Piemēram, lietas, kas lietotājiem rada lielisku pieredzi - un mazāk laika rīku, procesu un tehnoloģiju pārvaldībai.
3. Laiks tirgū
Vissvarīgākā problēma, kas tiek atrisināta, ir procesa sarežģītības samazināšana. Tas ievērojami veicina mūsu biznesa panākumus, saīsinot mūsu laiku tirgū, sniedzot ātru atgriezenisko saiti par funkcijām un padarot mūs atsaucīgākus klientu vajadzībām.
4. Problēmas risināšana
Veiksmīgas DevOps ieviešanas lielākā vērtība ir lielāka uzticēšanās piegādei, redzamība un izsekojamība notiekošajam, lai jūs varētu ātrāk atrisināt problēmas.
Vēl viena svarīga DevOps priekšrocība ir laika netērēšana. Organizācijas darbinieku un resursu saskaņošana ļauj ātri izvietot un atjaunināt. Tas ļauj DevOps programmām novērst problēmas, pirms tās pārvēršas par katastrofām.DevOps rada pārredzamības kultūru, kas veicina mērķtiecību un sadarbību starp attīstības, operāciju un drošības komandām.
KI (nepārtraukta integrācija)DevOps reāllaika scenāriji
1. Indivīdi var redzēt neproduktīvu nepārtrauktas integrācijas procesu
Izstrādes komandas locekļiem ir atšķirīgas lomas, pienākumi un prioritātes. Iespējams, ka produktu vadītāja galvenā prioritāte varētu būt jaunu funkciju palaišana, projekta vadītājam ir jāpārliecinās, ka viņu komanda ievēro termiņu. Programmētāji varētu domāt, ka, pārtraucot labot nelielu kļūdu katru reizi, tas palēnināsies. Viņi, iespējams, uzskata, ka uzbūves tīrība ir papildu slogs, un viņu papildu pūles viņiem nedos labumu. Tas potenciāli var apdraudēt adaptācijas procesu.
Lai to pārvarētu:
Pirmkārt, pārliecinieties, ka visa jūsu komanda ir uz kuģa, pirms veicat nepārtrauktu integrāciju.
CTO un komandas vadītājiem jāpalīdz komandas locekļiem saprast nepārtrauktas integrācijas izmaksas un ieguvumus.
Uzsveriet, ko un kad kodētāji gūs labumu, veltot sevi citai darba metodei, kurai nepieciešama mazliet lielāka atvērtība un elastība.
2. KI integrēšana esošajā attīstības plūsmā
KI pieņemšana neizbēgami rada nepieciešamību pēc būtības mainīt dažas savas attīstības darbplūsmas daļas. Iespējams, ka izstrādātāji, iespējams, nenovērsīs darbplūsmu, ja tā nav salauzta. Tas ir iespējams galvenokārt tad, ja jūsu komandai ir lielāka rutīna pašreizējās darbplūsmas izpildē.
Ja vēlaties mainīt darbplūsmu, tas jādara ar ļoti piesardzību. Pretējā gadījumā tas varētu apdraudēt izstrādes komandas produktivitāti un arī produkta kvalitāti. Bez pietiekama vadības atbalsta izstrādes komanda, iespējams, nedaudz nevēlas veikt uzdevumu ar šādiem riskiem.
Lai to pārvarētu:
Jums jāpārliecinās, vai esat atlicis pietiekami daudz laika savai komandai, lai izstrādātu jauno darbplūsmu. Tas tiek darīts, lai izvēlētos elastīgu nepārtrauktas integrācijas risinājumu, kas var atbalstīt viņu jauno darbplūsmu.
Nodrošiniet viņiem arī to, ka uzņēmumam ir mugura, pat ja sākumā viss varētu nenotikt ļoti gludi.
kas ir java vairākkārtēja mantošana
3. Recidīvs ar bijušajiem testēšanas paradumiem
Nepārtrauktas integrācijas ieviešanas tūlītējais rezultāts ir tas, ka jūsu komanda testēs biežāk. Tāpēc vairākiem testiem būs nepieciešami vairāk testa gadījumu, un testa lietu rakstīšana var būt laikietilpīga. Tādējādi izstrādātājiem bieži ir jāsadala laiks starp kļūdu novēršanu un testa lietu rakstīšanu.
Pagaidām izstrādātāji, iespējams, varēs ietaupīt laiku, manuāli pārbaudot, taču ilgtermiņā tas varētu sāpēt vairāk. Jo vairāk viņi atliks testa lietu rakstīšanu, jo grūtāk būs panākt attīstības gaitu. Sliktākajā gadījumā jūsu komanda var atgriezties pie sava vecā testēšanas procesa.
Lai to pārvarētu:
Jums jāuzsver, ka testa lietu rakstīšana no paša sākuma varētu ietaupīt daudz laika jūsu komandai un nodrošināt augstu produkta testa pārklājumu.
Iekļaujiet arī uzņēmuma kultūrā ideju, ka testa gadījumi ir tikpat vērtīgi līdzekļi kā pati koda bāze.
4. Izstrādātāji, ignorējot kļūdu ziņojumus
Tā ir izplatīta problēma, ka tad, kad lielākas komandas strādā kopā, KI paziņojumu daudzums kļūst milzīgs, un izstrādātāji sāk tos ignorēt un izslēgt. Tāpēc ir iespējams, ka viņi var palaist garām viņiem svarīgos atjauninājumus.
Tas var novest pie tā, ka kodētājiem rodas relatīva imunitāte pret salauztiem būvējumiem un kļūdu ziņojumiem. Jo ilgāk viņi ignorē attiecīgos paziņojumus, jo ilgāk tie tiek izstrādāti bez atsauksmes nepareizā virzienā. Tas potenciāli var izraisīt milzīgu atdošanu, naudas, resursu un laika izšķiešanu.
Lai to pārvarētu:
Jums vajadzētu nosūtīt tikai kritiskus atjauninājumus.
Nosūtiet paziņojumu tikai attiecīgajiem izstrādātājiem, kuri ir atbildīgi par tā labošanu.
CT (nepārtraukta testēšana) iekšāDevOps reāllaika scenāriji
Pareizu prasību iegūšana
Ja jūs pareizi izpildāt savas prasības, gandrīz puse cīņas ir uzvarēta. Tātad, ja jums ir ļoti specifiska un precīza izpratne par prasībām, varat labāk izstrādāt testa plānus un labi aptvert prasības.
Tomēr daudzas komandas tērē daudz laika un pūļu, vienkārši precizējot prasības. Tā ir ļoti izplatīta kļūda, un, lai no tā izvairītos, komandas var pieņemt uz modeļiem balstītas testēšanas un uz uzvedību balstītas attīstības metodes. Tas palīdz precīzi un adekvāti izstrādāt testa scenārijus.
Šī prakse noteikti palīdzēs ātrāk novērst un novērst nepilnības. Turklāt tas ļauj viņiem automātiski radīt vairāk testa gadījumu jau no sprinta sākuma posmiem.
Cauruļvadu orķestrēšana
Nepārtrauktas testēšanas un nepārtraukta piegāde ir cieši saistīti ar cauruļvadu orķestrēšanu. Tas tieši nozīmē saprast, kā tas darbojas, kāpēc tas darbojas, kā analizēt rezultātus un kā un kad mērogot. Viss ir atkarīgs no cauruļvada, un tāpēc tas ir jāintegrē ar automatizācijas komplektu.
Bet komandas iemesls ir tas, ka neviens risinājums nenodrošina pilnīgu rīku ķēdi, kas nepieciešama, lai izveidotu CD cauruļvadu.
Komandām parasti jāmeklē tās pareizās puzles daļas. Nav perfektu rīku, parasti tikai vislabākās šķirnes rīku, kas nodrošina integrāciju kopā ar vairākiem citiem rīkiem. Un, protams, API, kas ļauj arī viegli integrēt.
Īsāk sakot, nav iespējams īstenot nepārtrauktu testēšanu bez standartizēta un automatizēta cauruļvada ātruma un uzticamības.
Sarežģītības palielināšana un pārvaldīšana
Vēl viens svarīgs scenārijs ir tāds, ka nepārtraukta testēšana kļūst sarežģītāka, virzoties uz ražošanas vidi. Testu skaits palielinās, kā arī to sarežģītība kļūst pilnīgāka, jo nobriešanas kods un vide kļūst sarežģītāka.
Testi jāatjaunina katru reizi, kad tiek atjauninātas dažādas fāzes un automatizētie skripti. Tā rezultātā kopējais laiks, kas nepieciešams testu veikšanai, ir tendence palielināties arī izlaišanas laikā.
Risinājums tam ir uzlabota testa orķestrēšana, kas nodrošina pareizu testa pārklājumu īsākos sprinta ciklos un ļauj komandām droši darboties. Ideālā gadījumā viss process ir jā automatizē ar CT, kas jāveic dažādos posmos. Tas tiek darīts, izmantojot politikas vārtus un manuālu iejaukšanos, līdz kods tiek virzīts uz ražošanu.
Atgriezeniskās saites izveidošana
Bez biežas atgriezeniskās saites katrā attīstības cikla posmā nepārtraukta testēšana nav iespējama. Daļēji tas ir iemesls, kāpēc CT ir grūti īstenot. Jums nav nepieciešami tikai automatizēti testi, bet arī pārbaužu rezultātu redzamība un izpilde.
Tradicionālās atgriezeniskās saites, piemēram, mežizstrādes rīki, kodu profilētāji un veiktspējas uzraudzības rīki, vairs nav efektīvi. Ne viņi strādā kopā, ne arī sniedz nepieciešamo ieskatu problēmu novēršanai. Reāllaika informācijas paneļi, kas automātiski ģenerē pārskatus un praktiskas atsauksmes visā SDLC, palīdz ātrāk atbrīvot programmatūru ražošanā ar mazākiem defektiem. Reāllaika piekļuve informācijas paneļiem un piekļuve visiem komandas locekļiem palīdz nepārtrauktas atgriezeniskās saites mehānismam.
Vides trūkums
Nepārtraukta testēšana vienkārši nozīmē testēšanu biežāk, un tas prasa biežāku triecienu vairākās vidēs. Tas rada šauru vietu, ja minētās vides nav vajadzīgajā laikā. Dažas vides ir pieejamas, izmantojot API, un dažas, izmantojot dažādas saskarnes. Dažas no šīm vidēm var izveidot, izmantojot moderno arhitektūru, bet citas ar monolītām mantotajām klientu / serveru vai lieldatoru sistēmām.
Bet šeit ir jautājums, kā jūs koordinējat testēšanu, izmantojot dažādus vides īpašniekus? Ir arī iespējams, ka tie ne vienmēr uztur vidi un darbojas. Atbilde uz to visu ir Virtualizācija . Virtualizējot vidi, jūs varat pārbaudīt kodu, pārāk neuztraucoties par nemainīgām jomām.Vides padarīšana par pieejamu un pieejamu pēc pieprasījuma, izmantojot virtualizāciju, noteikti palīdz novērst ievērojamu vājo vietu no jūsu cauruļvada.
CD (nepārtraukta piegāde) iekšāDevOps reāllaika scenāriji
Izvietošana aizņem pārāk ilgu laiku
Izplatītajām lietojumprogrammām parasti ir nepieciešams vairāk nekā failu “kopēšana un ielīmēšana” serverī. Sarežģītībai ir tendence pieaugt, ja jums ir serveru saimniecība. Neskaidrība par to, ko, kur un kā izvietot, ir diezgan normāla lieta. Rezultāts? Ilgi gaidīšanas laiki, lai mūsu artefakti nonāktu nākamajā maršruta vidē, lai visu aizkavētu, testētu, dzīvotu utt.
Ko DevOps ienes galdā? Izstrādes un IT operāciju komandas nevainojamā sadarbības sesijā nosaka izvietošanas procesu. Pirmkārt, viņi pārbauda, kas darbojas, un pēc tam ar automatizāciju to pārceļ uz nākamo līmeni, lai atvieglotu nepārtrauktu piegādi. Tas krasi samazina izvietošanas laiku un paver ceļu biežākai izvietošanai.
Trūkst artefaktu, skriptu un citu atkarību
Pēc jaunas programmatūras darba versijas izvietošanas mēs bieži sastopamies ar kļūmēm. To bieži izraisa trūkstošo bibliotēku vai datu bāzu skriptu neatjaunināšana. To parasti izraisa skaidrības trūkums par to, kuras atkarības izvietot un to atrašanās vietu. Sadarbības veicināšana starp attīstību un operācijām vairumā gadījumu var palīdzēt atrisināt šāda veida problēmas.
Runājot par automatizāciju, varat definēt atkarības, kas ļoti palīdz paātrināt izvietošanu. Konfigurācijas pārvaldības rīki, piemēram, Leļļu vai Priekšnieks palīdzēt ar papildu atkarību definēšanas līmeni. Mēs varam definēt ne tikai atkarības mūsu lietojumprogrammā, bet arī infrastruktūras un servera konfigurācijas līmenī. Piemēram, mēs varam izveidot virtuālu mašīnu testēšanai un instalēt / konfigurēt runcis pirms mūsu artefaktu publicēšanas.
Neefektīva ražošanas uzraudzība
Dažreiz jūs konfigurējat uzraudzības rīkus tā, lai no ražošanas iegūtu daudz nesvarīgu datu, tomēr citreiz tie neražo pietiekami daudz vai vispār neko. Nav definīcijas par to, kas jums jārūpējas un kāda ir metrika.
Jums ir jāvienojas par to, ko uzraudzīt un kuru informāciju ražot, un pēc tam jāievieš vadīklas. Lietojumprogrammu veiktspējas pārvaldības rīki ir lielisks palīgs, ja jūsu organizācija to var atļauties, apskatot AppDynamics, New Relic un AWS X-Ray.
DevOps datu scenāriji
DevOps ir visu ar jauno programmatūras izstrādi saistīto risku novēršana: Datu analīze identificē šos riskus. Lai nepārtraukti izmērītu un uzlabotu DevOps procesu, analītikai vajadzētu aptvert visu cauruļvadu. Tas sniedz nenovērtējamu ieskatu vadībā visos programmatūras izstrādes dzīves cikla posmos.
1. Mazāk laika datu analizēšanai
Ņemot vērā visus datus, kas tiek ģenerēti attiecīgajā laikā, organizācijām ir jāpieņem, ka tās nevar visu analizēt. Dienā vienkārši nepietiek laika - un diemžēl roboti vēl nav pietiekami sarežģīti, lai to visu paveiktu mūsu vietā.
Šī iemesla dēļ ir svarīgi noteikt, kuras datu kopas ir visnozīmīgākās. Vairumā gadījumu tas katrai organizācijai būs atšķirīgs. Tāpēc pirms ieniršanas nosakiet galvenos uzņēmējdarbības mērķus un mērķus. Parasti šie mērķi ir saistīti ar klientu vajadzībām - galvenokārt visvērtīgākajām īpašībām, kas ir vissvarīgākās galalietotājiem. Piemēram, mazumtirgotājam saraksta augšdaļā ir analizēta, kā datplūsma mijiedarbojas ar vietnes norēķinu lapu, un pārbaudīt, kā tā darbojas aizmugurējā daļā.
Daži īsi padomi, lai noteiktu, kuri dati ir vissvarīgākie analizēšanai:
Izveidojiet diagrammu: nosakiet pārtraukumu ietekmi uz jūsu biznesu, uzdodot šādus jautājumus: “Ja X pārtraukumi , kāda būs tā ietekme uz citām funkcijām? ”
kārtot algoritmu c ++
Apskatiet vēsturiskos datus: nosakiet, kur agrāk ir radušās problēmas, un turpiniet testu un analīzes datu analīzi, lai pārliecinātos, ka tas neatkārtojas.
2. Sarežģīta komunikācija
Mūsdienās lielākā daļa organizāciju joprojām darbojas ar dažādām komandām un personām, identificējot savus mērķus un izmantojot savus rīkus un tehnoloģijas. Katra komanda darbojas neatkarīgi, atvienota no cauruļvada un tiekas ar citām komandām tikai integrācijas posmā.
Kad jāaplūko plašāka aina un jānosaka, kas darbojas un kas nedarbojas, organizācija cenšas nonākt pie viena risinājuma. Tas ir tāpēc, ka galvenokārt tāpēc, ka visi nespēj kopīgot kopējos datus, padarot analīzi neiespējamu.
Lai pārvarētu šo problēmu, pārskatiet komunikācijas plūsmu, lai nodrošinātu, ka visi cilvēki sadarbojas visā SDLC, ne tikai integrācijas procesa laikā.
Pirmkārt, pārliecinieties, ka DevOps metrikā ir spēcīga sinhronizācija no sākuma. Katras komandas progresam jābūt attēlotam vienā informācijas panelī, izmantojot vienus un tos pašus galvenos veiktspējas rādītājus (KPI), lai vadība iegūtu redzamību visā procesā. Tas tiek darīts, lai viņi varētu savākt visus nepieciešamos datus, lai analizētu, kas notika nepareizi (vai kas izdevās).
Papildus sākotnējai metrikas sarunai jābūt pastāvīgai saziņai, izmantojot komandas sanāksmes vai digitālos kanālus, piemēram, Slack.
3. Darbaspēka trūkums
Kad darbiniekiem ir maz darbinieku, mums ir nepieciešami gudrāki rīki, kas izmanto dziļu mācīšanos, lai apkopotu apkopotos datus un ātri pieņemtu lēmumus. Galu galā nevienam nav laika apskatīt katru atsevišķu testa izpildi (un dažām lielām organizācijām noteiktā dienā var būt aptuveni 75 000). Triks ir novērst troksni un atrast pareizās lietas, uz kurām koncentrēties.
Šeit var palīdzēt mākslīgais intelekts un mašīnmācīšanās. Daudzi mūsdienu tirgū esošie rīki izmanto AI un ML, lai veiktu šādas darbības:
Izstrādājiet skriptus un testus dažādu datu pārvietošanai un apstiprināšanai
Ziņojiet par kvalitāti, pamatojoties uz iepriekš iemācīto uzvedību
Darbs, reaģējot uz reāllaika izmaiņām.
Līdz ar to mēs esam nonākuši pie šī raksta par DevOps reālā laika scenārijiem beigām.
Tagad, kad esat sapratis, kas ir DevOps reālā laika scenāriji, pārbaudiet to Autors: Edureka, uzticams tiešsaistes mācību uzņēmums ar vairāk nekā 250 000 apmierinātu izglītojamo tīklu visā pasaulē. Edureka DevOps sertifikācijas apmācības kurss palīdz izglītojamajiem saprast, kas ir DevOps, un iegūt zināšanas dažādos DevOps procesos un rīkos, piemēram, Leļļu, Jenkins, Nagios, Ansible, Chef, Saltstack un GIT vairāku soļu automatizēšanai SDLC.
Vai mums ir jautājums? Lūdzu, pieminējiet to komentāru sadaļāDevOps reāllaika scenāriju rakstsun mēs sazināsimies ar jums.