Meny

Samarbeid i DevOps

collaboration devops

Prøv Instrumentet Vårt For Å Eliminere Problemer

Samarbeid i DevOps:

Små trinn på leveranser i DevOps ble forklart i detalj i vår forrige opplæring.

Vi vet at nøkkelmantraet til DevOps er samarbeid og derav ordet DevOps ankom.

Les gjennom => In-Depth DevOps Tutorials

Samarbeid er å komme sammen som et enkelt team for å løse ethvert problem i programmet, noe som hindrer programvarekundens fokus på kundene og løser dem ved å eie dem som sitt eget problem så raskt som mulig, uten noe skyldspill.

Samarbeid i DevOps

Samarbeid lærer alle å snakke med hverandre, møte hverandre ansikt til ansikt, involvere hverandre i møtene, diskusjonene, forstå hverandres oppgaver, avhengighet og ha gjennomsiktighet i arbeidet og arbeide proaktivt for å forhindre problemene.

VIDEO Del 2 Blokk 5: Samarbeid - 15 minutter og 36 sekunder

Transkripsjon:

Begrepet samarbeid gjentas igjen og igjen i DevOps og Devops-mantraet er samarbeid. Så la oss forstå hva 'samarbeid' egentlig betyr i programvareutvikling og DevOps-sammenheng.

Så snart en organisasjon sier, implementerer vi DevOps, ifølge meg starter automatisk tenkningen på samarbeid som er knyttet til devops praksis i alles sinn og gjør dem mer fokusert og våken mot samarbeid, og de begynner å føle at de trenger å samarbeide . Det er magien i samarbeid.

Så det å starte DevOps-samarbeid helt fra begynnelsen av prosjektet er veldig viktig for organisasjonen og teamet. Teamet mener jeg, teammedlemmer i programmet.

Jeg skal forklare et par tilfeller der jeg har sett Dev samarbeide med Ops og ops samarbeide med dev-teamet slik at vi vet hva som faktisk samarbeider betyr i DevOps-sammenheng.

Dette er representasjonen av eksempel en.

Det var et tilfelle at det var noe ukjent problem i installasjonsskriptet eller konfigurasjonsskriptet som ops teamet fant en utfordring med å installere programvaren på et bestemt oppsett av en klynge i en bestemt geografi.

Det kastet noen ukjente feil og var et rent produksjonsproblem, som aldri skjedde i utviklingsmiljø, og operasjonsteamet brukte virkelig mye krefter på å løse dem selv og tenkte at det er noe relatert til oppsettet, og de må løse den, som ikke ble løst på ganske lang tid.

Så begynte Dev-teamet umiddelbart uten å bli invitert til å hjelpe, selv om tidssonen var annerledes, tok den kontrollen over produksjonsstedet, du vet generelt at tilgang til produksjonen ikke vil bli gitt til alle, Ops deler bare feilen detaljer eller annen informasjon som teamet trenger for feilsøkingsformål.

Men denne situasjonen er kalt for å gi tilgang til en av teammedlemmet, som dedikert brukte noen timer på å analysere problemet på live og ga øyeblikkelig arbeid rundt, og dermed ble problemet løst raskt.

Dette er forekomsten av samarbeidet der dev-teamet frivillig eide problemet og hjalp ops-teamet med å løse det. Dette er en ren forekomst av samarbeid.

Tilsvarende, en annen forekomst, la meg vise det diagrammatisk, som jeg har tegnet. En annen forekomst er at ting fungerte ganske bra etter programvareoppgraderingen på et bestemt nettsted i noen dager, plutselig begynte applikasjonens ytelse å bremse.

Sluttbrukere begynte å møte alvorlige transaksjonstap på grunn av dette avta. Mange klagesamtaler begynte å komme til CSR, jeg mener kundeservicemedarbeidere, og de begynte i sin tur å følge opp teamet i saken.

I dette tilfellet kom både Dev- og Ops-teamet umiddelbart sammen, og med informasjonen og telemetridetaljene som ble gitt av Ops-teamet til dev-teamet, kunne de feilsøke problemet og identifisere at det var noe problem i belastningsdelingsaspektet og derfor var ytelsen treg.

