SDLC-telemetri

Äldre agila metoder

Under det senaste decenniet har organisationer sett en kraftig ökning av behovet av att snabbt leverera mjukvarulösningar av hög kvalitet för att möta ständigt förändrade marknadskrav och hantering av hård konkurrens. Tillsammans har IT-företag som stöder dessa organisationer bytt till denna agila metod för att hålla jämna steg med den växande efterfrågan på snabbare leverans av programvara.

Att förstå sig på Agil systemutveckling

Den agila modellen, en kombination av inkrementella och iterativa processer, har sitt ursprung i att påskynda leverans av programvara, säkerställa kundnöjdhet och erbjuda flexibiliteten att kontinuerligt kunna anpassa och förbättra sig. Enligt den agila modellen delades företagskraven upp i mindre delar, vilket gjorde det möjligt för utvecklingsteamet att leverera programvara i kortare iterationer mycket mer regelbundet. I takt med att agila metoder blev mer stadgat började nya automatiseringsteknologier och effektiviseringsprocesser växa fram så att utvecklingsteam kan integrera mindre delar av kodning kontinuerligt.

Men dessa mindre delar av kodning måste dock testas kontinuerligt så att högkvalitativ kodning kan integreras flera gånger. Även om denna ökade effektiviteten för mjukvaruutveckling bidrog det till belastning för testteamet med all kontinuerlig testning och distribution. I sin tur blev leveransen av den övergripande programvaruprodukten försenad, vilket därmed förstör hela syftet med den agila metoden.

Resan från Agile till DevOps

Snart insåg organisationer att hela livscykeln för mjukvaruutveckling borde behandlas som en enda process, och att det mesta borde automatiseras. Utvecklings- och driftsteamen som arbetar i silor slogs samman, vilket ledde till framväxten av DevOps.

DevOps är en sammanslagning av metoder, kulturfilosofier och verktyg som gör det möjligt för en organisation att leverera applikationer/tjänster med hög hastighet och förbättra produkter konsekvent. Organisationer som har gått bort från traditionella programvaruutvecklingsprocesser mot DevOps skördar fördelarna med snabbare tid till marknaden och därmed också ökad kundnöjdhet.

Element av DevOps: CI/CD

Kontinuerlig integrering är en mjukvaruutvecklingsmetod där utvecklare regelbundet slår samman kodändringar till ett centralt arkiv som sedan används för att köra automatiserade byggnader och tester. Tanken bakom kontinuerlig integrering är att identifiera och ta itu med fel snabbare, förbättra kvaliteten och minska tiden till marknaden.

Kontinuerlig leverans är en mjukvaruutvecklingsmetod där kodändringar byggs, testas och integreras automatiskt för att släppas, vilket tar kontinuerlig integrering ett steg vidare genom att distribuera kodändringar i en test- och produktionsmiljö efter byggfasen.

Kontinuerlig distribution är en annan utbredd DevOps-praxis där varje nybyggnad automatiskt distribueras när varje betydande ändring görs i koden.

Behovet för mätvärden

Medan många organisationer har antagit agila metoder och DevOps har mätning och hantering av programvaruutveckling aldrig varit lätt utan att definiera mätvärden, speciellt med tanke på att processen blir allt mer komplex och decentraliserad. I större organisationer där flera geografiskt olika team jobbar med samma applikation blir det svårt att identifiera processfördröjningar och beroenden.

Att mäta effektiviteten av DevOps med DORA-mätvärden

DORA-mätvärden spelar en viktig roll när det gäller mätningen av lagets prestationer. Ett resultat av år av forskning utförd av DevOps Research and Assessments -teamet (DORA) ledde till följande fyra DORA-mätvärden: distributionsfrekvens, ledtid för ändringar, tid för att återställa tjänsten samt förändringsfel.

DORA-mätvärden hjälper ledare att mäta genomströmning av programvaruleverans (time to market) och kvalitet (tillförlitlighet). Dessa mätvärden möjliggör informerade och datadrivna beslut som leder till kontinuerliga förbättringar som kan kopplas till mätbara digitala transformationsmål.

Utmaningar med Agile och DevOps

Integrationen av DevOps och agile har gjort det möjligt för organisationer att vara ett steg före på marknaden, men den nya mjukvaruutvecklingsmetoden är inte helt utan nackdelar. Det är särskilt utmanande när team börjar arbeta i hastighet och skala. Några av de viktigaste nyckelutmaningarna man stöter på är:

• Frånvaro av en enda sanningskälla för bättre synlighet
• Försenade återkopplingsslingor förlänger kurskorrigering
• Att det används en mängd olika verktyg; varje verktyg fungerar i silor med sitt egna rapporteringssystem
• Problem med att den manuella datainsamlingen och metriska beräkningen är besvärlig, felbenägen och inte i realtid

