Scenáre reálneho času DevOps - Vedzte, čo sa stane v reálnom čase



Tento blog hovorí o scenároch DevOps v reálnom čase, aby vám pomohol porozumieť výzvam, s ktorými sa môžete v reálnom čase stretnúť, a ako ich prekonať.

Mnoho z vás by mohlo vedieť o všetkých teóriách, ktoré s tým súvisia . Viete však, ako implementovať princípy DevOps v reálnom živote? V tomto blogu sa budem venovať scenárom DevOps Real Time, ktoré vám pomôžu získať krátke pochopenie toho, ako veci fungujú v reálnom čase.

Ukazovatele, ktorým sa v tomto budem venovaťČlánok Scenáre reálneho času DevOpssú:





Začnime teda prvou témou.

Čo je to DevOps?

scenáre - scenáre reálneho času - EdurekaDevOps je prístup k vývoju softvéru, ktorý zahŕňa nepretržitý vývoj, nepretržité testovanie, nepretržitú integráciu, nepretržité nasadenie a nepretržité monitorovanie softvéru počas celého jeho životného cyklu. Tieto aktivity sú možné iba v DevOps, nie v Agile alebo vo vodopáde. Preto si Facebook a ďalšie špičkové spoločnosti vybrali DevOps ako cestu vpred pre svoje obchodné ciele.DevOps sa uprednostňuje hlavne pri vývoji vysokokvalitného softvéru v kratších vývojových cykloch, čo vedie k väčšej spokojnosti zákazníkov.



V ďalšej časti tohtoV článku Scenáre reálneho času DevOps sa pozrieme na rôzne problémy, ktoré DevOps rieši.

Problémy vyriešené programom DevOps

1. Poskytnite hodnotu zákazníkom

ako urobiť varovanie v javascript
  • DevOps minimalizuje čas je potrebné poskytnúť hodnotu zákazníkom. Čas cyklu od dokončenia príbehu / úlohy vývojárom až do výrazného zníženia produkcie, čo umožňuje čo najrýchlejšiu realizáciu hodnoty.
  • Najdôležitejšou hodnotou realizovanou prostredníctvom DevOps je, že umožňuje IT organizáciám zamerať na svoje „kľúčové“ obchodné aktivity . Tým, že sa odstránia obmedzenia v rámci hodnotového toku a automatizujú sa kanály nasadenia, môžu sa tímy sústrediť na aktivity. To pomáha skôr pri vytváraní hodnoty pre zákazníka ako pri presúvaní bitov a bajtov. Tieto činnosti zvyšujú udržateľnú konkurenčnú výhodu spoločnosti a vytvárajú lepšie obchodné výsledky.



2. Skrátený čas cyklu

  • Interne DevOps je jediný spôsob, ako dosiahnuť svižnosť pri poskytovaní zabezpečeného kódu so štatistikami. Je dôležité mať brány a dobre prepracovaný proces DevOps. Keď dodávate novú verziu, môže bežať vedľa seba s aktuálnou verziou. Môžete tiež porovnať metriky, aby ste dosiahli to, čo ste chceli, s metrikami aplikácií a výkonu.

  • DevOps poháňa vývojové tímy smerom k neustále zlepšovanie a rýchlejšie cykly uvoľňovania . Ak bude tento iteračný proces vykonaný dobre, umožní mu viac sa časom sústrediť na veci, na ktorých skutočne záleží. Napríklad veci, ktoré používateľom vytvárajú vynikajúce zážitky - a menej času na správu nástrojov, procesov a technológií.

3. Čas uvedenia na trh

Najdôležitejším problémom, ktorý sa rieši, je zníženie zložitosti procesu. To významne prispieva k nášmu obchodnému úspechu, pretože skracuje náš čas uvedenia na trh, poskytuje nám rýchlu spätnú väzbu o funkciách a umožňuje nám lepšie reagovať na potreby našich zákazníkov.

4. Riešenie problému

  • Najväčšou hodnotou úspešnej implementácie DevOps je vyššia dôvera v doručenie, viditeľnosť a sledovateľnosť toho, čo sa deje, takže problémy môžete vyriešiť rýchlejšie.

  • Ďalšou dôležitou výhodou DevOps nie je plytvanie časom. Zarovnanie ľudí a zdrojov organizácie umožňuje rýchle nasadenie a aktualizácie. To umožňuje programom DevOps opraviť problémy skôr, ako sa stanú katastrofami.DevOps vytvára kultúru transparentnosti, ktorá podporuje zameranie a spoluprácu medzi vývojovými, operačnými a bezpečnostnými tímami.

