Att devopstrenden är stark märks tydligt och intresset lär inte minska. Det är lätt att förstå de principiella, och praktiska, fördelarna med att sammanföra utveckling och drift. Men som alltid går det att genomföra bra arbetsmetoder på ett dåligt sätt. Och även för dem som jobbar ambitiöst med devops lurar fällor på vägen. Utmaningarna är många.

En av fällorna rör något som kallas pipelines, vilket är ett centralt begrepp inom devopssfären. En pipeline är enkelt uttryckt en samling seriekopplade processer, med tillhörande verktygsstöd. En enkel pipeline i devopssammanhang kan till exempel bestå av planera – koda – bygga – testa – driftssätta.

Det här är ett sätt att ta sig an utmaningarna med utveckling, test och drift på ett överskådligt sätt. Det är ofta ett krav för att lyckas med automatisering. Och automatisering kan ses både som det viktigaste målet och den viktigaste förutsättningen för devops.

Läs också: Lär av Spotify för att lyckas med it-driften

Ett problem som allt fler lär få känna på är att det lätt uppstår flera pipelines på ett företag. Och det ger upphov till oönskad komplexitet, till exempel beroenden mellan pipelines, och till att olika sätt att lösa problem används, vilket försvårar automatisering.

Hur vanligt är det här i dag?

– Det är nog inte ovanligt. Ett stort problem är att mycket logik beskrivs i de olika flödena, vilket blir svårt att hantera, säger Magnus Bengtsson, plattformsingenjör på Expressen.

Magnus Bengtsson
Magnus Bengtsson.

Att definiera konfigurationer med grafiska verktyg för olika delar av ett flöde medför en risk för teknisk skuld längre fram. Eller för att prata ren svenska, det blir en jäkla röra.

I värsta fall uteblir effektiviseringsvinsterna med devops eftersom man måste lägga ner tid och pengar på att administrera olika pipelines.

Det kan handla om ett stort antal olika typer av parallella pipelines. Här är några exempel:

  • Olika delar av processen, till exempel en pipeline för utveckling och en för test.
  • Olika avdelningar på ett företag har sina egna pipelines.
  • Olika team på ett företag har sina egna pipelines.
  • Olika pipelines används för olika applikationer och tjänster, samt för olika produktfamiljer.
  • Olika tidscykler för olika typer av mjukvaror tvingar fram användning av olika pipelines.
  • Olika pipelines används för driftsättning på olika molnplattformar.

Det finns fler exempel och de kan, framför allt, kombineras på ett närmast oändligt antal sätt. Det är lätt hänt att avvika från idealet med en enda strömlinjeformad pipeline för all utveckling, test och drift. En sådan kanske inte är möjlig, eller önskvärd, men det är ditåt man bör sträva.

Hur ska man undvika pipelinekaos?

– Allt handlar om hur man jobbar med olika versioner av mjukvaror och kontrakt mellan berörda parter. Det krävs disciplin för att kunna leverera mjukvara snabbt, säger Fredrik Normén, konsult på Squeed.

Läs också: Det här är det skummaste programspråket vi sett på väldigt länge

En tolkning av de råden är att det krävs noggrannhet för att lyckas med automatisering. Om man automatiserar på en höft så blir det inte bra.

Fredrik Normén
Fredrik Normén.

Ett annat, kanske mer uppseendeväckande, råd är att undvika pipelines när man jobbar med devops och kontinuerliga leveranser:

– Vi tar mjukvara i drift direkt från kodbasen. Men vi har ett flöde för tester som utförs lokalt i containrar, berättar Expressens Magnus Bengtsson.

Han betonar dock att det kanske inte fungerar att arbeta så agilt i alla typer av verksamheter. Ett exempel är om det finns stora krav på integration mellan olika mjukvaror, ett annat om det handlar om en starkt reglerad verksamhet, som läkemedel eller finansiella tjänster.

Ett annat råd är att utnyttja containrar för att utjämna skillnader mellan olika driftsplattformar.

– Containrar ger ett utmärkt sätt att få bort skillnader mellan till exempel Java och Node, säger Magnus Bengtsson.