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).
Skicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.