CI (kontinuálna integrácia) vScenáre reálneho času DevOps

1. Jednotlivci môžu vidieť nepretržitú integráciu kontraproduktívnu

Členovia vývojového tímu majú rôzne úlohy, zodpovednosti a priority. Je možné, že prvou prioritou produktového manažéra môže byť uvádzanie nových funkcií na trh, manažér projektu sa musí ubezpečiť, že ich tím dodržuje termín. Programátori si môžu myslieť, že ak prestanú opravovať menšie chyby zakaždým, keď sa vyskytnú, spomalí ich to. Môžu mať pocit, že udržiavať stavbu v čistote, je pre nich ďalšou záťažou a nebude im prínosom pre ich ďalšie úsilie. To môže potenciálne ohroziť adaptačný proces.

Aby ste to prekonali:

  • Najskôr sa uistite, že je na palube celý váš tím, než začnete s nepretržitou integráciou.

  • CTO a vedúci tímov musia členom tímu pomôcť porozumieť nákladom a výhodám spojeným s integráciou.

  • Zvýraznite, čo a kedy prinesie kóderom úžitok, pretože sa môžu venovať inej pracovnej metóde, ktorá si vyžaduje trochu viac otvorenosti a flexibility.

2. Integrácia CI do vášho existujúceho vývojového toku

Prijatie CI nevyhnutne prichádza s potrebou zásadnej zmeny niektorých častí vášho vývojového pracovného toku. Je možné, že vaši vývojári nemusia opraviť pracovný tok, ak nie je narušený. To je možné hlavne vtedy, ak má váš tím pri vykonávaní svojho súčasného pracovného toku väčšiu rutinu.

Ak chcete zmeniť pracovný tok, musíte to urobiť s veľkou opatrnosťou. V opačnom prípade by to mohlo ohroziť produktivitu vývojového tímu a tiež kvalitu produktu. Bez dostatočnej podpory vedenia by sa vývojový tím mohol zdráhať prevziať úlohu s takýmito rizikami.

Aby ste to prekonali:

  • Musíte sa ubezpečiť, že svojmu tímu poskytnete dostatok času na vývoj nového pracovného toku. To sa deje za účelom výberu flexibilného riešenia nepretržitej integrácie, ktoré môže podporovať ich nový pracovný tok.

  • Zaistite im tiež, aby im spoločnosť bola chrbtom, aj keď to zo začiatku nemusí ísť úplne hladko.

3. Relaps k predchádzajúcim testovacím návykom

Okamžitým dôsledkom zavedenia nepretržitej integrácie je, že váš tím bude testovať častejšie. Viac testov teda bude vyžadovať viac testovacích prípadov a písanie testovacích prípadov môže byť časovo náročné. Preto musia vývojári často deliť čas medzi opravu chýb a písanie testovacích prípadov.

Dočasne by vývojári mohli ušetriť čas manuálnym testovaním, ale z dlhodobého hľadiska by to mohlo viac ublížiť. Čím viac budú otáľať pri písaní testovacích prípadov, tým ťažšie bude doháňať pokrok vo vývoji. V najhoršom prípade by sa váš tím mohol vrátiť k starému procesu testovania.

Aby ste to prekonali:

  • Musíte zdôrazniť, že písanie testovacích prípadov od začiatku by mohlo vášmu tímu ušetriť veľa času a zaistiť vysoké testovacie pokrytie vášho produktu.

  • Vložte tiež do svojej firemnej kultúry myšlienku, že testovacie prípady sú rovnako hodnotným majetkom ako samotný kódový základ.

4. Vývojári ignorujú chybové správy

Je častým problémom, že keď väčšie tímy spolupracujú, množstvo upozornení CI začne byť ohromujúce a vývojári ich začnú ignorovať a stlmiť. Preto je možné, že by im mohli chýbať aktualizácie, ktoré sa ich týkajú.

Môže to viesť do štádia, keď si kóderi vytvoria relatívnu imunitu voči rozbitým zostavám a chybovým správam. Čím dlhšie ignorujú príslušné oznámenia, tým dlhšie sa vyvíjajú bez spätnej väzby nesprávnym smerom. To by mohlo potenciálne spôsobiť obrovské vrátenie peňazí, plytvanie peniazmi, zdrojmi a časom.

