en praktisk vei til DevOps modenhet

enhver smidig metodikk er ubrukelig uten ekte DevOps praksis. Buzzword ble misbrukt i mange organisasjoner. Hvis du sier at du har modnet agile-lag, og du har En DevOps engineer eller DevOps-team, som sannsynligvis ikke går i riktig retning. DevOps er en kultur i stedet for et lagnavn eller betegnelse. Å ta en cue FRA CMM (Capability Maturity Model) dette forsøket er å hjelpe en organisasjon til å vite hvor De står i En DevOps-reise og vei fremover. Med noen brainstorm mellom Utviklings-og Ops-lag kan dette utvides og tilpasses organisasjonens behov.

Ingen tall er dårlig som for det hjelper en person eller organisasjon til å vokse.

Happy Customer

I Motsetning TIL CMM, er dette Ikke en modell som du må bevise for noen sertifiseringsorganisasjon. Det eneste sertifikatet du får er fra fornøyde kunder eller forretningspartnere. Det er en modell for å reflektere og hjelpe virksomheten til å vokse. Selve formålet MED ALLE IT-team er å skape verdier ved å gjøre bærekraftig, forutsigbar levering med kvalitet.

Dette er en enkel modell som Fra Utvikler Til CxO kan forstå og forholde seg.

Før jeg diskuterer om modellen. Vi må forstå behovet for denne modellen. Mange år siden, Melvin Conway i sin papir » Hvordan komiteer oppfinne?»kom opp med avhandling som ble kjent Som Conways lov.

enhver organisasjon som designer et system (definert bredt) vil produsere et design hvis struktur er en kopi av organisasjonens kommunikasjonsstruktur.

loven er basert på begrunnelsen at for at programvaremodulene skal fungere, må flere personer kommunisere ofte med hverandre. Derfor vil programvaregrensesnittstrukturen til et system gjenspeile de sosiale grensene til organisasjonen(e) som produserte den, over hvilken kommunikasjon er vanskeligere.

La oss se på hvordan dette fungerer i programvareutvikling med et ekte scenario. Radha bygger en front end skjerm som viser detaljerte attributter av et produkt. Si at dette produktet er en mobiltelefon. Få vanlige produktdetaljer er farge, pris, dimensjoner, karakterer etc. En ny regulering kom for å vise sar-verdien av håndsettet. Skjermen som hun designet fungerer med micro service call. Hun snakket Med Sunil som jobber i data team. Han sa at de bare kan sende data i flat fil. Det er en klar frakobling mellom to moduler. Dette er et scenario HVERT IT-team kommer over om ikke alle 100% ganger, men flertallet av ganger. Dette er bare et designproblem. Problemet er bredere. Hva om det andre lagets prioriteringer er svært forskjellige fra hva laget ditt gjør? Dine krav kan være lavest prioritet for dem mens interessentene dine kjører bak deg.

det første skrittet til Vellykket DevOps-implementering er å være åpen med organisasjonsendringer.

Organisasjonsendringer

la meg diskutere 5 nivåer av modenhet:

  1. Initial: i denne fasen jobber lagene i siloer, og det er bare, trenger basert samarbeid. I et møte med alle lagene sammen, hvis du spør hvem som eier «Produktet», vil du ikke ha noen hender som øker. Tid til markedet er vanligvis lengre, går til måneder og noen ganger år. Prioriteringene er satt på teamnivå, men ikke på produktnivå. Dette vil føre til at hvert lag har sine egne prioriteringer. Siden det ikke er noen definert prosess, er hvert forsøk som å gjenoppfinne hjulet. Dette vil føre til kvalitetsproblemer og lengre tidslinjer. Teamet gjør for det meste manuelle distribusjoner og manuelle inngrep. Vel.. dette er ikke en dårlig tilstand. Slik starter det meste av utviklingen.

2. Repeterbar: Lag jobber fortsatt i siloer. Det er en viss grad av automatisering i teamet. Når en krise treffer, definerer teamet sin egen prosess og følger til krisen slutter. Bare gode nyheter er at noen av disse kan bli repeterbare prosesser når krisen treffer igjen.

3. Definert: Dette er et godt utgangspunkt for å frø DevOps kultur med et sentralisert team. Dette teamet forstår ulike teknologier Dev team bruker og verktøy er basert på dagens behov. Å være et sentralisert lag, er det ikke lett å overvåke hva hvert lag gjør, og så noen beslutninger blir overlatt til lagene å eksperimentere. Sentralt team består vanligvis av eksperter og dev team vil ha noen mennesker med grunnleggende forståelse og kunnskap.

4. Administrert: ettersom det sentrale DevOps-teamet forstår organisasjonsverktøylandskapet, testes flere miljøer og verktøy. Konsistente og repeterbare prosesser følges av flere lag. Tool chain er valgt basert på brukstilfeller i stedet for personlige valg. Overvåkingsverktøy for alle prosessene blir introdusert og mye brukt av team for å ta beslutninger.

5. Optimalisere:

Suksess for en god leder er definert av ikke å ha tilhengere, men av evnen til å skape gode ledere.

Siste fase av devops modenhet er å få DevOps-teamet til å forsvinne. Dette kan se ut som counter intuitivt. På dette stadiet Er DevOps en Del Av Produktutviklingsteamet i stedet for en egen enhet. Bruke infrastruktur som kode, containere, orkestrering etc. null berøring distribusjon er oppnådd. Nå hvis du ringer alle som jobber med et produkt og spør hvem som eier produktet, vil du ha noen trygge hender heve uten å nøle. Data fra overvåkingsverktøy brukes til å velge nytt sett med verktøy (inkludert infrastruktur, programmeringsspråk, teknikker). Beslutninger er basert på data i stedet for personlige preferanser. Vare team er klar til a distribuere kode som helst og nar som helst. De elsker «forretningsverdien» og behandler den som et kjæledyr. Alt annet blir behandlet som storfe.

DevOps Modenhet Modell.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.