Så installerar du DevOps i din organisation

Ett av de tidiga framträdandena där Dev och Ops tillsammans presenterade hur de fick ner ledtiderna var när Flickr höll sin episka presentation på Velocity-konferensen i San Francisco. Patrik Dubois brukar också nämnas som den som myntade begreppet DevOps, som alltså är en lek på orden Developer och Operations.

Varför, vad är problemet?
Det underliggande fenomemet som DevOps (iaf tidigt) adresserar är att Dev-sidan (utveckling) av en IT-organisation från affärssidan hör: "Utvecklare snabbare, ge oss nyheter oftare, tidigare, fortare, ..."
Ops-sidan (drift) hör i sin tur från affärssidan: "Systemen skall vara tillgängliga 24/7, kanonstabila utan några som helst avbrott". Således har vi konflikt i hur ofta vi vill uppdatera våra system: Ops så sällan som möjligt så vi får stabil drift, och Dev så ofta som möjligt så vi snabbt kan komma ut med ny (eller justerad) funktionalitet.

Vad är lösningen?
Lösningen är givetvis att riva ned väggen mellan avdelningarna. Förenklat behöver Dev se till att det man vill att Ops skall drifta är bra anpassat ur Ops-perspektiv, och Ops behöver hjälpa Dev med detta! Den som vill beskriva hur det ser ut från sidan skulle kunna säga "de har automatiserat allt som går, allt som går är under versionskontroll och innan det går i produktion så är det redan automatiskt testat". Dvs installation, smoke test, uppsättning av miljöer såsom OS och tredje-partare, lastbalansering, backup-jobb, ... - allt är automatiserat och versionkontrollerat. Minsta förändring i någon miljö är fullt spårbar. Vi har inte råd att låta människor göra datorers jobb!

Utmaningarna är många
Listan över hinder att ta sig över brukar inte vara kort. Att automatisera är inte gratis, framför allt inte första gången. Kostnaden består dels i att det är nya verktyg, nya rutiner, nya fel och nya lärdomar att dra. Det gäller inte bara Ops utan lika mycket Dev. Att få dessa att sitta tillsammans kräver inte sällan att ledning och organisationen skapar gemensamma mål, och förutsättningar. Givetvis skall det vara affärsmässiga drivkrafter som driver organisationen mot DevOps - det skall finnas affärsnytta som man vill uppnå. När den är tydligt uttryckt och blir konkret ner till vardagsarbetet kommer arbetet med att gå mot DevOps-kultur bli mycket enklare.

Hur gör man då?
Continuous Integration är idag mainstream - det är få utvecklarorganisationer som inte har en byggmaskin igång som centralt bygger och testar varje kod-incheckning. Nästa steg mot att minska skräcken vid drifttagning är att få Continuous Delivery på plats. Hur man automatiserar sina miljöer, bygger sina pipelines och testar är givetvis starkt varierande beroende på organisation och produkt. I kursen Continuous Delivery så går vi igenom en implementation med en enkel produkt. Vi visar också på ett zero downtime-deployment-mönster (Blue/Green) med lastbalancering i molnet. Vi använder moderna verktyg och har inget fusk. Från 0 till 100 på några timmar, med en komplett versionskontrollerad miljö, produkt och pipeline!

Fredrik Wendt är Professional Scrum Trainer (Scrum.org) och jobbar som Agile Software Development Coach på Growing Agility. I vardagen sliter han i huvudsak med det tekniska och håller oftast till vid tangentbordet, kodandes i en Docker container. Computer Sweden rankade Fredrik som en av Sveriges 100 bästa utvecklare 2012. Genom coding dojos (oftast) hjälper han team ta till sig test-driven utveckling, clean code och andra färdigheter under Software Craftsmanship-temat.




Hos Informator håller Fredrik kurserna Professional Scrum Developer (Java), Docker-workshop, Continuous Delivery Hands-on samt Scrum Master (+certifiering).

Läs mer

Så installerar du DevOps i din organisation

