Från ax till limpa, hur vi utvecklar och uppdaterar lynes

Jag har förmånen att jobba på ett företag som utvecklar en egen app.

Det är minst lika roligt som det är utmanande. Jag får varje vecka bra (och mindre bra) idéer på ”nästa stora funktion”.

Och tro mig, jag är inte ensam… Men mer om det lite senare.

Jag tänkte nu ta med dig på en resa, en behind the scenes eller om jag får, en behind the lynes, där vi tittar på vad som händer i en utvecklingssprint.

Låt oss lyfta på huven och spana in

• Planering
• Startskottet
• Sprint
• Testperioden
• Release-dagen
• Dagen efter release-dagen-dagen

Vuxna planerar

Varje fredag förs det dialog om vår feature requests & roadmap av ett gäng vuxna personer. Det pratas bland annat om förslag som kommit in, den egna visionen av produkten, och prioriteringar görs.

En av dessa vuxna personer är Johan Åberg (CPO) som innehar tungviktsbältet i det här forumet.

Nu är jag inte vuxen, men jag gissar att han fungerar som en form av vågmästare.

Han slits mellan starka partier (avdelningar) internt så som sälj, leverans, ekonomi och admin (observera att jag medvetet lämnar min avdelning utanför det här).

Utöver dem, har vi såklart de externa rösterna att väga in, så som slutanvändare och partners.

Det har sagts att

En produktchefs roll är att pedagogiskt kunna säga nej även om man själv vill utveckla funktionen nu

Och det känns verkligen som att det stämmer, vi kan inte utveckla allt på en gång – även om vi önskar det.

De här mötena har såklart en output. Funktioner och så vidare tilldelas olika statusar och prioriteras utifrån parametrar som är lika hemliga som Coca Colas recept.

Men precis som Coca Cola kan jag dela med mig av en innehållsförteckning: det består bland annat av: Decided – prio, Decided – no prio och Later.

Startskottet

När väl en ny funktion ska tas fram börjar vi skissa på den och tar en avstämning med intressenter. Initiala skisser är inte pixel-perfect men lägger grunden.

Till slut clearas allt och nästa avstamp blir att planera in den nya funktionen i en release, som kan vara nästa eller den efter det – beroende på projektets storlek och komplexitet.

En eller flera lämpliga utvecklare utses som tillsammans med David (CTO) bidrar med djup teknisk erfarenhet. De diskuterar bland annat

• Skalbarhet
• Säkerhet
• Samt hur vi löser det på bästa sätt

Vid det här laget hade Sickan i Jönssonligan sagt ”Jag har en plan”, presenterat den och gått vidare till ”stöten” i det här fallet sprinten.

Mycket av det arbete som görs gäller nya funktioner, vilket innebär att det behövs ett användargränssnitt (GUI – Graphical User Interface). Alla GUI-komponenter så som input-fält, menyer, knappar, etc, finns upplagda i en så kallad Kitchen sink, som alla utvecklare har tillgång till.

Här kan man få en överblick över vad som redan finns, och vilka parametrar som kan styra komponenterna. Detta är bra för att undvika att nya komponenter utvecklas i onödan, för att inte återuppfinna hjulet.

Dags för sprint

Planen är lagd och nu jädrar börjar det kodas.

Engineering jobbar med dagliga stand-ups och veckovisa all hands-möten där status följs upp på alla parallella projekt de jobbar med i innevarande sprint (en sprint är en release, på ett ungefär).

Det är inte bara ny kod som skrivs, det skapas också automatiska testfall för all ny kod som skrivs. Dessa automatiska tester (så kallade enhetstester) körs automtiskt så snart ny kod checkas in. Det är ett sätt att hindra oväntade sidoeffekter av ny kod. Ofta skrivs enhetstesterna innan själva koden skapas, vilket kallas för testdriven utveckling.

Tiden rullar på och när lagom framsteg gjorts på en ny funktion skapar den ansvariga utvecklaren en så kallad Pull Request. Enkelt uttryckt är en pull request ett önskemål till en annan utvecklare att ta in den nya koden i kodbasen. I praktiken är det en granskning som görs.

Den nya koden granskas, rad för rad, och testkörs av flera olika utvecklare. Det är ofta en iterativ process där resultat blir ett antal kommenterar som behöver åtgärdas innan pull requesten kan godkännas. Förutom att koden ska fungera och göra det som är tänkt, vägs perspektiv såsom prestanda, säkerhet och läsbarhet in i granskningen.

Förutom ren kodgranskning görs också användningstester på utvecklarens lokala utvecklingsmiljö. I detta skede handlar det mest om att få till användarupplevelsen, alltså att känslan ska bli bra och att allt ska hänga ihop med resten av appen. Ofta görs ändringar i designen och olika alternativ utforskas.

