en praktisk väg till DevOps mognad

alla smidiga metoder är meningslösa utan verkliga DevOps-metoder. Buzzword missbrukades i många organisationer. Om du säger att du har mognat agila team och du har en DevOps-ingenjör eller DevOps-team, som förmodligen inte går i rätt riktning. DevOps är en kultur snarare än ett lagnamn eller beteckning. Att ta en cue från CMM (Capability Maturity Model) detta försök är att hjälpa en organisation att veta var de står i en DevOps resa och vägen framåt. Med lite brainstorm mellan utvecklings-och Ops-team kan detta utökas och anpassas till organisationens behov.

inget nummer är dåligt eftersom det hjälper en individ eller organisation att växa.

lycklig kund

till skillnad från CMM är detta inte en modell som du behöver bevisa för någon certifieringsorganisation. Det enda certifikatet du får är från dina nöjda kunder eller affärspartners. Det är en modell för att själv reflektera och hjälpa företag att växa. Själva syftet med alla IT-team är att skapa värde genom att göra hållbara, förutsägbara leveranser med kvalitet.

Detta är en enkel modell som från utvecklare till CxO kan förstå och relatera.

innan jag diskuterar om modellen. Vi måste förstå behovet av denna modell. För många år sedan, Melvin Conway i sitt papper ” Hur uppfinner utskotten?”kom upp med avhandling som blev känd som Conways lag.

varje organisation som utformar ett system (definierat brett) kommer att producera en design vars struktur är en kopia av organisationens kommunikationsstruktur.

lagen bygger på resonemanget att för att programmodulerna ska fungera måste flera personer kommunicera ofta med varandra. Därför kommer mjukvarugränssnittsstrukturen för ett system att återspegla de sociala gränserna för den eller de organisationer som producerade den, över vilken kommunikation är svårare.

Låt oss titta på hur detta fungerar i mjukvaruutveckling med ett verkligt scenario. Radha bygger en frontskärm som visar detaljerade attribut för en produkt. Säg att den här produkten är en mobiltelefon. Få vanliga produktdetaljer är färg, pris, dimensioner, betyg etc. En ny förordning kom för att visa SAR-värdet på handenheten. Skärmen som hon designade fungerar med micro service call. Hon pratade med Sunil som arbetar i datateam. Han sa att de bara kan skicka data i platt fil. Det finns en tydlig koppling mellan två moduler. Detta är ett scenario varje IT-team stöter på om inte alla 100% gånger men majoriteten av gånger. Detta är bara en designfråga. Problemet är bredare. Vad händer om det andra lagets prioriteringar skiljer sig mycket från vad ditt lag gör? Dina krav kan vara LÄGSTA prioritet för dem medan dina intressenter kör bakom dig.

det första steget till framgångsrik DevOps-implementering är att vara öppen med organisationsförändringar.

organisationsförändringar

Låt mig diskutera 5 nivåer av mognad:

  1. Initial: i denna fas arbetar team i silor och det finns bara, behöver baserat samarbete. I ett möte med alla lag tillsammans, om du frågar vem som äger ”produkten” kommer du inte att ha några händer som höjer. Tiden till marknaden är vanligtvis längre, går till månader och ibland år. Prioriteringarna fastställs på teamnivå men inte på produktnivå. Detta kommer att leda till att varje lag har sina egna prioriteringar. Eftersom det inte finns någon definierad process är varje försök som att återuppfinna hjulet. Detta kommer att leda till kvalitetsproblem och längre tidslinjer. Team gör mestadels manuella distributioner och manuella ingrepp. Samt.. detta är inte ett dåligt tillstånd. Så här skulle det mesta av utvecklingen börja.

2. Repeterbar: lag arbetar fortfarande i silor. Det finns en viss grad av automatisering inom teamet. När en kris träffar, team definierar sin egen process och följer tills krisen slutar. Bara goda nyheter är att några av dessa kan bli repeterbara processer när krisen träffar igen.

3. Definierat: detta är en bra utgångspunkt för utsäde DevOps kultur med ett centraliserat team. Detta team förstår olika tekniker som Dev-Team använder och verktyg baseras på det nuvarande behovet. Att vara ett centraliserat team, det är inte lätt att övervaka vad varje lag gör och så vissa beslut lämnas till lag att experimentera. Central team består vanligtvis av experter och dev team kommer att ha vissa människor med grundläggande förståelse och kunskap.

4. Hanteras: eftersom det centrala DevOps-teamet förstår organisationsverktygslandskap testas flera miljöer och verktyg. Konsekventa och repeterbara processer följs av flera Team. Verktygskedjan väljs utifrån användningsfall snarare än personliga val. Övervakningsverktyg för alla processer introduceras och används starkt av team för att fatta beslut.

5. Optimerad:

framgång för en bra ledare definieras av att inte ha anhängare utan av förmågan att skapa stora ledare.

sista etappen av DevOps mognad är att få DevOps-teamet att försvinna. Det här kan se ut som motintuitivt. I detta skede är DevOps en del av produktutvecklingsteamet snarare än en separat enhet. Använda infrastruktur som kod, containrar, orkestrering etc. zero touch-distribution uppnås. Nu om du ringer till alla som arbetar med en produkt och frågar vem som äger produkten, kommer du att ha några självsäkra händer som höjer utan tvekan. Data från övervakningsverktyg används för att välja ny uppsättning verktyg (inklusive Infrastruktur, programmeringsspråk, tekniker). Beslut baseras på data snarare än personliga preferenser. Produktteam är redo att distribuera kod när som helst och när som helst. De älskar ”affärsvärdet” och behandlar det som ett husdjur. Allt annat behandlas som nötkreatur.

DevOps Mognad Modell.

Lämna ett svar

Din e-postadress kommer inte publiceras.