Mange af jer er måske opmærksomme på alle teorier relateret til . Men ved du, hvordan du implementerer DevOps-principper i det virkelige liv? I denne blog vil jeg diskutere DevOps Real Time-scenarier, der hjælper dig med at få en kort forståelse af, hvordan ting fungerer i realtid.
Tipene, jeg vil dække i detteDevOps artikel i realtidsscenarierer:
- Hvad er DevOps?
- Problemer løst af DevOps
- CI-scenarier (kontinuerlig integration)
- CT (kontinuerlig test) scenarier
- CD-scenarier (kontinuerlig levering)
- DevOps datascenarier
Så lad os begynde med vores første emne.
Hvad er DevOps?
DevOps er en softwareudviklingsmetode, der involverer kontinuerlig udvikling, kontinuerlig test, kontinuerlig integration, kontinuerlig implementering og kontinuerlig overvågning af softwaren gennem hele dens udviklingslivscyklus. Disse aktiviteter er kun mulige i DevOps, ikke Agile eller vandfald. Dette er grunden til, at Facebook og andre topvirksomheder har valgt DevOps som vejen frem for deres forretningsmål.DevOps foretrækkes hovedsageligt til udvikling af software af høj kvalitet i kortere udviklingscyklusser, hvilket resulterer i større kundetilfredshed.
I det næste afsnit af detteDevOps Real Time Scenarios-artikel, vi vil se på de forskellige problemer løst af DevOps.
Problemer løst af DevOps
1. Lever værdi til kunder
- DevOps minimerer tiden det tager at levere værdi til kunderne. Cyklustiden fra udviklerens afslutning af en historie / opgave, indtil produktionen reduceres markant, så værdien kan realiseres så hurtigt som muligt.
Den vigtigste værdi, der realiseres gennem DevOps, er, at det gør det muligt for it-organisationer fokusere på deres “kerne” forretningsaktiviteter . Ved at fjerne begrænsninger inden for værdistrømmen og automatisere implementeringsrørledninger kan hold fokusere på aktiviteterne. Dette hjælper med at skabe kundeværdi snarere end bare at flytte bits og bytes. Disse aktiviteter øger en virksomheds bæredygtige konkurrencefordel og skaber bedre forretningsresultater.
2. Reduceret cyklustid
hvad er dødvande i java
Internt er DevOps den eneste måde at opnå smidighed på at levere sikker kode med indsigt. Det er vigtigt at have porte og en veludformet DevOps-proces. Når du leverer en ny version, kan den køre side om side med den aktuelle version. Du kan også sammenligne metrics for at opnå det, du ønskede med applikations- og performance-metrics.
DevOps driver udviklingshold mod kontinuerlig forbedring og hurtigere frigivelsescyklusser . Hvis det gøres godt, giver denne iterative proces mere fokus over tid på de ting, der virkelig betyder noget. Såsom ting, der skaber gode oplevelser for brugerne - og mindre tid til at styre værktøjer, processer og teknologi.
3. Tid til marked
Det vigtigste problem, der løses, er reduktion af procesens kompleksitet. Dette bidrager væsentligt til vores forretningssucces ved at forkorte vores tid til markedet, give os hurtig feedback på funktioner og gøre os mere lydhøre over for vores kunders behov.
4. Problemløsning
Den største værdi af vellykket DevOps-implementering er højere tillid til levering, synlighed og sporbarhed til hvad der foregår, så du kan løse problemer hurtigere.
En anden vigtig fordel ved DevOps spilder ikke tid. Justering af en organisations medarbejdere og ressourcer muliggør hurtig implementering og opdatering. Dette giver DevOps-programmer mulighed for at løse problemer, før de bliver til katastrofer.DevOps skaber en kultur af gennemsigtighed, der fremmer fokus og samarbejde mellem udvikling, operationer og sikkerhedsteams.
CI (kontinuerlig integration) iDevOps realtidsscenarier
1. Enkeltpersoner kan se kontinuerlig integration kontraproduktivt
Medlemmer af et udviklingsteam har forskellige roller, ansvarsområder og prioriteter. Det er muligt, at produktchefens første prioritet er lancering af nye funktioner, projektleder skal sørge for, at deres team overholder deadline. Programmører tror måske, at hvis de holder op med at rette en mindre fejl, hver gang den opstår, vil de sænke dem. De føler måske at holde bygningen ren er en ekstra byrde for dem, og de får ikke fordel af deres ekstra indsats. Dette kan potentielt bringe tilpasningsprocessen i fare.
For at overvinde dette:
For det første skal du sørge for, at hele dit team er om bord, inden du vedtager kontinuerlig integration.
CTO'er og teamledere skal hjælpe teammedlemmerne med at forstå omkostningerne og fordelene ved kontinuerlig integration.
Fremhæv, hvad og hvornår kodere vil få gavn af at dedikere sig til en anden arbejdsmetode, der kræver lidt mere åbenhed og fleksibilitet.
2. Integrering af CI i dit eksisterende udviklingsflow
Vedtagelse af CI kommer uundgåeligt med behovet for i det væsentlige at ændre nogle dele af din udviklingsworkflow. Det er muligt, at dine udviklere muligvis ikke retter arbejdsgangen, hvis den ikke er brudt. Dette er hovedsageligt muligt, hvis dit team har en større rutine i udførelsen af deres nuværende arbejdsgang.
Hvis du ønsker at ændre arbejdsgangen, skal du gøre det med store forholdsregler. Ellers kan det kompromittere produktiviteten i udviklingsteamet og også produktets kvalitet. Uden tilstrækkelig støtte fra ledelsen kan udviklingsteamet være lidt tilbageholdende med at påtage sig en opgave med sådanne risici involveret.
For at overvinde dette:
Du skal sørge for at give tid nok til dit team til at udvikle deres nye arbejdsgang. Dette gøres for at vælge en fleksibel kontinuerlig integrationsløsning, der kan understøtte deres nye arbejdsgang.
Sørg også for, at virksomheden har ryggen, selvom ting måske ikke går meget glat i starten.
3. Tilbagevenden til de tidligere testvaner
Den umiddelbare virkning af vedtagelse af kontinuerlig integration er, at dit team tester oftere. Så flere tests har brug for flere testsager, og det kan være tidskrævende at skrive testsager. Derfor er udviklere ofte nødt til at opdele deres tid mellem at rette fejl og skrive testsager.
Midlertidigt kan udviklere muligvis spare tid ved manuel test, men det kan skade mere i det lange løb. Jo mere de udsætter skrivetestesager, jo sværere bliver det at indhente udviklingen. I værste fald kan dit team ende med at gå tilbage til deres gamle testproces.
For at overvinde dette:
Du skal understrege, at skrivning af testsager fra starten kan spare meget tid for dit team og kan sikre høj testdækning af dit produkt.
Integrer også ideen i din virksomhedskultur om, at testsager er lige så værdifulde aktiver som selve kodebasen.
4. Udviklere ignorerer fejlmeddelelser
Det er et almindeligt problem, at når større hold arbejder sammen, bliver mængden af CI-underretninger overvældende, og udviklere begynder at ignorere og dæmpe dem. Derfor er det muligt, at de måske går glip af de opdateringer, der er relevante for dem.
Det kan føre til et stadium, hvor kodere udvikler en relativ immunitet over for ødelagte builds og fejlmeddelelser. Jo længere tid de ignorerer relevante meddelelser, jo længere udvikler de sig uden feedback i den forkerte retning. Dette kan potentielt medføre enorme tilbagesendelser, spild af penge, ressourcer og tid.
For at overvinde dette:
Du skal kun sende kritiske opdateringer.
Send kun underretningen til respektive udviklere, der har ansvaret for at rette det.
CT (kontinuerlig test) iDevOps realtidsscenarier
Få kravspecifikation til højre
Hvis du får dine krav rigtige, er næsten halvdelen af kampen vundet. Så hvis du har en meget specifik og nøjagtig forståelse af kravene, kan du designe testplaner bedre og dække kravene godt.
Alligevel bruger mange hold meget tid og kræfter på at afklare kravene. Dette er en meget almindelig faldgrube, og for at undgå dette kan hold vedtage modelbaseret test og adfærdsdrevet udviklingsteknikker. Dette hjælper med at designe testscenarier nøjagtigt og tilstrækkeligt.
Disse fremgangsmåder vil helt sikkert hjælpe med at løse og løse hullerne hurtigere. Det gør det også muligt for dem at generere flere testsager automatisk lige fra de tidlige stadier af en sprint.
Orkestrering af rørledning
Fordelene ved kontinuerlig test og kontinuerlig levering er tæt knyttet til orkestrering af rørledninger. Dette betyder direkte at forstå, hvordan det fungerer, hvorfor det fungerer, hvordan man analyserer resultaterne, og hvordan og hvornår man skalerer. Alt afhænger af rørledningen, og derfor skal du integrere rørledningen med automatiseringspakken.
Men grunden til, at hold fumler, er, at ingen enkelt løsning leverer den komplette værktøjskæde, der kræves for at opbygge en cd-pipeline.
Hold skal typisk søge efter de brikker i puslespillet, der passer til dem. Der er ingen perfekte værktøjer, typisk kun de bedste værktøjer, der giver integrationer sammen med flere andre værktøjer. Og selvfølgelig en API, der også tillader lette integrationer.
Kort sagt er det umuligt at gennemføre kontinuerlig test uden en standardiseret og automatiseret pipelines hastighed og pålidelighed.
Opskalering og styring af kompleksitet
Et andet vigtigt scenario er, at kontinuerlig test bliver mere kompleks, når den bevæger sig mod produktionsmiljøet. Testene vokser i antal såvel som kompleksitet med modningskoden og miljøet bliver mere komplekst.
Du skal opdatere test hver gang du opdaterer forskellige faser og automatiske scripts. Som et resultat har den samlede tid, det tager at køre testene, også en tendens til at stige mod frigivelsen.
Løsningen på dette ligger i forbedret testorkestrering, der giver den rigtige mængde testdækning i kortere sprintcykler og gør det muligt for hold at levere trygt. Ideelt set skal hele processen automatiseres med CT udført på forskellige stadier. Dette gøres ved hjælp af politiske porte og manuel indgriben, indtil koden skubbes til produktion.
Oprettelse af feedback-sløjfer
Uden hyppige feedback-sløjfer på hvert trin i udviklingscyklussen er kontinuerlig test ikke mulig. Dette er dels grunden til, at CT er vanskelig at implementere. Du har ikke kun brug for automatiserede tests, men du har også brug for synlighed af testresultaterne og udførelsen.
Traditionelle feedback-sløjfer som logningsværktøjer, kodeprofiler og værktøjer til effektivitetsovervågning er ikke effektive mere. Hverken de arbejder sammen eller giver den dybde af den indsigt, der kræves for at løse problemer. Realtids dashboards, der genererer rapporter automatisk og tilbagemeldende feedback på tværs af hele SDLC hjælper med at frigive software hurtigere i produktion med mindre defekter. Realtidsadgang til dashboards og adgang for alle teammedlemmer hjælper den kontinuerlige feedbackmekanisme.
Mangel på miljøer
Kontinuerlig test betyder simpelthen test oftere, og dette kræver at ramme flere miljøer oftere. Dette udgør en flaskehals, hvis de nævnte miljøer ikke er tilgængelige på det tidspunkt, de er nødvendige. Nogle miljøer er tilgængelige via API'er og andre gennem forskellige grænseflader. Nogle af disse miljøer kan bygges ved hjælp af moderne arkitektur, mens andre med monolitisk ældre klient / server eller mainframesystemer.
Men spørgsmålet her er, hvordan koordinerer du test gennem de forskellige miljøejere? Det er også muligt, at de måske ikke altid holder miljøerne i gang. Svaret på alt dette er Virtualisering . Ved at virtualisere miljøet kan du teste koden uden at bekymre dig for meget om områder, der er uændrede.At gøre miljøerne tilgængelige og tilgængelige on-demand gennem virtualisering hjælper helt sikkert med at fjerne en betydelig flaskehals fra din pipeline.
CD (kontinuerlig levering) iDevOps realtidsscenarier
Implementeringer, der tager for lang tid
Distribuerede applikationer kræver normalt mere end 'kopiering og indsætning' af filer til en server. Kompleksiteten har en tendens til at stige, hvis du har en gård med servere. Usikkerhed om, hvad der skal implementeres, hvor og hvordan, er en ret normal ting. Resultatet? Lange ventetider for at få vores artefakter ind i det næste miljø på ruten for at forsinke alt, test, tid til at leve osv.
Hvad bringer DevOps til bordet? Udviklings- og it-driftsteam definerer en implementeringsproces i en ubeklagelig samarbejdssession. Først kontrollerer de, hvad der fungerer, og tager det derefter til næste niveau med automatisering for at lette kontinuerlig levering. Dette reducerer drastisk timing for implementering, det baner også vejen for hyppigere implementeringer.
Manglende artefakter, scripts og andre afhængigheder
Vi støder ofte på fejl efter implementeringen af en ny version af et arbejdsstykke software. Dette skyldes ofte, at manglende biblioteker eller databasescripts ikke opdateres. Dette skyldes normalt manglende klarhed om, hvilke afhængigheder der skal implementeres, og deres placering. Fremme af samarbejde mellem udvikling og drift kan hjælpe med at løse denne slags problemer i de fleste tilfælde.
Når det kommer til automatisering, kan du definere afhængigheder, som hjælper meget med at fremskynde implementeringer. Konfigurationsstyringsværktøjer som Marionet eller Chief bidrage med et ekstra niveau af definition af afhængigheder. Vi kan ikke kun definere afhængigheder inden for vores applikation, men også på infrastruktur- og serverkonfigurationsniveau. For eksempel kan vi oprette en virtuel maskine til en test og installere / konfigurere tomcat inden vores artefakter offentliggøres.
brug af iterator i java
Ineffektiv produktionsovervågning
Nogle gange konfigurerer du overvågningsværktøjer på en måde, der producerer en masse irrelevante data fra produktionen, men andre gange producerer de ikke nok eller slet ikke noget. Der er ingen definition af, hvad du skal passe på, og hvad metrics er.
Du skal være enig om, hvad du skal overvåge, og hvilke oplysninger du skal producere, og derefter sætte kontroller på plads. Applikationseffektivitetsstyringsværktøjer er en stor hjælp, hvis din organisation har råd til det, kig på AppDynamics, New Relic og AWS X-Ray.
DevOps datascenarier
DevOps handler om at fjerne de risici, der er forbundet med ny softwareudvikling: Dataanalyse identificerer disse risici. For kontinuerligt at måle og forbedre DevOps-processen skal analyser spænde over hele pipelinen. Dette giver uvurderlig indsigt for ledelsen i alle faser af softwareudviklingens livscyklus.
1. Mindre tid til at analysere data
Med alle de data, der genereres til enhver tid, skal organisationer acceptere, at de ikke kan analysere det hele. Der er simpelthen ikke tid nok på dagen - og desværre er robotter ikke helt sofistikerede nok til at gøre det hele for os endnu.
Af den grund er det vigtigt at afgøre, hvilke datasæt der er mest betydningsfulde. I de fleste tilfælde vil dette være forskelligt for hver organisation. Så inden du dykker ind, skal du bestemme de vigtigste forretningsmål og mål. Disse mål drejer sig typisk om kundernes behov - primært de mest værdifulde funktioner, der er vigtigst for slutbrugerne. For en detailhandler er det f.eks. Øverst på listen at analysere, hvordan trafik interagerer med checkout-siden på webstedet og teste, hvordan det fungerer i back-end.
Nogle hurtige tip til at identificere, hvilke data der er vigtigst at analysere:
Lav et diagram: Find ud af, hvilken indvirkning udfald vil have på din virksomhed, og still spørgsmål som 'Hvis X går i stykker , hvilken effekt vil det have på andre funktioner? ”
Se på historiske data: Identificer, hvor der tidligere er opstået problemer, og fortsæt med at analysere data fra test og opbyg for at sikre, at det ikke sker igen.
2. Vanskelig kommunikation
I dag arbejder de fleste organisationer stadig med forskellige teams og personaer, der identificerer deres egne mål og bruger deres egne værktøjer og teknologier. Hvert hold handler uafhængigt, afbrudt fra rørledningen og mødes kun med andre hold i integrationsfasen.
Når det kommer til at se på det større billede og identificere hvad der fungerer og ikke fungerer, kæmper organisationen for at komme til en løsning. Dette skyldes for det meste fordi alle ikke deler de samlede data, hvilket gør analysen umulig.
For at løse dette problem skal du gennemgå strømmen af kommunikation for at sikre, at alle samarbejder i hele SDLC, ikke kun under integrationsprocessen.
Først skal du sørge for, at der er stærk synkronisering på DevOps-metrics fra starten. Hvert teams fremskridt skal vises i et enkelt instrumentbræt ved hjælp af de samme Key Performance Indicators (KPI'er) for at give ledelsen synlighed i hele processen. Dette gøres, så de kan indsamle alle de nødvendige data til at analysere, hvad der gik galt (eller hvad der lykkedes).
Ud over den indledende metrics-samtale skal der være konstant kommunikation via teammøder eller digitale kanaler som Slack.
3. Manglende arbejdskraft
Når vi er bemandede, har vi brug for smartere værktøjer, der bruger dyb læring til at indsætte de data, vi indsamler, og hurtigt træffe beslutninger. Når alt kommer til alt har ingen tid til at se på hver eneste testudførelse (og for nogle store organisationer kan der være omkring 75.000 på en given dag). Tricket er at fjerne støj og finde de rigtige ting at fokusere på.
Det er her kunstig intelligens og maskinlæring kan hjælpe. Mange værktøjer på markedet i dag bruger AI og ML til at gøre ting som:
Udvikle scripts og tests for at flytte og validere forskellige data
Rapport om kvalitet baseret på tidligere lært adfærd
Arbejd som reaktion på ændringer i realtid.
Så med dette er vi kommet til slutningen af denne artikel om DevOps Real Time Scenarios.
Nu hvor du har forstået, hvad DevOps Real Time Scenarios er, skal du tjekke dette af Edureka, et pålideligt online læringsfirma med et netværk på mere end 250.000 tilfredse elever spredt over hele kloden. Edureka DevOps-certificeringstræningskurset hjælper eleverne med at forstå, hvad der er DevOps og få ekspertise i forskellige DevOps-processer og -værktøjer såsom Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack og GIT til automatisering af flere trin i SDLC.
Har du et spørgsmål til os? Nævn det i kommentarfeltet i detteDevOps artikel i realtidsscenarierog vi vender tilbage til dig.