Så begge lagene jobbet sammen for å løse problemet og komme tilbake til normalitet i løpet av få timer. Så her kom både Dev og Ops sammen fram og samarbeidet om å løse problemet i stedet for Dev som sa Ops-problemet og Ops tenkte at det er Devs problem og dev-teamet må se på og fikse det.

Dette er den tydelige forekomsten av samarbeid der alle eier problemene, i stedet for å spille skyldspillet, uavhengig av hvem det er problemet eller kaster bort tid på å finne ut hvem det er problemet, med tanke på at sluttbrukeren lider og problemet trenger skal løses snart.

Så igjen, problemet trenger ikke bare å være fra produksjonen, det kan være noe enkelt internt programvareutviklingsproblem, så enkelt som det daglige problemet, eller et designproblem, eller et arkitekturproblem, eller til og med et enkelt verktøyproblem.

Ethvert problem relatert til programmet eller ethvert problem som teamet vet at, forårsaker skade på kunden eller bremser programmet, må eies av alle, i stedet for å isolere problemet om at det er utviklingsproblem eller driftsproblem eller testproblem, og bidra til å få det adressert så raskt som mulig, er et samarbeid.

Så samarbeid i DevOps-sammenheng er utvikling og drift som kommer sammen og jobber sammen for å løse problemet så tidlig som mulig, med tanke på kundens fokus.

Samarbeid er både Dev og Ops som eier det som skjer i live, overvåking og logging og ytelseskontroll er på toppen for å løse problemet som oppstår spesielt i produksjonen i sluttbrukerens interesse.

hvordan åpne apk på android

ELLER rett og slett, jeg kan si at hele teamet, som jobber kontinuerlig sammen for å løse problemet for å oppnå programmålene, og som har kundefokus i tankene, er samarbeidet. Jeg gjentar, og jobber kontinuerlig sammen for å løse problemene for å oppnå programmålene med å holde kundens fokus i tankene er samarbeid.

Så dukker det opp et spørsmål, hvordan utvikler vi dette samarbeidet, og når trenger vi å starte samarbeidet mellom teamet, som sitter milevis fra hverandre ??

Tydeligvis vet vi at både Dev og Ops ikke kan samlokalisere. Ops-teamet må være nærmere arbeidsstedet eller datasentre, og utvikleren må være nærmere programvareutviklingssenteret. Så hvordan oppnår vi det konstante samarbeidet mellom begge lag ??

Først og fremst å starte DevOps-samarbeid helt fra begynnelsen av prosjektet er veldig viktig for organisasjonen og teamet. Teamet jeg mener her, er teamets medlemmer i programmet.

Å øve på et par av følgende ting vil hjelpe til med å bygge bro over gapet mellom teamet og overvinne begrensningen til virtuelle team og hjelper til å oppnå samarbeidet.

Så la oss se hvilke fremgangsmåter som hjelper til å oppnå samarbeidet.

Involver utvikling i alle relevante møter og diskusjoner i operasjonsteamet og omvendt.

Dette bringer dem ikke bare sammen, men hjelper også til å forstå hvert av arbeidsområdet, deres daglige problemer og hvordan arbeidet deres påvirker hverandre, og hva er de kritiske tingene som hver og en bør ta vare på for å unngå problemene senere og dermed bringer dem nærmere og innleder en behagelig diskusjon mellom hverandre hver gang.

Før introduksjonen av DevOps-øvelsen pleide dev-teamet aldri å bry seg om å levere programvaren til Operations. Du vet at de pleide å være ignorante eller aldri bry seg om ting som infrastruktur, konfigurasjoner, serveroppsett, nettverkskonfigurasjoner, overvåking av live forestillinger etc.,

De trodde tidligere at alle disse aktivitetene var ansvaret for operasjonsteamet, og dev-teamet pleide ikke å vite om det. Tidligere betydde levering for utviklingsteam å være levering til Operasjonsteamet alene, men med DevOps-praksis betyr levering til produksjonen og ikke bare til operasjonene.

Tilsvar pleide ops aldri å bry seg om koden som utviklingsteamet produserte. Ethvert problem som de møter under programvareinstallasjon, funksjonalitets- eller ytelsesproblemer i produksjonen, brukte de ganske enkelt pengene til utviklingsteamet og ba dem fikse og gi det tilbake.

