DevOps realtidsscenarier - vet vad som händer i realtid



Den här bloggen berättar om realtidsscenarierna för DevOps för att hjälpa dig att förstå de utmaningar du kan stöta på i realtid och hur du kan övervinna dem.

Många av er kanske känner till alla teorier relaterade till . Men vet du hur du implementerar DevOps-principer i verkliga livet? I den här bloggen kommer jag att diskutera DevOps realtidsscenarier som hjälper dig att få en kort förståelse för hur saker fungerar i realtid.

De tips som jag kommer att täcka i dettaArtikel om DevOps realtidsscenarierär:





Så låt oss börja med vårt första ämne.

Vad är DevOps?

devops-devops realtidsscenarier-EdurekaDevOps är ett programvaruutvecklingssätt som involverar kontinuerlig utveckling, kontinuerlig testning, kontinuerlig integration, kontinuerlig installation och kontinuerlig övervakning av programvaran under hela dess utvecklingslivscykel. Dessa aktiviteter är endast möjliga i DevOps, inte Agile eller vattenfall. Det är därför Facebook och andra toppföretag har valt DevOps som vägen framåt för sina affärsmål.DevOps föredras främst för att utveckla högkvalitativ mjukvara i kortare utvecklingscykler vilket resulterar i större kundnöjdhet.



I nästa avsnitt av dettaDevOps Real Time Scenarios-artikel kommer vi att ta en titt på de olika problemen som löses av DevOps.

Problem som löses av DevOps

1. Leverera värde till kunder

  • DevOps minimerar tiden det krävs för att leverera värde till kunderna. Cykeltiden från utvecklarens slutförande av en berättelse / uppgift tills produktionen minskar avsevärt, vilket gör att värdet kan realiseras så snabbt som möjligt.
  • Det viktigaste värdet som uppnås genom DevOps är att det tillåter IT-organisationer att fokusera på deras 'kärnverksamheter' . Genom att ta bort begränsningar inom värdeströmmen och automatisera distributionsledningar kan team fokusera på aktiviteterna. Detta hjälper till att skapa kundvärde snarare än att bara flytta bitar och byte. Dessa aktiviteter ökar ett företags hållbara konkurrensfördel och skapar bättre affärsresultat.



2. Minskad cykeltid

  • Internt är DevOps det enda sättet att uppnå smidigheten att leverera säker kod med insikter. Det är viktigt att ha grindar och en väl utformad DevOps-process. När du levererar en ny version kan den köras sida vid sida med den aktuella versionen. Du kan också jämföra mätvärden för att uppnå vad du ville med applikations- och prestandamätvärden.

  • DevOps driver utvecklingsteam mot kontinuerlig förbättring och snabbare frigöringscykler . Om det görs bra tillåter den iterativa processen mer fokus över tiden på de saker som verkligen betyder något. Såsom saker som skapar bra upplevelser för användarna - och mindre tid på att hantera verktyg, processer och teknik.

3. Dags att marknadsföra

Det viktigaste problemet som löses är minskning av processens komplexitet. Detta bidrar avsevärt till vår affärsframgång genom att förkorta vår tid på marknaden, ge oss snabb feedback om funktioner och göra oss mer lyhörda för våra kunders behov.

4. Problemlösning

  • Det största värdet av framgångsrik DevOps-implementering är högre förtroende för leverans, synlighet och spårbarhet till vad som händer, så att du kan lösa problem snabbare.

  • En annan viktig fördel med DevOps är inte att slösa bort tid. Genom att anpassa en organisations människor och resurser möjliggörs snabba distributioner och uppdateringar. Detta gör det möjligt för DevOps-program att åtgärda problem innan de förvandlas till katastrofer.DevOps skapar en öppenhetskultur som främjar fokus och samarbete mellan utveckling, drift och säkerhetsteam.

CI (kontinuerlig integration) iDevOps-scenarier i realtid

1. Individer kan se kontinuerlig integration kontraproduktivt

Medlemmar i ett utvecklingsteam har olika roller, ansvarsområden och prioriteringar. Det är möjligt att produktchefens första prioritet kan vara att lansera nya funktioner, projektledare måste se till att deras team uppfyller deadline. Programmerare kanske tror att om de slutar fixa ett mindre fel varje gång det inträffar kommer det att sakta ner dem. De kan känna att det är en extra börda för dem att hålla byggnaden ren och de kommer inte att dra nytta av deras extra ansträngningar. Detta kan potentiellt äventyra anpassningsprocessen.