Ett av de tidiga framträdandena där Dev och Ops tillsammans presenterade hur de fick ner ledtiderna var när Flickr höll sin episka presentation på Velocity-konferensen i San Francisco. Patrik Dubois brukar också nämnas som den som myntade begreppet DevOps, som alltså är en lek på orden Developer och Operations.

Varför, vad är problemet?
Det underliggande fenomemet som DevOps (iaf tidigt) adresserar är att Dev-sidan (utveckling) av en IT-organisation från affärssidan hör: "Utvecklare snabbare, ge oss nyheter oftare, tidigare, fortare, ..."
Ops-sidan (drift) hör i sin tur från affärssidan: "Systemen skall vara tillgängliga 24/7, kanonstabila utan några som helst avbrott". Således har vi konflikt i hur ofta vi vill uppdatera våra system: Ops så sällan som möjligt så vi får stabil drift, och Dev så ofta som möjligt så vi snabbt kan komma ut med ny (eller justerad) funktionalitet.

Vad är lösningen?
Lösningen är givetvis att riva ned väggen mellan avdelningarna. Förenklat behöver Dev se till att det man vill att Ops skall drifta är bra anpassat ur Ops-perspektiv, och Ops behöver hjälpa Dev med detta! Den som vill beskriva hur det ser ut från sidan skulle kunna säga "de har automatiserat allt som går, allt som går är under versionskontroll och innan det går i produktion så är det redan automatiskt testat". Dvs installation, smoke test, uppsättning av miljöer såsom OS och tredje-partare, lastbalansering, backup-jobb, ... - allt är automatiserat och versionkontrollerat. Minsta förändring i någon miljö är fullt spårbar. Vi har inte råd att låta människor göra datorers jobb!

Utmaningarna är många
Listan över hinder att ta sig över brukar inte vara kort. Att automatisera är inte gratis, framför allt inte första gången. Kostnaden består dels i att det är nya verktyg, nya rutiner, nya fel och nya lärdomar att dra. Det gäller inte bara Ops utan lika mycket Dev. Att få dessa att sitta tillsammans kräver inte sällan att ledning och organisationen skapar gemensamma mål, och förutsättningar. Givetvis skall det vara affärsmässiga drivkrafter som driver organisationen mot DevOps - det skall finnas affärsnytta som man vill uppnå. När den är tydligt uttryckt och blir konkret ner till vardagsarbetet kommer arbetet med att gå mot DevOps-kultur bli mycket enklare.

Hur gör man då?
Continuous Integration är idag mainstream - det är få utvecklarorganisationer som inte har en byggmaskin igång som centralt bygger och testar varje kod-incheckning. Nästa steg mot att minska skräcken vid drifttagning är att få Continuous Delivery på plats. Hur man automatiserar sina miljöer, bygger sina pipelines och testar är givetvis starkt varierande beroende på organisation och produkt. I kursen Continuous Delivery så går vi igenom en implementation med en enkel produkt. Vi visar också på ett zero downtime-deployment-mönster (Blue/Green) med lastbalancering i molnet. Vi använder moderna verktyg och har inget fusk. Från 0 till 100 på några timmar, med en komplett versionskontrollerad miljö, produkt och pipeline!

Fredrik Wendt är Professional Scrum Trainer (Scrum.org) och jobbar som Agile Software Development Coach på Growing Agility. I vardagen sliter han i huvudsak med det tekniska och håller oftast till vid tangentbordet, kodandes i en Docker container. Computer Sweden rankade Fredrik som en av Sveriges 100 bästa utvecklare 2012. Genom coding dojos (oftast) hjälper han team ta till sig test-driven utveckling, clean code och andra färdigheter under Software Craftsmanship-temat.

Hos Informator håller Fredrik kurserna Professional Scrum Developer (Java), Docker-workshop, Continuous Delivery Hands-on samt Scrum Master (+certifiering).

Läs mer

Myt #3: När man jobbar agilt behövs inga experter

