Kontinuerlig leverans, continuous delivery, är det kanske hetaste begreppet inom systemutveckling i dag. Det handlar om en drivkraft att automatisera alla repetitiva arbetsuppgifter som kan automatiseras i utvecklingsprocessen, allt från att den första källkoden skrivs, till att applikationer och tjänster tas i drift.

Det här kan göras på olika sätt, med stöd av olika verktyg. Exempel på arbetsuppsgifter som ingår, i en ungefärlig följd, är att koda, kompilera, bygga ihop hela applikationer och tjänster, distribuera (deploya) till först testmiljö och sedan produktionsmiljö, för att till sista köra skarp drift. Och tester, en himla massa olika tester.

Mer om testerna snart, men först några ord om varför många satsar på att jobba med kontinuerliga leveranser. Det finns flera uppenbara skäl, varav de främsta kan sammanfattas med två ord: Snabbare och oftare.

Läs också: Målet för noops-trenden: att göra alla drifttekniker arbetslösa

Automatisering av de enskilda arbetsuppgifterna ger i sig snabbare projekt, men den främsta vinsten är kanske att en hel process skapas som är automatiserad i hög grad. Tanken är att öka produktiviteten och träffsäkerheten för utvecklingsprojekten, helt enkelt att leverera samma sak till längre kostnad eller leverera mer till samma kostnad.

De enskilda uppgifterna under ett projekt kopplas samman i en kedja som ofta kallas för pipeline. Med hjälp av verktygsstöd är tanken att allt ska flyta på av sig själv när programmerare lämnar i från sig sin kod. Slutresultatet ska bli kortare tid från utvecklingsstart till drift, och mer frekventa driftstarter. Och det här gäller inte enbart för stora projekt med stora team:

Daniel Marell, arkitekt på konsultföretaget C.A.G
Daniel Marell, arkitekt på konsultföretaget C.A.G

– Det finns goda skäl att skapa en sån här pipeline med automatiska tester även i projekt med bara en utvecklare. Det handlar om repeterbarhet och kvalitet. Man vill kunna lita på att en applikations befintliga funktionalitet förblir intakt även när systemet förändras och nya funktioner läggs till, säger Daniel Marell, arkitekt på konsultföretaget C.A.G.

Tester är en nyckelaktivitet för att lyckas med den automatisering som är själva vitsen med kontinuerliga leveranser. Och det finns flera olika typer av tester att hantera. Ett antagande är att den enskilda utvecklare, eller i alla fall utvecklingsteamen, ansvarar för enhetstester, alltså att testa att de minsta beståndsdelarna i en applikation, till exempel klasser. Enheterna testas i isolation och det handlar inte om att uppfylla kravspecifikationer, utan om att uppfylla programmerarens egna intentioner med enheterna.

När man jobbar med kontinuerlig leveranser ska enhetstesterna normalt vara gjorda innan utvecklaren skickar i väg sin kod in i den pipeline som finns.

En annan typ av tester som inte automatiseras i en pipeline är de som måste vara manuella, till exempel utforskande tester. Sådana används för att skaffa sig kunskap om och underlag för automatiserade tester och de ingår normalt inte i en pipeline. Det kan till exempel handla om aspekter för användargränssnitt, som layout, färgval och formuleringar.

Även om manuella tester inte ingår i en pipeline bör man planera för dem i utvecklingsprocessen.

– I början när man introducerar en pipeline har vi upptäckt att man ofta vill ha ett manuellt teststeg, men efter ett tag frikopplar man det sedan man upptäckt att det sällan tillför något i den dagliga produktionen. I stället körs manuella tester utanför pipelinen som en del av utvecklingsarbetet, säger Daniel Marell.

Nu återstår ett antal tester som kan automatiseras. Var i processen, eller i pipelinen, de stoppas in kan variera, liksom vilka verktyg som används för att automatisera dem. Ett exempel på sådana tester är ickefunktionella, till exempel av prestanda och skalbarhet. Ett annat exempel är integrationstester, vilket kan betyda olika saker på olika företag. Ibland är integrationstest en benämning på att testa just integrationslösningar. Men för det mesta syftar begreppet på att testa alla enskilda delar i en applikation eller tjänst tillsammans. Kort sagt, ”köra hela applikationen”.

– Att automatisera tester är absolut en nyckelfaktor för att lyckas med kontinuerlig leverans, säger Daniel Marell.

Läs också: Med crowdtesting kan utvecklare finslipa sina appar med hjälp av studenter

Den mest speciella hanteringen av tester vid kontinuerlig leverans, jämfört med traditionella vattenfallsprojekt, är funktionella tester, alltså tester av att en applikation uppfyller en kravspecifikation. Allra mest speciella är acceptanstester. Traditionellt har det begreppet ofta syftat på en sista chans för kunden, eller beställaren, att godkänna den applikation som byggs. Men när kontinuerlig leverans blir ett sådant förfarande meningslöst.

Det är ingen vits med att automatisera hela kedjan för systemutveckling och leverans om den ska stoppas upp av att kunden ska godkänna en applikation innan driftsstart. Även acceptanstester måste automatiseras.

– Man kanske kör acceptanstester sju gånger om dagen för en applikation. Lösningen blir att kunden och slutanvändarna deltar i utformningen av de automatiska acceptanstesterna, säger Daniel Marell.

Chansen för kunden att påverka hur applikationer som ska tas i drift fungerar är att engagera sig under projekten. Det finns inga sista chans att sätta stopp i en automatiserad process. Utvecklarteamet och projektledaren har naturligtvis också ett ansvar att ge kunden en chans att engagera sig.

Fakta

Det finns gott om verktyg och tjänster som underlättar arbetet med kontinuerliga leveranser. Här är några exempel:

  • Github. En webbaserad tjänst för att lagra programkod. Utvecklarna i ett team kan skicka kod som de är klara med till den. Sedan kan andra verktyg hämta koden.
  • Jenkins. Ett verktyg för att knyta ihop hela utvecklingsprocessen, genom att styra andra verktyg, och även för att genomföra enskilda moment, till exempel att bygga ihop applikationer.
  • Thoughtworks Go. Ett alternativ till Jenkins.
  • Maven. Ett verktyg för att automatisera byggen, inklusive hantering av tester. Kan styras av till exempel Jenkins.