För att övervinna detta:

  • Först och främst, se till att hela teamet är ombord innan du antar kontinuerlig integration.

  • CTO: er och teamledare måste hjälpa teammedlemmarna att förstå kostnaderna och fördelarna med kontinuerlig integration.

  • Markera vad och när kodare kommer att gynnas genom att ägna sig åt en annan arbetsmetod som kräver lite mer öppenhet och flexibilitet.

2. Integrera CI i ditt befintliga utvecklingsflöde

Att anta CI kommer oundvikligen med behovet av att i huvudsak ändra vissa delar av ditt utvecklingsarbetsflöde. Det är möjligt att dina utvecklare kanske inte fixar arbetsflödet om det inte går sönder. Detta är möjligt främst om ditt team har en större rutin i att utföra sitt nuvarande arbetsflöde.

Om du vill ändra arbetsflödet måste du göra det med stora försiktighetsåtgärder. I annat fall kan det äventyra utvecklingsteamets produktivitet och även produktens kvalitet. Utan tillräckligt stöd från ledarskapet kan utvecklingsteamet vara lite ovilligt att utföra en uppgift med sådana risker.

pmi-acp värt det

För att övervinna detta:

  • Du måste se till att du ger tillräckligt med tid för ditt team att utveckla sitt nya arbetsflöde. Detta görs för att välja en flexibel lösning för kontinuerlig integration som kan stödja deras nya arbetsflöde.

  • Se också till att företaget har ryggen även om det kanske inte går så smidigt i början.

3. Återfall till de tidigare testvanorna

Den omedelbara effekten av att anta kontinuerlig integration är att ditt team kommer att testa oftare. Så fler tester kommer att behöva fler testfall och att skriva testfall kan vara tidskrävande. Därför måste utvecklare ofta dela sin tid mellan att fixa buggar och skriva testfall.

Tillfälligt kan utvecklare spara tid genom att testa manuellt, men det kan skada mer på lång sikt. Ju mer de fördröjer att skriva testfall, desto svårare blir det att komma ikapp med utvecklingen. I värsta fall kan ditt team sluta gå tillbaka till sin gamla testprocess.

För att övervinna detta:

  • Du måste betona att det att skriva testfall från början kan spara mycket tid för ditt team och kan garantera hög testtäckning av din produkt.

  • Bädda också in idén i din företagskultur att testfall är lika värdefulla tillgångar som själva kodbasen.

4. Utvecklare som ignorerar felmeddelanden

Det är ett vanligt problem att när större team arbetar tillsammans blir mängden CI-meddelanden överväldigande och utvecklare börjar ignorera dem och dempa dem. Därför är det möjligt att de missar de uppdateringar som är relevanta för dem.

Det kan leda till ett stadium där kodare utvecklar en relativ immunitet mot trasiga konstruktioner och felmeddelanden. Ju längre de ignorerar relevanta meddelanden, desto längre utvecklas de utan feedback i fel riktning. Detta kan potentiellt orsaka enorma återbetalningar, slöseri med pengar, resurser och tid.

För att övervinna detta:

  • Du ska bara skicka kritiska uppdateringar.

  • Skicka endast meddelandet till respektive utvecklare som ansvarar för att fixa det.

