Tankar som continuous har funnits med inom mjukvaruutveckling tidigare men har först på senare år blivit en egen disciplin, fått betydligt bättre verktygsstöd och används av allt fler, men fortfarande är det nytt för väldigt många. Det är ett modernt och flexibelt arbetssätt som möjliggör snabba leveranser till kund, något som det hela tiden ställs allt högre krav på. I continuousvärlden finns det dock en hel del begrepp och metoder att hålla koll på, i det här blogginlägget tittar vi närmare på Continuous Integration (CI) och Continuous Delivery (CD) och hur dessa fungerar.
I continuousvärlden jobbar man precis som det låter kontinuerligt, här jobbar man inte i projekt eller efter hårda start- och sluttider. Ständiga förändringar och förbättringar görs hela tiden, små delar i taget. Idag är kraven på en snabb time to market som sagt höga och det går inte längre att blunda för att de företag som snabbast kan leverera nytta till sina kunder är de som kommer överleva i dagens hårda konkurrens. Men för att lyckas med detta krävs det snabba metoder som möjliggör ett flexibelt arbete, som i sin tur tillåter ständiga förändringar vid behov. Två vanliga metoder som används inom continuous är Continuous Integration och Continuous Delivery.
Continuous Integration
Inom traditionell utveckling jobbar man ofta mot flera olika grenar eller så kallade brancher, där olika projekt eller delar har sin egen branch. Till sist läggs flera brancher ihop till den slutliga produkten. Inom Continuous Integration jobbar man istället hela tiden mot en så kallad master branch. Huvudsyftet är att det ska gå så fort som möjligt att få ut koden i produktion, vilket kräver att koden alltid ska vara så bra att den direkt ska kunna skjutas ut i produktion.
Kvalitetsarbetet börjar ofta i ett tidigt skede med design av modellbaserade tester baserat på tillståndskartor och sedan mer aktivt när koden genomgår automatiserade tester på en lokal maskin. Innan man får lägga till ny kod i master branchen körs byggtester, som talar om ifall koden är tillräckligt bra för att läggas till eller inte. Om koden inte klarar testerna får man fixa eventuella fel och försöka igen.
Normalt ingår även ett kodgranskningssteg där någon annan tittar på koden, kollar att den kompilerar som förväntat och att eventuella enhetstest fungerar. Huvuddelen av de efterföljande testerna automatiseras också. Den del av testningen som sker manuellt är normalt riskbaserad och i form av utforskande test. Att arbeta på det här viset ger en snabb och tidig indikation på om något i koden behöver göras om.
Continuous Delivery
Medan Continuous Integration kan ses som steget där paketet slås in, där koden skapas och går igenom initiala tester som hjälper till att avgöra om den är tillräckligt bra eller inte, så kan Continuous Delivery istället ses som själva leveransen av paketet. Det finns ett antal olika sätt att produktionssätta koden för att minimera effekterna av eventuella fel. De flesta går ut på att en begränsad delmängd av användarna får tillgång till den nya koden och sedan öppnar man för fler vartefter. En stor del av framgången här består i bra monitorering och färdiga scenarion för roll-back eller roll-forward.
Sammanfattning
Idag går det mesta i rasande fart, vilket förstås ställer höga krav på företag att hänga med i utvecklingen. Men för att lyckas med kontinuerliga leveranser i ett högt tempo, krävs snabba, flexibla metoder. Continuous Integration och Continuous Delivery är två exempel på vanliga metoder som används flitigt i continuousvärlden.