čo je továreň v angularjs

Aby ste to prekonali:

  • Mali by ste posielať iba dôležité aktualizácie.

  • Oznámenie pošlite iba príslušným vývojárom, ktorí majú na starosti jeho opravu.

CT (nepretržité testovanie) vScenáre reálneho času DevOps

  1. Správna špecifikácia požiadaviek

    Ak správne splníte svoje požiadavky, takmer polovica bitky je vyhratá. Takže ak veľmi presne a presne rozumiete požiadavkám, môžete lepšie navrhnúť plány testov a dobre pokryť požiadavky.

    Mnoho tímov napriek tomu trávi veľa času a úsilia jednoduchým objasňovaním požiadaviek. Toto je veľmi častá nástraha a aby sa tomu zabránilo, môžu tímy prijať techniky testovania založené na modeloch a techniky vývoja založené na správaní. To pomáha navrhnúť scenáre testovania presne a adekvátne.

    Tieto postupy určite pomôžu rýchlejšie vyriešiť a vyriešiť medzery. Umožňuje im to tiež automaticky generovať viac testovacích prípadov hneď v počiatočných fázach šprintu.

  2. Pipeline Orchestration

    Výhody nepretržitého testovania a nepretržité doručovanie sú úzko spojené s organizáciou plynovodu. To priamo znamená porozumieť tomu, ako to funguje, prečo to funguje, ako analyzovať výsledky a ako a kedy škálovať. Všetko závisí od potrubia, a preto musíte potrubie integrovať do automatizačného balíka.

    Tímy sa však domnievajú, že ani jedno riešenie neposkytuje kompletný reťazec nástrojov, ktorý je potrebný na vybudovanie potrubia CD.

    Tímy musia zvyčajne hľadať kúsky skladačky, ktoré sú pre nich správne. Neexistujú žiadne dokonalé nástroje, zvyčajne iba tie najkvalitnejšie, ktoré by poskytovali integráciu spolu s mnohými ďalšími nástrojmi. A samozrejme API, ktoré umožňuje tiež ľahkú integráciu.

    Stručne povedané, je nemožné implementovať nepretržité testovanie bez rýchlosti a spoľahlivosti štandardizovaného a automatizovaného potrubia.

  3. Škálovanie a riadenie zložitosti

    Ďalším dôležitým scenárom je, že neustále testovanie sa stáva zložitejším, keď sa posúva smerom k produkčnému prostrediu. Počet testov, ako aj ich zložitosť rastie s tým, že zrejúci kód a prostredie sa stávajú zložitejšími.

    Testy musíte aktualizovať zakaždým, keď aktualizujete rôzne fázy a automatizované skripty. Výsledkom je, že celkový čas potrebný na vykonanie testov sa tiež zvyčajne zvyšuje s uvoľnením.

    Riešenie spočíva v zdokonalenej orchestrácii testov, ktorá poskytuje správne množstvo testovacieho pokrytia v kratších cykloch šprintu a umožňuje tímom poskytovať spoľahlivé výsledky. V ideálnom prípade musí byť celý proces automatizovaný tým, že CT sa vykonáva v rôznych fázach. To sa deje pomocou bezpečnostných brán a manuálneho zásahu, až kým sa kód nedostane do výroby.

  4. Vytváranie slučiek spätnej väzby

    Bez častých cyklov spätnej väzby v každej fáze vývojového cyklu nie je možné nepretržité testovanie. To je čiastočne dôvod, prečo je CT ťažké implementovať. Nepotrebujete iba automatické testy, ale aj viditeľnosť výsledkov a vykonanie testu.

    Tradičné slučky spätnej väzby, ako sú protokolovacie nástroje, profilovače kódu a nástroje na sledovanie výkonu, už nie sú účinné. Spolupracujú ani neposkytujú hĺbku pohľadu potrebnú na vyriešenie problémov. Panely v reálnom čase, ktoré generujú správy automaticky a akčná spätná väzba v rámci celého SDLC, pomáha rýchlejšie vydávať softvér do výroby s menšími chybami. Prístup k informačným panelom v reálnom čase a prístup pre všetkých členov tímu pomáha mechanizmom nepretržitej spätnej väzby.

  5. Nedostatok prostredí

    Nepretržité testovanie jednoducho znamená častejšie testovanie, čo si vyžaduje častejšie zasiahnutie viacerých prostredí. Toto predstavuje úzke miesto, ak uvedené prostredia nie sú k dispozícii v čase, keď sú potrebné. Niektoré prostredia sú k dispozícii prostredníctvom rozhraní API a iné prostredníctvom rôznych rozhraní. Niektoré z týchto prostredí je možné vytvoriť pomocou modernej architektúry, zatiaľ čo iné s monolitickými staršími systémami klient / server alebo sálovými počítačmi.

    Otázkou však je, ako koordinujete testovanie prostredníctvom rôznych vlastníkov prostredia? Je tiež možné, že nemusia vždy udržiavať prostredie v prevádzke. Odpoveď na toto všetko je Virtualizácia . Virtualizáciou prostredia môžete testovať kód bez toho, aby ste sa príliš starali o oblasti, ktoré sa nemenia.Sprístupnenie a sprístupnenie prostredí na požiadanie prostredníctvom virtualizácie určite pomôže odstrániť z vášho potrubia významné úzke miesto.