CT (kontinuerlig testning) iDevOps-scenarier i realtid

  1. Få rätt kravspecifikation

    Om du förstår dina krav så är nästan hälften av striden vunnit. Så om du har en mycket specifik och korrekt förståelse av kraven kan du utforma testplaner bättre och täcka kraven väl.

    Ändå spenderar många lag mycket tid och ansträngning för att helt enkelt klargöra kraven. Detta är en mycket vanlig fallgrop och för att undvika detta kan team anta modellbaserad testning och beteendedriven utvecklingsteknik. Detta hjälper till att utforma testscenarier korrekt och tillräckligt.

    Dessa metoder hjälper definitivt till att lösa och lösa luckorna snabbare. Det gör det också möjligt för dem att generera fler testfall automatiskt från de tidiga stadierna av en sprint.

  2. Pipeline Orchestration

    Fördelarna med kontinuerlig testning och kontinuerlig leverans är nära knutna till orkestrering av rörledningar. Detta betyder direkt att förstå hur det fungerar, varför det fungerar, hur man analyserar resultaten och hur och när man ska skala. Allt beror på rörledningen och därför måste du integrera rörledningen med automatiseringssviten.

    Men anledningen till att team fumlar är att ingen enskild lösning ger den kompletta verktygskedjan som krävs för att bygga en CD-pipeline.

    Lag måste vanligtvis söka efter pusselbitarna som är korrekta för dem. Det finns inga perfekta verktyg, vanligtvis bara de bästa verktygen, som ger integrationer tillsammans med flera andra verktyg. Och naturligtvis ett API som också möjliggör enkla integrationer.

    Kort sagt, det är omöjligt att genomföra kontinuerlig testning utan hastigheten och tillförlitligheten hos en standardiserad och automatiserad pipeline.

  3. Skala upp och hantera komplexitet

    Ett annat viktigt scenario är att kontinuerlig testning blir mer komplex när den rör sig mot produktionsmiljön. Testerna växer i antal såväl som komplexiteten med mognadskoden och miljön blir mer komplex.

    Du måste uppdatera tester varje gång du uppdaterar olika faser och automatiserade skript. Som ett resultat tenderar den totala tiden det tar att köra testerna också att öka mot utgivningen.

    Lösningen för detta ligger i förbättrad testorkestrering som ger rätt mängd täckning i kortare sprintcykler och gör det möjligt för lag att leverera säkert. Helst måste hela processen automatiseras med CT som utförs i olika steg. Detta görs genom att använda policygrindar och manuellt ingripande, tills koden skjuts till produktion.

  4. Skapa feedback loopar

    Utan frekventa återkopplingsslingor i varje steg i utvecklingscykeln är det inte möjligt att testa kontinuerligt. Detta är delvis anledningen till att CT är svårt att implementera. Du behöver inte bara automatiserade tester, utan du behöver också synlighet i testresultaten och utförandet.

    Traditionella återkopplingsslingor som loggningsverktyg, kodprofiler och verktyg för övervakning av prestanda är inte effektiva längre. Varken de arbetar tillsammans eller ger den djup insikt som krävs för att lösa problem. Realtidsinstrumentpaneler som genererar rapporter automatiskt och återkopplingsbar feedback över hela SDLC hjälper till att släppa programvara snabbare i produktion med mindre defekter. Realtidstillträde till instrumentpaneler och åtkomst för alla teammedlemmar hjälper den kontinuerliga feedbackmekanismen.

  5. Brist på miljöer

    Kontinuerlig testning betyder helt enkelt att testa oftare och det kräver att träffa flera miljöer oftare. Detta utgör en flaskhals om nämnda miljöer inte är tillgängliga vid den tidpunkt de krävs. Vissa miljöer är tillgängliga via API: er och andra via olika gränssnitt. Vissa av dessa miljöer kan byggas med modern arkitektur medan andra har monolitiska äldre klienter / server eller stordatorer.

    Men frågan här är hur samordnar du testning genom olika miljöägare? Det är också möjligt att de inte alltid kan hålla miljön igång. Svaret på allt detta är Virtualisering . Genom att virtualisera miljön kan du testa koden utan att oroa dig för mycket för områden som är oförändrade.Att göra miljöerna tillgängliga och tillgängliga på begäran genom virtualisering hjälper säkert till att ta bort en betydande flaskhals från din pipeline.

CD (kontinuerlig leverans) iDevOps-scenarier i realtid

  1. Driften tar för lång tid

    Distribuerade applikationer kräver normalt mer än att 'kopiera och klistra in' filer till en server. Komplexiteten tenderar att öka om du har en server med gårdar. Osäkerhet om vad man ska distribuera, var och hur är en ganska normal sak. Resultatet? Långa väntetider för att få våra artefakter till nästa miljö på vägen för att försena allt, test, tid att leva etc.

    Vad tar DevOps till bordet? Utvecklings- och IT-driftsteam definierar en distributionsprocess i en oskuldlig samarbetssession. Först verifierar de vad som fungerar och tar sedan det till nästa nivå med automatisering för att underlätta kontinuerlig leverans. Detta minskar tidpunkten för distribution drastiskt, det banar också väg för mer frekventa distributioner.

  2. Saknade artefakter, skript och andra beroenden

    Vi stöter ofta på fel efter utplaceringen av en ny version av ett arbetsstycke. Detta beror ofta på att saknade bibliotek eller databasskript inte uppdateras. Detta orsakas vanligtvis av bristande tydlighet om vilka beroenden som ska distribueras och deras plats. Att främja samarbete mellan utveckling och verksamhet kan hjälpa till att lösa denna typ av problem i de flesta fall.

    När det gäller automatisering kan du definiera beroenden som hjälper mycket att påskynda distributioner. Konfigurationshanteringsverktyg som Marionett eller Chef bidra med en extra definition av beroenden. Vi kan inte bara definiera beroenden i vår applikation utan också på infrastruktur- och serverkonfigurationsnivå. Till exempel kan vi skapa en virtuell maskin för ett test och installera / konfigurera hankatt innan våra artefakter publiceras.

  3. Ineffektiv produktionsövervakning

