Mange av dere er kanskje klar over alle teoriene knyttet til . Men vet du hvordan du implementerer DevOps-prinsipper i det virkelige liv? I denne bloggen vil jeg diskutere DevOps sanntidsscenarier som vil hjelpe deg med å få en kort forståelse av hvordan ting fungerer i sanntid.
Tips som jeg skal dekke i detteDevOps sanntidsscenarier artikkeler:
- Hva er DevOps?
- Problemer løst av DevOps
- CI (kontinuerlig integrasjon) scenarier
- CT (kontinuerlig testing) scenarier
- CD-scenarier (kontinuerlig levering)
- DevOps datascenarier
Så la oss begynne med vårt første tema.
Hva er DevOps?
DevOps er en programvareutviklingsmetode som involverer kontinuerlig utvikling, kontinuerlig testing, kontinuerlig integrering, kontinuerlig implementering og kontinuerlig overvåking av programvaren gjennom hele utviklingssyklusen. Disse aktivitetene er bare mulig i DevOps, ikke Agile eller foss. Dette er grunnen til at Facebook og andre toppbedrifter har valgt DevOps som veien videre for sine forretningsmål.DevOps foretrekkes hovedsakelig for utvikling av programvare av høy kvalitet i kortere utviklingssykluser, noe som resulterer i større kundetilfredshet.
I neste del av detteDevOps Real Time Scenarios-artikkel, vi vil se på de forskjellige problemene som er løst av DevOps.
Problemer løst av DevOps
1. Lever verdi til kunder
- DevOps minimerer tiden det tar å levere verdi til kundene. Syklusstiden fra utviklerens fullføring av en historie / oppgave til produksjonen reduseres betydelig, slik at verdien kan realiseres så raskt som mulig.
Den viktigste verdien realisert gjennom DevOps er at den lar IT-organisasjoner gjøre det fokusere på 'kjernevirksomheten' . Ved å fjerne begrensninger i verdistrømmen og automatisere distribusjonsrørledninger, kan team fokusere på aktivitetene. Dette hjelper til med å skape kundeverdi i stedet for bare å flytte biter og byte. Disse aktivitetene øker et bærekrafts konkurransefortrinn for et selskap og skaper bedre forretningsresultater.
2. Redusert syklustid
Internt er DevOps den eneste måten å oppnå smidigheten til å levere sikker kode med innsikt. Det er viktig å ha porter og en godt utformet DevOps-prosess. Når du leverer en ny versjon, kan den kjøre side om side med den gjeldende versjonen. Du kan også sammenligne beregninger for å oppnå det du ønsket med applikasjons- og ytelsesberegninger.
DevOps driver utviklingsteam mot kontinuerlig forbedring og raskere frigjøringssykluser . Hvis det gjøres bra, tillater denne iterative prosessen mer fokus over tid på de tingene som virkelig betyr noe. Slik som ting som skaper gode opplevelser for brukerne - og mindre tid på å administrere verktøy, prosesser og teknologi.
3. Tid til markedet
Det viktigste problemet som løses er reduksjon av kompleksiteten i prosessen. Dette bidrar betydelig til vår suksess ved å forkorte vår tid til markedet, gi oss raske tilbakemeldinger på funksjoner og gjøre oss mer lydhøre overfor kundenes behov.
4. Problemløsning
Den største verdien av vellykket implementering av DevOps er høyere tillit til levering, synlighet og sporbarhet til det som skjer, slik at du kan løse problemer raskere.
En annen viktig fordel med DevOps er ikke å kaste bort tid. Justering av organisasjonens mennesker og ressurser muliggjør rask distribusjon og oppdateringer. Dette lar DevOps-programmer løse problemer før de blir til katastrofer.DevOps skaper en kultur av åpenhet som fremmer fokus og samarbeid mellom utvikling, drift og sikkerhetsteam.
CI (kontinuerlig integrasjon) iDevOps-sanntidsscenarier
1. Enkeltpersoner kan se kontinuerlig integrasjon kontraproduktivt
Medlemmer av et utviklingsteam har forskjellige roller, ansvar og prioriteringer. Det er mulig at produktsjefens første prioritet kan være å lansere nye funksjoner, prosjektleder må sørge for at teamet deres overholder fristen. Programmører tror kanskje at hvis de slutter å fikse en mindre feil hver gang den oppstår, vil de redusere farten. De kan føle at det å holde bygningen ren er en ekstra belastning for dem, og de vil ikke dra fordel av deres ekstra innsats. Dette kan potensielt bringe tilpasningsprosessen i fare.
For å overvinne dette:
Først må du sørge for at hele teamet er ombord før du vedtar kontinuerlig integrasjon.
CTOer og teamledere må hjelpe teammedlemmene til å forstå kostnadene og fordelene ved kontinuerlig integrasjon.
Fremhev hva og når kodere vil ha nytte av å vie seg til en annen arbeidsmetode som krever litt mer åpenhet og fleksibilitet.
2. Integrering av CI i din eksisterende utviklingsstrøm
Å vedta CI kommer uunngåelig med behovet for å endre noen deler av utviklingsarbeidsflyten din. Det er mulig at utviklerne kanskje ikke fikser arbeidsflyten hvis den ikke er ødelagt. Dette er mulig hovedsakelig hvis teamet ditt har en større rutine i å utføre sin nåværende arbeidsflyt.
Hvis du ønsker å endre arbeidsflyten, må du gjøre det med store forholdsregler. Ellers kan det kompromittere produktiviteten til utviklingsteamet og også kvaliteten på produktet. Uten tilstrekkelig støtte fra ledelsen, kan utviklingsteamet være litt motvillige til å påta seg en oppgave med slike risikoer involvert.
For å overvinne dette:
Du må sørge for at du gir nok tid til teamet ditt til å utvikle sin nye arbeidsflyt. Dette gjøres for å velge en fleksibel kontinuerlig integrasjonsløsning som kan støtte deres nye arbeidsflyt.
Java streng delt flere avgrensere
Sørg også for at selskapet har ryggen, selv om ting kanskje ikke går veldig greit i begynnelsen.
3. Å komme tilbake til de tidligere testvanene
Den umiddelbare effekten av å vedta kontinuerlig integrasjon er at teamet ditt tester oftere. Så flere tester vil trenge flere testsaker, og det kan være tidkrevende å skrive testsaker. Derfor må utviklere ofte dele tiden sin mellom å fikse feil og skrive testsaker.
Midlertidig kan utviklere kanskje spare tid ved manuell testing, men det kan skade mer i det lange løp. Jo mer de utsetter å skrive testsaker, jo vanskeligere blir det å fange opp utviklingen. I verste fall kan teamet ditt ende opp med å gå tilbake til sin gamle testprosess.
For å overvinne dette:
Du må understreke at det å skrive testsaker fra begynnelsen kan spare tid for teamet ditt og kan sikre høy testdekning av produktet ditt.
Legg også inn ideen i bedriftskulturen din om at testsaker er like verdifulle eiendeler som selve kodebasen.
4. Utviklere ignorerer feilmeldinger
Det er et vanlig problem at når større team jobber sammen, blir mengden CI-varsler overveldende og utviklere begynner å ignorere og dempe dem. Derfor er det mulig at de kan savne oppdateringene som er relevante for dem.
Det kan føre til et stadium der kodere utvikler en relativ immunitet mot ødelagte bygg og feilmeldinger. Jo lenger de ignorerer relevante varsler, jo lenger utvikler de seg uten tilbakemelding i feil retning. Dette kan potensielt føre til enorme tilbakeslag, sløsing med penger, ressurser og tid.
For å overvinne dette:
Du bør bare sende kritiske oppdateringer.
Send kun varselet til respektive utviklere som har ansvaret for å fikse det.
CT (kontinuerlig testing) iDevOps-sanntidsscenarier
Få kravspesifikasjon riktig
Hvis du får dine krav riktig, er nesten halvparten av kampen vunnet. Så hvis du har en veldig spesifikk og nøyaktig forståelse av kravene, kan du designe testplaner bedre og dekke kravene godt.
Likevel bruker mange lag mye tid og krefter på å bare avklare kravene. Dette er en veldig vanlig fallgruve, og for å unngå dette kan teamene ta i bruk modellbasert testing og atferdsdrevet utviklingsteknikk. Dette hjelper deg med å utforme testscenarier nøyaktig og tilstrekkelig.
Denne fremgangsmåten vil definitivt bidra til å løse og løse hullene raskere. Det gjør det også mulig for dem å generere flere testsaker automatisk helt fra de tidlige stadiene av en sprint.
Orkestrering av rørledninger
Fordelene med kontinuerlig testing og kontinuerlig levering er nært knyttet til orkestrering av rørledninger. Dette betyr direkte å forstå hvordan det fungerer, hvorfor det fungerer, hvordan man analyserer resultatene, og hvordan og når skalering. Alt avhenger av rørledningen, og derfor må du integrere rørledningen med automatiseringsserien.
Men grunnen til at team fomler er at ingen løsninger gir den komplette verktøykjeden som kreves for å bygge en CD-rørledning.
forholdet mellom java og javascript
Lag må vanligvis søke etter brikkene i puslespillet som er riktige for dem. Det er ingen perfekte verktøy, vanligvis bare de beste verktøyene, som gir integrasjoner sammen med flere andre verktøy. Og selvfølgelig en API som også tillater enkle integrasjoner.
Kort sagt, det er umulig å implementere kontinuerlig testing uten hastigheten og påliteligheten til en standardisert og automatisert rørledning.
Skaler opp og håndtere kompleksitet
Et annet viktig scenario er at kontinuerlig testing blir mer kompleks når den beveger seg mot produksjonsmiljøet. Testene vokser i antall i tillegg til kompleksitet med modningskoden og miljøet blir mer komplekst.
Du må oppdatere tester hver gang du oppdaterer forskjellige faser og automatiserte skript. Som et resultat har den totale tiden det tar å kjøre testene også en tendens til å øke mot utgivelsen.
Løsningen på dette ligger i forbedret testorkestrering som gir riktig mengde testdekning i kortere sprintsykluser og som gjør at lagene kan levere trygt. Ideelt sett må hele prosessen automatiseres med CT utført på forskjellige stadier. Dette gjøres ved å bruke policyporter og manuell inngrep, frem til koden blir presset til produksjon.
Opprette tilbakemeldingsløkker
Uten hyppige tilbakemeldingsløkker på hvert trinn i utviklingssyklusen, er kontinuerlig testing ikke mulig. Dette er delvis grunnen til at CT er vanskelig å implementere. Du trenger ikke bare automatiserte tester, men du trenger også synlighet av testresultatene og utførelsen.
Tradisjonelle tilbakemeldingsløkker som loggeverktøy, kodeprofiler og ytelsesovervåkingsverktøy er ikke effektive lenger. Verken de jobber sammen eller gir den dybden av innsikt som kreves for å løse problemer. Sanntids dashboards som genererer rapporter automatisk og handlingsfri tilbakemelding på tvers av hele SDLC hjelper med å frigjøre programvare raskere i produksjon med mindre feil. Sanntidstilgang til dashbord og tilgang for alle teammedlemmene hjelper den kontinuerlige tilbakemeldingsmekanismen.
Mangel på miljøer
Kontinuerlig testing betyr ganske enkelt å teste oftere, og dette krever å treffe flere miljøer oftere. Dette utgjør en flaskehals hvis de nevnte miljøene ikke er tilgjengelige på det tidspunktet de kreves. Noen miljøer er tilgjengelige via API-er og andre gjennom forskjellige grensesnitt. Noen av disse miljøene kan bygges ved hjelp av moderne arkitektur, mens andre med monolitisk eldre klient / server eller hovedrammesystemer.
Men spørsmålet her er hvordan koordinerer du testing gjennom de forskjellige miljøeierne? Det er også mulig at de ikke alltid holder miljøene i gang. Svaret på alt dette er Virtualisering . Ved å virtualisere miljøet kan du teste koden uten å bekymre deg for mye for områder som er uendret.Å gjøre miljøene tilgjengelige og tilgjengelige på forespørsel gjennom virtualisering bidrar helt sikkert til å fjerne en betydelig flaskehals fra rørledningen din.
CD (kontinuerlig levering) iDevOps-sanntidsscenarier
Implementeringer tar for lang tid
Distribuerte applikasjoner krever normalt mer enn ‘kopiering og liming’ av filer til en server. Kompleksiteten har en tendens til å øke hvis du har en server med gårder. Usikkerhet om hva du skal distribuere, hvor og hvordan, er en ganske normal ting. Resultatet? Lange ventetider for å få gjenstandene våre inn i neste miljø på ruten for å forsinke alt, teste, tid til å leve osv.
Hva bringer DevOps til bordet? Utviklings- og IT-operasjonsteam definerer en distribusjonsprosess i en ufarlig samarbeidsøkt. Først verifiserer de hva som fungerer, og tar det deretter til neste nivå med automatisering for å lette kontinuerlig levering. Dette reduserer tidspunktet for distribusjon drastisk, og baner også vei for hyppigere distribusjoner.
Mangler gjenstander, skript og andre avhengigheter
Vi møter ofte feil etter distribusjonen av en ny versjon av et programvare. Dette er ofte forårsaket av manglende biblioteker eller databaseskript som ikke oppdateres. Dette er vanligvis forårsaket av mangel på klarhet om hvilke avhengigheter som skal distribueres og deres plassering. Å fremme samarbeid mellom utvikling og drift kan bidra til å løse slike problemer i de fleste tilfeller.
Når det gjelder automatisering, kan du definere avhengigheter som hjelper mye med å påskynde distribusjoner. Konfigurasjonsadministrasjonsverktøy som Marionett eller Sjef bidra med et ekstra nivå av definisjon av avhengigheter. Vi kan definere ikke bare avhengigheter i applikasjonen vår, men også på infrastruktur- og serverkonfigurasjonsnivå. For eksempel kan vi lage en virtuell maskin for en test, og installere / konfigurere tomcat før gjenstandene våre blir publisert.
Ineffektiv produksjonsovervåking
Noen ganger konfigurerer du overvåkingsverktøy på en måte som produserer mange irrelevante data fra produksjonen, men andre ganger produserer de ikke nok eller ingenting i det hele tatt. Det er ingen definisjon av hva du trenger å ta vare på og hva beregningene er.
Du må avtale hva du skal overvåke og hvilken informasjon du skal produsere, og deretter sette kontrollene på plass. Applikasjonsytelsesadministrasjonsverktøy er en god hjelp hvis organisasjonen din har råd til det, ta en titt på AppDynamics, New Relic og AWS X-Ray.
DevOps datascenarier
DevOps handler om å eliminere risikoen forbundet med ny programvareutvikling: Dataanalyse identifiserer disse risikoene. For kontinuerlig å måle og forbedre DevOps-prosessen, bør analyser spenne over hele rørledningen. Dette gir uvurderlig innsikt for ledelsen i alle ledd i livssyklusen for programvareutvikling.
1. Mindre tid til å analysere data
Med alle dataene som genereres til enhver tid, må organisasjoner godta at de ikke kan analysere det hele. Det er rett og slett ikke nok tid på dagen - og dessverre er ikke roboter ganske sofistikerte nok til å gjøre alt for oss ennå.
Av den grunn er det viktig å avgjøre hvilke datasett som er viktigst. I de fleste tilfeller vil dette være annerledes for hver organisasjon. Så før du dykker inn, må du bestemme viktige forretningsmål og mål. Vanligvis dreier disse målene seg om kundebehov - først og fremst de mest verdifulle funksjonene som er viktigst for sluttbrukerne. For en forhandler, for eksempel, er det å analysere hvordan trafikken samhandler med kassen siden på nettstedet og teste hvordan den fungerer på baksiden.
Noen raske tips for å identifisere hvilke data som er viktigst å analysere:
Lag et diagram: Finn ut hvilken innvirkning utfall vil ha på virksomheten din, og still spørsmål som 'Hvis X går i stykker , hvilken effekt vil det ha på andre funksjoner? '
Se på historiske data: Identifiser hvor problemer har oppstått tidligere, og fortsett å analysere data fra tester og bygg for å sikre at det ikke skjer igjen.
2. Vanskelig kommunikasjon
I dag opererer de fleste organisasjoner fortsatt med forskjellige team og personas som identifiserer sine egne mål og bruker egne verktøy og teknologier. Hvert team handler uavhengig, koblet fra rørledningen og møter bare med andre lag i løpet av integrasjonsfasen.
Når det gjelder å se på det større bildet og identifisere hva som fungerer og ikke fungerer, sliter organisasjonen med å komme til en løsning. Dette er fordi det meste fordi alle ikke deler de samlede dataene, noe som gjør analysen umulig.
linux systemadministrator jobbbeskrivelse
For å få bukt med dette problemet, må du flyte kommunikasjonsflyten for å sikre at alle samarbeider gjennom SDLC, ikke bare under integrasjonsprosessen.
Først må du sørge for at det er sterk synkronisering på DevOps-beregninger fra begynnelsen. Hvert teams fremgang bør vises i ett enkelt dashbord, ved å bruke de samme Key Performance Indicators (KPIs) for å gi ledelsen synlighet i hele prosessen. Dette gjøres slik at de kan samle alle nødvendige data for å analysere hva som gikk galt (eller hva som lyktes).
Utover den innledende beregningen samtale, bør det være konstant kommunikasjon via teammøter eller digitale kanaler som Slack.
3. Mangel på arbeidskraft
Når vi er lite bemannet, trenger vi smartere verktøy som bruker dyp læring for å spore inn dataene vi samler inn og komme raskt til avgjørelser. Tross alt har ingen tid til å se på hver eneste testutførelse (og for noen store organisasjoner kan det være rundt 75 000 på en gitt dag). Trikset er å eliminere støyen og finne de rette tingene å fokusere på.
Det er her kunstig intelligens og maskinlæring kan hjelpe. Mange verktøy på markedet i dag bruker AI og ML til å gjøre ting som:
Utvikle skript og tester for å flytte og validere forskjellige deler av data
Rapport om kvalitet basert på tidligere lært atferd
Arbeid som svar på sanntidsendringer.
Så med dette har vi kommet til slutten av denne artikkelen om DevOps Real Time Scenarios.
Nå som du har forstått hva DevOps sanntidsscenarier er, sjekk ut dette av Edureka, et pålitelig online læringsfirma med et nettverk av mer enn 250 000 fornøyde elever spredt over hele verden. Edureka DevOps Certification Training-kurset hjelper elever til å forstå hva som er DevOps og få ekspertise i forskjellige DevOps-prosesser og verktøy som Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack og GIT for å automatisere flere trinn i SDLC.
Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet til detteDevOps sanntidsscenarier artikkelog vi kommer tilbake til deg.