De allra flesta företag, myndigheter och organisationer jobbar med mjukvara på något sätt, och många bygger egen mjukvara. För ett stort antal av dem har det blivit självklart att kunna leverera nya eller modifierade mjukvaror snabbt och ofta.

Det angreppssättet kallas för kontinuerliga leveranser (continuous delivery) och inbegriper på ett naturligt sätt kontinuerlig integration (continuous integration). På vissa företag som ligger långt fram har man även börjat anamma ett förhållningssätt som heter devops, som går ut på att funktionerna, och ibland rollerna, för utveckling och drift smälter samman.

Hur går den här förändringen till på olika typer av företag?

Att det är enklare att anamma nya arbetssätt för ett relativt nystartat företag för vilket merparten av verksamheten kretsar kring en publik webbtjänst som konsumenter interagerar direkt med, än för till exempel Ericsson är ganska självklart.

Läs också: Stekhett svenskt mjukvaruföretag får miljardinvestering

Grejen är att på större företag med stora komplexa system så kan ett normalstort mjukvaruprojekt vara en, kanske liten, del av en större produkt eller tjänst. Eller av flera andra produkter eller tjänster. Teamet som utvecklar mjukvaran kan mycket väl ha flera, både interna och externa, ”kunder”.

Det här betyder att teamet i fråga med största säkerhet inte kan bestämma leveranstakten helt på egen hand. Det är rätt meningslöst att krysta fram nya versioner av mjukvaran var tredje vecka, om den stora produkten den ska ingå i som en del i bara släpps i nya versioner en gång per år.

Infinera Metro Business Group i Stockholm som gör lösningar för nätverkskommunikation har man jobbat med sådana här frågor länge.

Jan Skagerlund.
Jan Skagerlund.

– De två första faserna man bör jobba med är att först förbereda den egna organisationen på att arbeta annorlunda och sedan att få kunderna mottagliga för det, säger Jan Skagerlund, systemarkitekt på Infinera.

Omställningen till kontinuerliga leveranser är alltså en förändring som mycket väl kan initieras internt på en utvecklingsorganisation, inte av de externa kunderna. Det gäller speciellt i sammanhang när en mjukvara är en del av en större produkt eller tjänst.

Och det finns inte bara affärsmässiga skäl till att förändra sättet att jobba:

– Kontinuerliga leveranser ger snabb feedback och borgar för kontinuerlig kvalitetskontroll vilket i slutänden leder till effektiv utveckling och ett flexibelt arbetssätt. Det uppskattar de som jobbar på här, förklarar Jan Skagerlund.

Utmaningen är att jämka en viss leveranstakt internt med en annan externt. Om man nagelfar den utmaningen blir slutsatsen att om man kan leverera nya versioner av en viss mjukvara ofta, kanske till och med dagligen, så borde det gå att anpassa sig till leveranser mer sällan av den större produkten som mjukvaran ingår i. Det omvända förhållandet skulle inte fungera.

Kontentan är att lösningen är en välfungerande process för kontinuerliga leveranser, och därmed även kontinuerlig integration, på de mest detaljerade nivåerna för en stor produkt eller tjänst. Det är i alla fall ett steg på vägen om man även lyckas få till en bra process för att bygga ihop de olika delarna av den större lösningen till en färdig produkt eller tjänst.

Då är frågan, hur lyckas man med kontinuerliga leveranser av delarna, till exempel vissa mjukvaror?

Johan Malmberg.
Johan Malmberg.

– Automatiserade tester är centrala i ett maskineri för kontinuerlig integration, de ger det stora mervärdet. Det gör att man kan testa både djupare och bredare, säger Johan Malmberg, ansvarig för kontinuerlig integration och verifikation på Infinera.

Han beskriver det som att olika händelser i processen triggar till exempel uppsättningar av regressionstester.

Läs också: Nu vill Docker modernisera företagens gamla applikationer – med konsulthjälp

Men fungerar det alltid med den här automatiseringen? Litar utvecklarna på den?

– De är vana vid den här automatiseringen och har själva skrivit merparten av de automatiserade testfallen, vilket gör att de inte vill börja koda på något om det inte passerat och det inte lyser grönt på bildskärmen, förklarar Johan Malmberg.

Vad händer om fel upptäcks när testerna körs?

– Först kollar man om det är något i testmiljön, sedan i det automatiserade testramverket eller i testfallen. Därefter vet man att det är ett ’riktigt’ fel, säger Johan Malmberg.

Slutsatsen av det är att det blir svårt att införa kontinuerliga leveranser och integration om man inte har automatiserade tester som det går att lita på.

För att återknyta till Jan Skagerlunds beskrivning av de två första faserna i en omställning, att förbereda den egna organisationen och få kunderna mottagliga: Vad kommer sedan?

– Det gäller att isolera en ändring till den del den genomförs i, förklarar Jan Skagerlund.

Alltså, en väl modulariserad arkitektur gör det möjligt att genomföra ändringar och välja leveranstakt fritt för en del av en produkt, utan att de andra delarna påverkas.

– Det blir en arkitekturfråga. I sämsta fallet har man en monolit, i bästa fallet autonoma moduler, säger Johan Malmberg.