Så, å kjenne hverandres arbeid og forstå oppgaven deres og eie hverandres problem gjennom hele syklusen, hjelper teamet til å løse problemene raskt.

Fordi de vet hvor problemet er og hva som skjer i programmet og hva som forårsaker problemet i produksjonen, og som dermed kan gå direkte og fikse det uten store vanskeligheter.

Så, samarbeid betyr at utviklingsteamet trenger å forstå infrastruktur og konfigurasjon, og operasjonsteamet trenger å bry seg om koden, kvaliteten, levering og tidslinjer.

Å forstå avhengigheten av hverandre vil hjelpe til med å øke hastigheten på arbeidet og levere det i tide.

Som under programvareinstallasjon, er operasjonsteamet avhengig av et utviklingsteam for å løse eventuelle problemer knyttet til installasjonen. På samme måte er utviklingsteamet avhengig av mange forutsetninger som eksisterer live for at operasjonsteamet skal sørge for under kodingsprosessen, mens koding.

En annen Eksempel er testteamet avhengig av operasjonsteamet for å levere eksempeldata fra produksjonen for testing. Detaljer om miljøkonfigurasjon som skal settes opp i utviklingsmiljøet etc.

Så både teamet trenger å samarbeide med hverandre og forstå avhengigheten av hverandre og gi dataene eller informasjonen i tide uten å forårsake noen forsinkelse ved å huske på tidssonefaktoren.

Oppretthold gjennomsiktighet ved å vedta DevOps-fremgangsmåter som kildekontroll eller versjonskontroll som gjør at teamet kan forstå alt om programmet og hjelper til med å unngå misforståelser.

Så dette er i utgangspunktet å opprettholde gjennomsiktigheten i teamet.

Teammedlemmer trenger ikke å være avhengige av noen person eller spesiell informasjon om noen vil vite konfigurasjonen som er satt opp på en bestemt node i klyngen, slik at de ikke trenger å vente på at operasjonsteamet våkner og gi disse detaljene til dem, i stedet kan de gå til versjonskontrollverktøyet og hente denne informasjonen og kan fullføre oppgaven uten forsinkelse.

Å lære av hverandre, særlig fra de andre feilene, er de største egenskapene ved samarbeid. Slik at de ikke gjentar disse feilene som noen andre allerede har gjort.

Så, utvikling er å lære av driften, og drift er å lære av utviklingen, det være seg en ny teknologi, et verktøy, eller å gjøre noe på en enklere og bedre måte. Hvor i begge er på samme side, og derfor samarbeider de med hverandre ved å lære av hverandre.

Operasjoner pleide alltid å føle at dev-teamet er veldig tregt og at de ikke kan levere i tide, nå som de samhandler med utviklingsteamet på en daglig basis, forstår de hva som forårsaker forsinkelsen, det være seg mindre klarhet i krav, designproblem, kodingsproblem eller annet verktøyproblem.

Selv de kaster inn og gir sine verdifulle forslag å forbedre.

I tilfelle problemer, enten fra produksjonen eller fra utviklingssiden, introduserer DevOps en kultur for å først løse problemet enn å prøve å finne ut hvem eller hvilket team som har introdusert dette problemet. Og så prøver alle å fokusere på å løse problemet i stedet for å kaste bort tid på å finne ut hvem som forårsaket problemet.

Så, slutte å skylde på og vurdere hver enkelt sak som sin egen og komme frem for å løse dem sammen og støtte problem, det er igjen et samarbeid å støtte hverandre under problemene deres.

Så, jeg kan si, slutte å skylde på spill, skylden på spill er et kjennetegn på samarbeid igjen.

Når alle begynner å tenke ofte i samme retning, er samme tankesett og jobber med de samme aspektene og fremgangsmåtene igjen et samarbeid som når noen nye funksjoner blir utviklet, alle tenker på hvordan man kan teste dette, hvordan man distribuerer dette, hvordan man overvåker dette, er et samarbeid.

Så, ofte tenker, er teamet et kjennetegn på samarbeidet igjen.

La oss ta en pause nå og forstå litt mer om samarbeid i vår neste video.

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^