CD (priebežné doručovanie) vScenáre reálneho času DevOps

  1. Nasadenie trvá príliš dlho

    Distribuované aplikácie zvyčajne vyžadujú viac ako 'kopírovanie a vkladanie' súborov na server. Zložitosť má tendenciu stúpať, ak máte farmu serverov. Neistota ohľadom toho, čo, kde a ako nasadiť, je celkom normálna vec. Výsledok? Dlhé čakacie doby, kým sa naše artefakty dostanú do ďalšieho prostredia trasy, k oneskoreniu všetkého, testovaniu, dobe života atď.

    Čo prináša DevOps na stôl? Vývojové a operačné tímy IT definujú proces nasadenia v bezúhonnej spolupráci. Najskôr overia, čo funguje, a potom ich pomocou automatizácie posunú na ďalšiu úroveň, ktorá uľahčí nepretržité doručovanie. Toto drasticky skracuje čas nasadenia a tiež pripravuje cestu pre častejšie nasadenie.

    čo je parameter v table
  2. Chýbajú artefakty, skripty a iné závislosti

    Často sa stretávame s poruchami po nasadení novej verzie funkčnej časti softvéru. Je to často spôsobené tým, že chýbajúce knižnice alebo databázové skripty sa neaktualizujú. Je to zvyčajne spôsobené nejasnosťou, ktoré závislosti sa majú nasadiť, a ich umiestnením. Podpora spolupráce medzi vývojom a prevádzkou môže pomôcť vyriešiť tieto druhy problémov vo väčšine prípadov.

    Pokiaľ ide o automatizáciu, môžete definovať závislosti, ktoré veľmi pomáhajú pri urýchľovaní nasadenia. Nástroje na správu konfigurácie ako Bábka alebo Náčelník prispieť ďalšou úrovňou definície závislostí. Môžeme definovať nielen závislosti v rámci našej aplikácie, ale aj na úrovni infraštruktúry a konfigurácie servera. Napríklad môžeme vytvoriť virtuálny stroj na test a nainštalovať / nakonfigurovať kocúr pred zverejnením našich artefaktov.

  3. Neúčinné sledovanie výroby

Niekedy konfigurujete monitorovacie nástroje spôsobom, ktorý produkuje veľa nepodstatných údajov z výroby, inokedy však neprodukujú dostatok alebo vôbec nič. Neexistuje žiadna definícia toho, o čo sa musíte starať, a o aké metriky sa jedná.

Musíte sa dohodnúť, čo monitorovať a ktoré informácie produkovať, a potom zaviesť kontroly. Nástroje na správu výkonu aplikácií sú veľkým pomocníkom, ak si to vaša organizácia môže dovoliť, napríklad AppDynamics, New Relic a AWS X-Ray.

Dátové scenáre DevOps

Cieľom DevOps je eliminovať riziká spojené s vývojom nového softvéru: Analýza dát tieto riziká identifikuje. Na neustále meranie a vylepšovanie procesu DevOps by sa mala analýza rozprestierať po celom potrubí. Poskytuje to neoceniteľné štatistiky pre správu vo všetkých fázach životného cyklu vývoja softvéru.

1. Menej času na analýzu údajov

So všetkými údajmi, ktoré sa generujú kedykoľvek, musia organizácie akceptovať, že nemôžu všetko analyzovať. Denne jednoducho nie je dosť času - a bohužiaľ, roboty nie sú dosť sofistikované na to, aby to všetko ešte celkom zvládli.

