DevOps – förenar utveckling och drift

Historiskt kom utvecklingen med regelbundna större mjukvarusläpp som drift skulle kvalitetssäkra och sätta i produktion. För att säkerställa stabilitet byggde drift upp omfattande processer.

När många utvecklingsorganisationer anammade agila utvecklingsmetoder, som bl a syftar till att producera mindre leveranser oftare så harmoniserade detta inte med de byråkratiska driftsprocesserna. Under 2009 organiserades, av bl.a. Patric Debois i Belgien, en serie workshops för att adressera detta problem och termen DevOps blev myntat.

Syftet med DevOps är att etablera en kultur och miljö som möjliggör att utveckling, testning och produktionssättning av mjukvara kan ske snabbt, frekvent och mer tillförlitligt vilket ger:

• Snabbare värdeskapande – kunder/användare får behov uppfyllda snabbare.
• Förbättrad kundupplevelse – kontinuerlig diskussion kring behov och återkoppling på lösningar.
• Ökad innovationsförmåga – mindre spill och möjlighet att prova sig fram.

DevOps kan ses som en utvidgning av agila utveckligsprocesser till att även innefatta drift. Följande punkter sammanfattar några viktiga principer:

• Samarbete – att komma ifrån "silos". Utveckling, test och drift behöver samarbeta för att få till ett effektivt flöde.
• Automation – för att kunna hantera många små leveranser måste så mycket som möjligt vara automatiserat (t ex. byggmiljö, testning, produktionssättning, versionshantering och mätningar).
• Återkoppling – handlar både om att bygga in (automatisera) avstämningar i utveckling, test och drift och att etablera återkoppling med kunder och användare om hur lösningar fungerar.
• Mätningar - basen för kvantitativ kontinuerlig förbättring vilket är centralt i DevOps.

För att DevOps skall fungera så finns det några fundamentala processer och kvalitetsaspekter som man måsta adressera för att lyckas:

• En bra arkitektur. För att kunna utveckla och driftsätta nya funktioner utan att påverka det befintliga systemet allt för mycket så måste funktionerna vara relativt isolerade. Det är också viktigt att hitta eventuella beroenden och förstå hur de skall hanteras under utvecklingen. Oförutsedda sidoeffekter kan bli mycket allvarligare om man har en kort testfas.
• Kvalitet i utvecklingen. Om man skall driftsätta system ofta finns det begränsad tid för att hitta och rätta fel vilket kräver att kvaliteten från utvecklingen måste vara hög.
• Automatiska tester. Även om vi har hög kvalitet från utveckling måste den kompletteras med olika typer av automatiserade tester (enhetstester, integrationstester, systemtester, etc).
• Realistisk testmiljö. Det måste finnas realistiska, dvs produktionslika,  testmiljöer. Detta är ofta en stor utmaning då driftmiljöerna kan vara enorma. Ofta har man inte fast uppsatta testmiljöer, utan måste snabbt (automatiskt) kunna skapa och lämna tillbaka miljöerna.
• Noggrann konfigurationskontroll. Vi måste hela tiden veta vilka versioner som är i drift var, och vilka ändringar de innehåller. Vi måste också ha möjlighet att rulla tillbaka ändringar om något skulle ha gått fel. Flera organisationer låter användarna köra på olika versioner för att jämföra användbarheten, så kallad A/B testning.
• Snabba men kontrollerade driftsbeslut. Även om alla i teorin skulle kunde driftsätta ändringar så måste vi ha en kontrollerad process för att minska riskerna.
• Automatisk driftsättning: Eftersom vi driftsätter nya versioner dagligen måste processen och systemen för att driftsätta nya versioner vara automatiserad.

Att införa DevOps är, som ofta när man inför nya arbetssätt, en utmaning i förändringsledning, speciellt som det inbegriper kulturaspekter.

1. Affärsnytta och ledningens välsignelse
   Att tydliggöra de förväntade effekterna är viktigt vid allt förändringsarbete. Att kvantifiera kan vara svårt men som belöning har man lättare  att få ledningens acceptans för införandet. Säkerställ att förbättringsmålen skapar gemensamma drivkrafter för utveckling, test och drift.
2. Se helheten
   Skapa förståelse för vilka delar som är involverade i leveransprocessen. Tydliggör leveransflödet, definiera de ingående stegens syfte och kriteria för passage:
   t ex: Utveckling ⇒ Bygg ⇒ Versionshantering ⇒ Testmiljö ⇒ Produktionsmiljö 
3. Identifiera flaskhalsar och onödigt arbete
   Gör en värdeströmsanalys och identifiera åtgärder för ett så effektivt flöde som möjligt. Vanliga källor till ineffektivitet är:
   - Onödig overhead (t ex överlämnanden mellan individer/team
   - Oönskat omarbete (t ex fel hittade i test och produktion
   - Överflödig funktionalitet/prestanda
   - Manuella arbetssteg som (enkelt) kan automatiseras
4. Gemensamt automatiserat flöde
   DevOps kan kräva stora investeringar för att automatisera leveransflödet. Det finns många leverantörer på marknaden som säljer DevOps-verktyg som stöder olika delar av processen, men utan en bra process så blir inte verktygen effektiva. Alla parter behöver gemensamt arbeta fram en bra lösning för en gemensam process och verktygskedja.
5. Investera i kompetens och samarbete
   Man måste hantera både kultur- och organisationsaspekter. Drift och utveckling (och ibland även test) har ofta varit skilda världar med olika historik,  mål och verktyg. Då DevOps kräver att det som ofta varit olika silos skall bli ett sammanflätat flöde krävs att alla får en övergripande förståelse för hela flödet.
6. Mät - visualisera
   Baserat på syfte i punkt ett, definiera de mätningar som visar hur man ligger mot målbild. För att bibehålla intresset visualisera både progress och process.

Införandet av DevOps är inget som kan göras över en natt. Det viktiga är att utgå från vilken affärsnytta som skall realiseras och sedan sträva mot principerna,  vara flexibel och testa och se vad som fungerar. Det gäller att minska kostnaderna för att misslyckas, så att man vågar sträva mot en ”lean start-up” process ”Bygg – Mät – Förbättra” !