En av de absolut vanligaste vanföreställningarna med agil produktutveckling är att "alla i utvecklingsgruppen måste kunna allt lika bra, så vi behöver inga experter längre". Jag kan förstå tanken bakom detta mål, och även hur missförståndet uppstår. Låt oss kika närmare på detta.

Varför?

Finns det något bra med att alla kan exakt samma saker, exakt lika bra? Absolut! Ur ett riskperspektiv är det ju klockrent om vem som helst i gruppen kan bli påkörd av en buss utan att det påverkar det dagliga arbetet (den så kallade “bussfaktorn”). Om alla kan allt lika bra så spelar det ingen roll om det är Lisa eller Kalle som hamnar på sjukhus. "Fyll bara på med en generalist till så vi får återställer leveranskapaciteten!"

I Scrum-guiden står att läsa att teamet skall ha alla kompetenser som behövs för att leverera ett leveransklart inkrement av produkten. Om vi minimerar mängden variation inom vår utvecklarkår så blir det lättare att bygga ett sådant komplett team.

Varför inte?

Finns det då några nackdelar med utgångspunkten att "alla kan allt, lika bra"? Ja! En grundpelare inom agil systemutveckling är insikten om att värde är något annat än enbart "on scope, on budget, on time". Vi vill t ex ha en hållbar utvecklingstakt som gör att människor mår bra och trivs med arbetet, eftersom glada medarbetare är värdefulla för bolaget. Om varje människa slutar vara individuell, slutar ha sina intressen och områden de är extra duktiga inom, då har vi nått den perfekta matrisresursen: den där utvecklaren är som en siffra i ett kalkylark som går att placera i vilket team som helst utan någon särskild hemvist eller tillhörighet.

En sådan människa blir snabbt väldigt ensam, demotiverad, och kan lätt känna att han eller hon inte har ett eget värde. Man har ju inget unikt som man tillför gruppen. Hur länge skulle du stanna i en situation där du inte har något egetvärde? Där du inte tillför något som inte alla andra i gruppen också skulle kunna tillföra?

Tvärtom!

Istället värnar vi om individens inneboende motivation. Vi ser till att kombinera individens unika kompetens med andras kompetens i grupper som då får en stor bredd. Vi försöker skapa miljöer där det är fullt naturligt att man delar med sig av sin kunskap.

Det finns ett kunskapsideal som kallas “T-formade” individer. Ett T har en vertikal stapel. Det symboliserar att individen bör ha särskild djup kunskap inom ett fält. Det är denna djupa kompetens som gör att vi kan bygga avancerade, konkurrenskraftiga produkter. Men ett T har också ett horisontellt “tak”. Det symboliserar att individen bör ha en bredd i sin kompetens, så att han eller hon kan förstå något av de andra gruppmedlemmarnas specialiteter, och på så sätt se hur man kan samarbeta bättre

"Jag kanske inte kan skapa en ny prestandaprofil i lasttestningsprogramvaran, men när vår testexpert är sjuk så kan vi andra i alla fall hoppa in och köra de befintliga testen."

Detta sätt att organisera sig kallas för “tvärfunktionella arbetslag”. Att befolka dem med personer med både bredd och djup gör att vi både kan dra nytta av deras expertis, och deras förmåga att arbetsdela mellan sig. Att de besitter expertkunskaper inom olika områden gör att arbetslagen blir väldigt kompetenta när det gäller att lösa många olika sorters uppgifter. Det finns forskning som visar att grupper med en heterogen uppsättning erfarenheter och kompetenser presterar bättre än en homogent sammansatt grupp. Eller som en av principerna bakom det agila manifestet uttrycker det:

The best architectures, requirements, and designs emerge from self-organizing teams.

Om vi alla skall se ut, gå och vara likadana ut försvinner utrymmet för individen att utvecklas och frodas. Istället ser vi till att teamet som helhet innehåller alla relevanta kompetenser, i en bra mix. Myten är krossad. Jag avslutar med ytterligare en princip:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Lär dig Agile på riktigt hos Informator. Ta en titt på vår nya endagarskurs Introduktion till Agila metoder. Hela vårt utbud hittar du på Agile-sidan.

Läs mer