Telemetri: Automatiserad övervakning och mätning för SDLC-excellens

Det är möjligt att förflytta sig bortom dessa utmaningar med hjälp av kontinuerlig automatiserad datainsamling, mätning och övervakning tidigt i SDLC, från historia och kod till distribution. Denna vänsterförskjutning i programutvecklingscykeln kommer att göra det mycket lättare för DevOps-team att arbeta sömlöst, identifiera flaskhalsar och vidta korrigerande åtgärder tidigt.

Agile och DevOps är pågående processer som kräver konsekvent feedback för att kunna förbättra sig. Alla steg för programvaruutvecklingslivscykeln (SDLC) som kravinsamling, kodning, byggnad, testning, distribution och release kan förbättras genom att kontinuerligt mäta och övervaka nyckeltal tidigt i SDLC.

Telemetri är en automatisk inspelning och överföring av data från avlägsna eller oåtkomliga källor till ett IT-system på en annan plats för övervakning och analys . Det lägger tillrätta för konstant övervakning och presentation av diagram för intressenter i realtid för att möjliggöra snabb identifiering av frågor. Det gör att team kan åtgärda problem tidigt och förhindra att det uppstår komplikationer som kan vara dyra att lösa senare. Med telemetri är det till och med möjligt att bestämma viktiga affärsmetoder och skapa varningar om avvikelser inträffar.

Ledande kontra eftersläpande indikatorer

Ledande indikatorer är som insatser och mäter aktiviteter som är nödvändiga för att uppnå mål. Även om de kan vara svåra att mäta, är de lätta att påverka direkt för att uppnå bättre resultat. Släpande indikatorer är som resultat, och de mäter de faktiska resultaten. Även om de är lätta att mäta så är de inte lätta att förbättra direkt.

DORA-mätvärden som fokuserar på time-to-market (tid till marknad) och kvalitet faller under kategorin fördröjningsmätvärden. Men det är flera faktorer som påverkar dem indirekt. Lead-mätvärden kan mäta dessa faktorer, och om de förbättras kontinuerligt så kommer de att påverka lagringsmätvärdena direkt för hastighet och kvalitet.

I applikationens sammanhang måste organisationer identifiera grundläggande prestationsindikatorer och definiera ledningsvärden. Tabellen nedan är en bra utgångspunkt för att definiera lead-mätvärden. Även om det inte är uttömmande så kan det användas för att skapa baslinjer och följa trenderna. Genom att bestämma trendens riktning så får vi en förståelse för om teamen rör sig i rätt riktning.

Automatisera datainsamling, mätning och presentation

Organisationer som vill komma igång bör identifiera de prestationsindikatorer som ska mätas, dvs. definiera ledningsvärdena. Som ett nästa steg i processen bör de identifiera olika SDLC-verktyg där data kan samlas in. Insamlad data måste omvandlas och lagras. En del av den data som insamlas kan presenteras direkt, medan resten behöver beräknas. Efter beräkning bör mätdata visas visuellt som diagram för team för att kunna utvärdera och få insikter om framsteg och flaskhalsar som hindrar dem från att stiga upp mot fördröjningsvärdena.

Ovanstående process för datainsamling, beräkning och presentation bör vara helt automatiserad så att alla team kan få kontinuerlig insikt för de definierade mätvärdena. Telemetri bör också kopplas in tidigt i SDLC så att alla team har tillgång till insikter och kan vidta korrigerande åtgärder.

Arkitekturdiagrammet nedan representerar en enkel 3-stegs mikrotjänstbaserad implementering som utnyttjar befintliga visualiseringsplattformar som Grafana.

Varför telemetri?

• Den konsoliderade vyn av SDLC-data från telemetri-instrumentpanelen stöder datadrivet beslutsfattande. Telemetri-instrumentpanelen kan också erbjuda robust programstyrning för hela företaget för att förbättra SDLC-kvalitet och tillförlitlighet.
• Telemetriinstrumentpanelen kan ge djupgående realtidsinsikter över programvaruutvecklingscykeln för snabbare återkopplingsslingor, och hjälpa intressenter att fatta välgrundade beslut för bättre utgåvor.
• Organisationer som investerar i telemetri tidigt i SDLC-processen sparar veckor av ansträngning för att rapportera DevOps- och SDLC-mätvärden, vilket leder till snabbare behandlingstid, förbättrat beslutsfattande och större transparens.

Avslutande tankar

Det vänstra skiftet av telemetri i Agile DevOps-resan är verkligen anmärkningsvärt. Tillgång till telemetrisk data i Pre-prod-miljön har gjort det möjligt för DevOps-teamet att automatisera feedback och övervaka applikationer i realtid. Som ett resultat kan team enkelt visualisera och lösa problem tidigare när de uppstår, vilket säkerställer snabbare leverans av programvara och förbättrad time-to-market.