När en Pull Request är godkänd läggs den in på Master inför releasen.

Testperiod

Nu börjar det dra ihop sig för releasen och vi går in i testveckan. Efter en formell deadline för ny kod, ett så kallat kod-stopp, uppdateras testmiljön med all ny kod och testperioden börjar.

Det är nu allt nytt ska testas rigoröst för att säkerställa att det fungerar som förväntat samt att det lirar ihop med all annan kod. Nya testbeskrivningar tas fram så att de nya funktionerna kan testas av personer som inte varit direkt involverade i utvecklingen.

Det görs också en stor mängd så kallade regressionstester som testar gamla funktioner för att säkerställa att inga nya funktioner fått det gamla att gå sönder genom någon oväntad sidoeffekt.

Varje ny release innebär tusentals nya rader kod. Men också borttagen och omskriven kod. En viktig del i utvecklingen är att hela tiden förfina och förbättra gammal kod. Att göra den effektivare och mer läsbar.

Det tjänar man på långsiktigt genom färre fel (så kallade buggar) och kortare tid för utveckling av nya funktioner som bygger på den gamla koden. Det är lite som att rensa ogräs och hålla mossan borta i gräsmattan.

All testning görs i vår testmiljö, kallad Lingon. Det är tekniskt sett en kopia av vår Live-miljö och möjliggör testning och experiment utan att det påverkar några kunder.

Alla manuella tester finns beskrivna i vårt testverktyg. Testerna fördelas mellan alla utvecklare (och några inlånade resurser från andra avdelningar). En testbeskrivning innehåller en tydlig beskrivning av testet, nedbrutet i ett antal steg, samt en beskrivning av förväntat resultat.

Till exempel: sätt användare X i statusen Upptagen, skicka in ett samtal i en svarsgrupp. Inget samtal ska ringa ut på användare X.

Testet får ett utfall: Passed eller Failed. Om testet failar skapas en Fix-Task för att åtgärda felet/utfallet.

I releasen 1.20 hade vi ca 1000 regressionstester och hundratals tester för nya funktioner att gå igenom vilket tog ca 2 dagar för hela teamet.

Efter att alla tester är genomförda utförs alla Fix-Tasks och de Failade testerna körs om tills alla tester visar grönt ljus.

Release-dagen

Inför själva uppdateringen görs en risk-analys. Analysen hålls av Platform-teamet som ansvarar för all infrastruktur och drift, men alla utvecklare som bidragit med nya funktioner deltar vanligtvis i genomgången.

När den stora dagen börjar är allt förberett in i minsta detalj. Engineering-teamet har blivit indelat i ett Night crew och ett Morning crew. Morgongänget deltar ej i uppdateringen under kvällen utan håller sig fräscha för att vara på stand-by tidigt på morgonen efter, ifall något oväntat skulle gå snett med uppdateringen.

För kvällsgänget finns det Tasks och körscheman för allt som ska genomföras under själva uppdateringstillfället. Vi lever som vi lär vilket innebär att vissa väljer att vara på kontoret medan andra jobbar hemma.

De som är på kontoret kan ta del av det obligatoriska lösviktsgodiset och uppdaterings-pizzan. För er som undrar är det x antal familjepizzor toppade med: salami, jalapeño och lök.

‍

När klockan börjar närma sig 22:00 ansluter folk till vårt Mission Control Center (en konferens i Lingon) och arbetet startar ”på riktigt”.

Körschemat är helt beroende på vad som ska uppdateras. Utöver uppdatering av diverse mikrotjänster kan det finnas synkar som körs och omvandlar befintlig data till nya format, nya databastabeller som skapas, index genereras, osv.

I normala fall kan allt detta göras helt utan störning. Det är fördelen med en arkitektur baserad på tillståndslösa mikrotjänster.

Det sista som sker är att nya frontend versionen laddas upp och verifieras. När det är klart trycker vi på nästa knapp, i det här fallet frontend-knappen. Den fina knappen är det som faktiskt skjuter ut releasen till alla användare, det är alltså nu du som slutanvändare får den gröna toasten i appen som berättar för dig att det finns en ny version att uppdatera till.

Har allt gått enligt plan brukar kvällen rundas av runt midnatt. Checklistan för uppdateringen innehåller en obligatorisk avslutningspunkt med high fives och ryggdunkningar, ibland virtuella sådana.

Dagen efter release-dagen-dagen

Ofta är det sovmorgon som gäller för kvällsgänget. Dagens första avstämning sker kl 13:00 om inget oförutsett har inträffat. Morgongänget håller ställningarna och jobbar på som vanligt under förmiddagen och vi andra, vi njuter av all ny funktionalitet som nu finns live!

Så där. Nu vet du hur en utvecklingssprint ser ut hos oss!