Z tohto dôvodu je dôležité určiť, ktoré súbory údajov sú najvýznamnejšie. Vo väčšine prípadov to bude pre každú organizáciu odlišné. Pred ponorom si teda určte kľúčové obchodné zámery a zámery. Tieto ciele sa zvyčajne točia okolo potrieb zákazníkov - predovšetkým tých najcennejších funkcií, ktoré sú pre koncových používateľov najdôležitejšie. Napríklad pre maloobchodníka je v hornej časti zoznamu analýza toho, ako prevádzka interaguje so stránkou platby na webe a testovanie jej fungovania v serveri back-end.

Niekoľko rýchlych tipov na identifikáciu údajov, ktoré je najdôležitejšie analyzovať:

  • Vytvorte graf: Zistite, aký dopad budú mať výpadky na vaše podnikanie. Položte otázky typu: „Ak X sa zlomí , aký vplyv to bude mať na ďalšie funkcie? “

  • Pozrite sa na historické údaje: Zistite, kde v minulosti nastali problémy, a pokračujte v analýze údajov z testov a zostavujte ich, aby sa tak už nestalo.

2. Zložitá komunikácia

V súčasnosti väčšina organizácií stále pracuje s rôznymi tímami a osobami, ktoré identifikujú svoje vlastné ciele a využívajú svoje vlastné nástroje a technológie. Každý tím koná nezávisle, odpojený od plynovodu a s ostatnými tímami sa stretáva iba počas fázy integrácie.

Pokiaľ ide o pohľad na širší obraz a identifikáciu toho, čo nefunguje a nefunguje, organizácia sa snaží dospieť k jednému riešeniu. Je to tak preto, lebo všetci zlyhávajú v zdieľaní celkových údajov, čo znemožňuje analýzu.

Na prekonanie tohto problému prepracujte komunikačný tok, aby ste zabezpečili spoluprácu všetkých v rámci SDLC, nielen počas procesu integrácie.

  • Najskôr sa uistite, či sú metriky DevOps od začiatku dostatočne synchronizované. Pokrok každého tímu by mal byť zobrazený na jednom jedinom paneli, ktorý využíva rovnaké kľúčové ukazovatele výkonu (KPI) a poskytuje tak zviditeľneniu riadenia celého procesu. To sa deje preto, aby mohli zhromažďovať všetky potrebné údaje na analýzu toho, čo sa pokazilo (alebo čo sa podarilo).

  • Okrem počiatočnej konverzácie o metrikách by mala existovať neustála komunikácia prostredníctvom tímových stretnutí alebo digitálnych kanálov, ako je Slack.

3. Nedostatok pracovných síl

Ak máme nízky počet zamestnancov, potrebujeme inteligentnejšie nástroje, ktoré využívajú hlboké učenie sa na zhromažďovanie údajov, ktoré zhromažďujeme, a rýchle prijímanie rozhodnutí. Koniec koncov, nikto nemá čas sa pozrieť na každé jedno vykonanie testu (a pre niektoré veľké organizácie ich môže byť v daný deň asi 75 000). Trik spočíva v odstránení hluku a nájdení správnych vecí, na ktoré sa treba sústrediť.

Tu môžu pomôcť umelá inteligencia a strojové učenie. Mnoho nástrojov na dnešnom trhu využíva AI a ML na vykonávanie týchto činností:

  • Vyvíjajte skripty a testy na presun a overovanie rôznych údajov

  • Správa o kvalite na základe predtým naučeného správania

  • Pracujte ako reakcia na zmeny v reálnom čase.

Týmto sme sa teda dostali na koniec tohto článku o scenároch reálneho času DevOps.

Teraz, keď ste pochopili, čo sú scenáre reálneho času DevOps, sa pozrite na toto autor: Edureka, dôveryhodná online vzdelávacia spoločnosť so sieťou viac ako 250 000 spokojných študentov rozmiestnených po celom svete. Kurz certifikácie EdOkaka DevOps Certification Training pomáha študentom pochopiť, čo je DevOps, a získať odborné znalosti v rôznych procesoch a nástrojoch DevOps, ako sú Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack a GIT na automatizáciu viacerých krokov v SDLC.

Máte na nás otázku? Uveďte to, prosím, v sekcii komentárovČlánok Scenáre reálneho času DevOpsa ozveme sa vám.