Att jobba agilt – vad innebär det egentligen?
Vi tänker ofta att agilt arbete handlar om att låta produkten växa fram på ett mer organiskt sätt än tidigare, utveckla små funktioner som testas och utvärderas. Ett arbete som går i cykler, eller iterationer, för att bygga bästa möjliga produkt.

2001 skrevs det Agila manifestet, som var ett försök att ändra processen kring mjukvaruutveckling som den såg ut då, tungrodd och svår att ändra riktning på. Den första principen i det manifestet glöms ofta bort:

Vår högsta prioritet är att tillfredställa kunden genom tidig och kontinuerlig leverans av värdefull programvara.

Kontinuerlig leverans nämndes alltså redan 2001, men det dröjde ganska många år innan begreppet Continuous Delivery började slå igenom. Uppdatering av programvara eller nya funktioner på webbsidor har länge varit något som gjorts en gång i månaden, som involverat både utvecklare och driftavdelning, som möjligen till och med skett på nätterna för att inte störa användare.

Continuous Delivery som vi ser det idag är en helt annan sak; en helt automatiserad process som kan göras när som helst och som sköts av utvecklingsteamet själva.

Den automatiserade processen på Di
I vår automatiserade process har vi valt att använda oss av Github för källkodshantering, TeamCity som byggserver och Octopus Deploy för att hantera deployer ut på webbservrarna. Förenklat ser det ut så här:

  1. Så fort kod pushas till Github startas ett nytt bygge i TeamCity.
  2. TeamCity hämtar ner alla externa beroenden, kompilerar lösningen, kör enhetstester och skapar Nugetpaket som publiceras hos Octopus Deploy.
  3. Octopus plockar ut webbservrarna en i taget ur lastbalanseraren, kopierar ut paketet till servern, kör ytterligare GUI-tester med Casper.js och lägger tillbaka servern i lastbalanseraren igen om allt är OK.

På det här sättet kan vi göra en produktionssättning av ny kod när som helst under dagen. Medan en server uppdateras med ny kod ligger de andra kvar och hanterar inkommande besök. Eftersom detta sker kontinuerligt blir det aldrig några stora revolutionerande ändringar, utan det handlar oftast om små förbättringar och buggfixar.

Det är därför också lätt att hålla reda på vad som gjorts vid varje produktionssättning och om något går fel är det enkelt att hitta problemet. Principen är att aldrig backa en produktionssättning, utan istället fixa det eventuella felet och lägga ut den nya koden.

10 nya versioner varje dag
Vårt arbetssätt med mobbprogrammering, där hela teamet tillsammans arbetar med en funktion åt gången, gör att vi har alla möjligheter att ofta leverera ny kod ut på beta.di.se. Vi arbetar bara i en branch, vi behöver inte gå igenom och godkänna någon annans kod, vi får inte några mergekonflikter.

Vi plockar uppgifter som ska göras i prioritetsordning, gör klart dem och pushar ut koden. Därför kan vi ofta uppdatera våra webbar 10 gånger om dagen.

Tyck till!
Det finns förstås inget bättre sätt att få våra idéer och funktioner testade än att få ut dem till användarna. Och vi vill gärna höra vad ni tycker! Använd ”Tyck till”-knappen på beta.di.se för att ge oss feedback. Gör vi rätt saker?