Mitt första inlägg här och jag vill höra mig för om hur det tänks och tycks kring DevOps och DevSecOps?
Jag har följt rörelsen under ett antal år som serverdriftare och utvecklare och har väl en del tankar och åsikter.
Några formuleringar om DevOps och DevSecOps:
Cloud Native Computing Foundation:
"En metodik där team tillsammans äger hela processen från systemutveckling till drift i produktion, därav namnet DevOps. . . . DevOps kräver att utvecklare och drifttekniker fokuserar på mindre komponenter (inte större funktioner) vilket leder till mindre överlämningar (en vanlig felkälla)."
Google Cloud:
“En organisatorisk och kulturell rörelse som syftar att öka takten på mjukvaruleveranser, förbättra tillgängligheten och pålitligheten för tjänster och att bygga ett delat ägarskap emellan intressenter.”
Department of Defense:
"DevSecOps är en samling aktiviteter och förmågor inom systemutveckling som kombinerar utveckling, säkerhet och IT-drift med syftet att göra leveranser säkrare och att korta ned utvecklingsprojektens livscykler. Ny funktionalitet, buggrättningar, säkerhets- och andra uppdateringar ska kunna ske oftare och på ett mer automatiserat sätt. Säkerhet appliceras i alla faser av utvecklingsprojekten."
DevOps är ju inget som ersätter Lean och Agile, men delar av det kan (potentiellt) hjälpa oss att jobba enligt Lean- och Agile-principer.
Den årliga State of DevOps Report som gjorts sedan 2014 menar att de bästa måtten för en organisations utvecklingskapacitet är:
- Ledtid till release (från incheckad källkod till driftsättning)
- Hur ofta driftsätter vi nya releaser
- Tid det tar att återställa en tjänst (MTTR - Mean Time To Restore)
- Hur ofta orsakar en förändring/release problem
Och det låter väl i alla fall sunt?
Jag läste boken Accelerate förra hösten (från initiativtagarna bakom rapporten) och skrev ner några meningar...
Några dåliga sätt att mäta utvecklingskapacitet i organisationer:
-
Vad man använder för teknik. Det spelar en viktig roll men kultur och processer är viktigare föga förvånande, sedan kan verktyg hjälpa till i en kulturförflyttning
-
Om man har en CAB-funktion. Det visade sig t.o.m. att många org som förlitade sig på mer flexibla processer som parprogrammering eller peer review ofta var bättre både på att leverera OCH tillgänglighet och stabilitet i drift
-
Att mäta antal rader kod. Föga förvånande är det ett ruskigt dåligt mått. En lösning med 10 rader kod är - givetvis - ofta att föredra än samma lösning med 1000 rader kod (om den korta lösningen samtidigt är läsbar och inte för komprimerad). Det bästa är förstås om vi kan lösa ett problem helt utan kod eller genom att ta bort kod! Vem älskar inte att få radera kod ibland?
-
Snabbaste leveranserna. Undvik att fokusera så mycket på det. Det kan leda till att team nedprioriterar samarbete med andra team för att det tar tid från kodknackning och leverans.
Undvik att belöna utvecklare för mängden mjukvara som levereras och att belöna driftteam för stabilitet. Det leder gärna till att utvecklare "kastar kod" på drift och drift sätter upp plågsamma processer för att förhindra förändring.
Vad ger det att ha en hög utvecklingskapacitet då? God förmåga att ta fram och bygga nya lösningar, anpassa sig till förändring, leverera värde till användarna, osv.
Man kom fram till att mått på utvecklingskapacitet bör fokusera på två nyckelaspekter:
- Maximal verksamhetsnytta
- Goda resultat, inte hur mycket det jobbas.
![;) 😉](https://community.dataportal.se/assets/plugins/nodebb-plugin-emoji/emoji/android/1f609.png?v=aitcmg865au)
En bör inte uppmuntra att maximera mängden utfört arbete om det ändå inte hjälper organisationens mål (vad sa ni?!
)
Därav är genuin förståelse för vision och mål så himla viktigt!
Något som inte är med bland dem måtten är tiden det tar att identifiera problem och att designa/ta fram potentiella lösningar. De kom fram till att det var många variabler i denna fas så att det var svårt att följa metodiskt (inte att det är mindre viktigt). Det är hög osäkerhet på estimat och resultat.
Det får bli en annan tråd en annan dag...
Hur ser ni på DevOps? Anammar ni denna lära? Tycker ni mest att det är ett nytt modeord på vad ni redan gjort i 3000 år? (vilken sorts vampyr är du?!)
Låter det som namnet på en hel massa produkter som leverantörer försökt sälja in för att lösa alla era problem?
Personligen tycker jag nog att det är på tok för mycket brus kontra signal. Men känner ändå att det finns mycket bra stoff här som jag gärna ställer mig bakom och drar nytta av. Som sagt, intressant att höra era tankar!