Ibland konfigurerar du övervakningsverktyg på ett sätt som producerar mycket irrelevant data från produktionen, men andra gånger producerar de inte tillräckligt eller ingenting alls. Det finns ingen definition av vad du behöver ta hand om och vad mätvärdena är.

Du måste komma överens om vad du ska övervaka och vilken information du ska producera och sedan sätta in kontroller. Verktyg för hantering av applikationsprestanda är till stor hjälp om din organisation har råd med det. Ta en titt på AppDynamics, New Relic och AWS X-Ray.

DevOps datascenarier

DevOps handlar om att eliminera riskerna i samband med utveckling av ny programvara: Dataanalys identifierar dessa risker. För att kontinuerligt mäta och förbättra DevOps-processen bör analysen spänna över hela pipelinen. Detta ger ovärderlig insikt för ledningen i alla skeden av programvaruutvecklingen.

1. Mindre tid att analysera data

Med all information som genereras vid en viss tidpunkt måste organisationer acceptera att de inte kan analysera allt. Det finns helt enkelt inte tillräckligt med tid på dagen - och tyvärr är robotar inte tillräckligt sofistikerade för att göra allt för oss ännu.

Av det skälet är det viktigt att avgöra vilka datamängder som är viktigast. I de flesta fall kommer detta att vara annorlunda för varje organisation. Så innan du dyker in bestämmer du viktiga affärsmål och mål. Dessa mål kretsar vanligtvis kring kundernas behov - främst de mest värdefulla funktionerna som är viktigast för slutanvändarna. För en återförsäljare, till exempel, är det högst upp på listan att analysera hur trafiken interagerar med kassasidan på webbplatsen och testa hur den fungerar i backend.

Några snabba tips för att identifiera vilka data som är viktigast att analysera:

  • Gör ett diagram: Bestäm vilken påverkan avbrott kommer att ha på ditt företag och ställ frågor som 'Om X går sönder , vilken effekt kommer det att ha på andra funktioner? ”

  • Titta på historiska data: Identifiera var problem har uppstått tidigare och fortsätt att analysera data från tester och bygg för att säkerställa att det inte händer igen.

2. Svår kommunikation

Idag arbetar de flesta organisationer fortfarande med olika team och personligheter som identifierar sina egna mål och använder sina egna verktyg och tekniker. Varje lag agerar oberoende, kopplas bort från rörledningen och träffas bara med andra team under integrationsfasen.

När det gäller att titta på den större bilden och identifiera vad som fungerar och inte fungerar, kämpar organisationen för att komma till en lösning. Det beror främst på att alla inte delar den totala informationen, vilket gör analysen omöjlig.

För att lösa problemet, se över flödet av kommunikation för att säkerställa att alla samarbetar i hela SDLC, inte bara under integrationsprocessen.

  • Kontrollera först att det finns stark synkronisering av DevOps-mätvärden från början. Varje lags framsteg ska visas i en enda instrumentpanel med samma Key Performance Indicators (KPI) för att ge ledningen synlighet i hela processen. Detta görs så att de kan samla alla nödvändiga data för att analysera vad som gick fel (eller vad som lyckades).

  • Utöver den initiala mätkonversationen bör det finnas konstant kommunikation via teammöten eller digitala kanaler som Slack.

3. Brist på arbetskraft

När vi är kortbemannade behöver vi smartare verktyg som använder djupinlärning för att spara in data vi samlar in och fatta beslut snabbt. När allt kommer omkring har ingen tid att titta på varje enskild testkörning (och för vissa stora organisationer kan det vara cirka 75 000 per dag). Tricket är att eliminera bullret och hitta rätt saker att fokusera på.

Det är här artificiell intelligens och maskininlärning kan hjälpa till. Många verktyg på marknaden idag använder AI och ML för att göra saker som:

  • Utveckla skript och tester för att flytta och validera olika datadelar

  • Rapportera om kvalitet baserat på tidigare inlärda beteenden

  • Arbeta som svar på förändringar i realtid.

Så med detta har vi kommit till slutet av den här artikeln om DevOps Real Time Scenarios.

Nu när du har förstått vad DevOps realtidsscenarier är, kolla in det här av Edureka, ett pålitligt inlärningsföretag online med ett nätverk av mer än 250 000 nöjda elever spridda över hela världen. Edureka DevOps Certification Training-kursen hjälper eleverna att förstå vad som är DevOps och få expertis inom olika DevOps-processer och verktyg som Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack och GIT för att automatisera flera steg i SDLC.

Har du en fråga till oss? Vänligen nämna det i kommentarfältet i dettaArtikel om DevOps realtidsscenarierså återkommer vi till dig.