Jeg har privilegiet å jobbe i et selskap som utvikler sin egen app.
Det er minst like gøy som det er utfordrende. Jeg får hver uke gode (og mindre gode) ideer om «neste store funksjon».
Og tro meg, jeg er ikke alene... Men mer om det litt senere.
Jeg skulle ta deg med på en tur, bak kulissene eller hvis jeg får lov, en bak lynet, hvor vi ser på hva som skjer i en utviklingssprint.
La oss løfte hetten og sjekke inn
- Planlegging
- Startskuddet
- Sprint
- Testperioden
- Utgivelsesdag
- Dagen etter utgivelsesdagen
Voksenplan
Hver fredag er det en dialog om vår funksjonsforespørsler og veikart av en gjeng voksne. Blant annet diskuteres mottatte forslag, egen visjon av produktet og prioriteringer.
En av disse voksne er Johan Åberg (CPO) som holder tungvektbeltet i dette forumet.
Nå er jeg ikke voksen, men jeg gjetter at han fungerer som en form for wavemaster.
Han er revet mellom sterke parter (avdelinger) internt som salg, levering, økonomi og admin (merk at jeg bevisst lar avdelingen min være utenfor dette).
I tillegg til dem har vi selvfølgelig de eksterne stemmene å veie inn, for eksempel sluttbrukere og partnere.
Det har blitt sagt at
Rollen som produktsjef er å kunne si nei pedagogisk selv om du vil utvikle funksjonen selv nå
Og det føles virkelig som om det er sant, vi kan ikke utvikle alt på en gang - selv om vi vil.
Selvfølgelig, disse møtene har et resultat. Funksjoner og så videre tildeles forskjellige statuser og prioriteres basert på parametere som er så hemmelige som Coca Colas oppskrifter.
Men akkurat som Coca Cola kan jeg dele en liste over ingredienser: den består blant annet av: Besluttet — prio, Bestemt — ingen premie og Laat.
Startskuddet
Når en ny funksjon skal utvikles, begynner vi å skissere den og gjøre en forsoning med interessenter. Innledende skisser er ikke pikselperfekte, men legger grunnlaget.
Til slutt blir alt ryddet, og neste trinn er å planlegge den nye funksjonen til en utgivelse, som kan være neste eller den etter det - avhengig av prosjektets størrelse og kompleksitet.
En eller flere egnede utviklere utnevnes som sammen med David (CTO) bidrar med dyp teknisk erfaring. De diskuterer blant annet
- Skalerbarhet
- Sikkerhet
- Og hvordan du løser det på den beste måten
Nå hadde Sickan i Jönssonligan sagt «Jeg har en plan», presentert den og gått videre til «heist» i dette tilfellet sprinten.
Mye av arbeidet som gjøres gjelder nye funksjoner, noe som betyr at en GUI (Graphical User Interface) er nødvendig. Alle GUI-komponenter som inndatafelt, menyer, knapper, etc., lagres i en såkalt kjøkkenvask, som alle utviklere har tilgang til.
Her kan du få oversikt over hva som allerede eksisterer, og hvilke parametere som kan styre komponentene. Dette er bra for å unngå unødvendig utvikling av nye komponenter, for ikke å gjenoppfinne hjulet.
Tid for sprint
Planen er lagt, og nå begynner den å bli kodet.
Engineering jobber med daglige stand-ups og ukentlige all-hands møter der statusen spores på alle parallelle prosjekter de jobber med i dagens sprint (en sprint er en release, på omtrentlig basis).
Det er ikke bare ny kode som skrives, det lager også automatiske testtilfeller for all ny kode som er skrevet. Disse automatiske testene (kjent som enhetstester) kjøres automatisk så snart ny kode er sjekket inn. Det er en måte å forhindre uventede bivirkninger av ny kode. Ofte skrives enhetstester før selve koden opprettes, som er kjent som testdrevet utvikling.
Tiden går videre, og når det er gjort nok fremgang på en ny funksjon, oppretter den ansvarlige utvikleren en såkalt Pull-Request. Enkelt sagt, en pull-forespørsel er en forespørsel til en annen utvikler om å bringe den nye koden inn i kodebasen. I praksis er det en revisjon som gjøres.
Den nye koden blir gjennomgått, linje for linje, og testkjørt av flere forskjellige utviklere. Det er ofte en iterativ prosess der resultatene blir en rekke kommentarer som må tas opp før pull-forespørselen kan godkjennes. I tillegg til å få koden til å fungere og gjøre det som er ment, blir perspektiver som ytelse, sikkerhet og lesbarhet veid inn i revisjonen.
I tillegg til ren kodegjennomgang blir det også gjort brukstester på utviklerens lokale utviklingsmiljø. På dette stadiet handler det mest om å få brukeropplevelsen, det vil si at følelsen skal være god og at alt skal være koblet til resten av appen. Ofte gjøres endringer i designet og ulike alternativer blir utforsket.
Når en Pull-forespørsel er godkjent, sendes den til masteren før utgivelsen.
Prøveperiode
Nå begynner det å trekke seg sammen for utgivelsen, og vi går inn i testuka. Etter en formell frist for ny kode, et såkalt kodestopp, oppdateres testmiljøet med all ny kode og testperioden begynner.
Det er nå helt nytt som skal testes grundig for å sikre at det fungerer som forventet og at det smelter sammen med all annen kode. Nye testbeskrivelser er utviklet slik at de nye funksjonene kan testes av personer som ikke har vært direkte involvert i utviklingen.
Det finnes også et stort antall såkalte regresjonstester som tester gamle funksjoner for å sikre at ingen nye funksjoner har fått den gamle til å bryte gjennom noen uventet bivirkning.
Hver nye utgivelse innebærer tusenvis av nye kodelinjer. Men også slettet og omskrevet kode. En viktig del av utviklingen er å stadig foredle og forbedre gammel kode. Gjør det mer effektivt og mer lesbart.
Dette oppnås på lang sikt ved færre bugs (såkalte bugs) og kortere tid for å utvikle nye funksjoner basert på den gamle koden. Det er litt som å luke og holde mosen borte i plenen.
All testing gjøres i vårt testmiljø, kalt Lingon. Det er teknisk sett en kopi av Live-miljøet vårt og gir mulighet for testing og eksperimentering uten å påvirke noen kunder.
Alle manuelle tester er beskrevet i vårt testverktøy. Testene er fordelt på alle utviklere (og noen lånte ressurser fra andre avdelinger). En testbeskrivelse inneholder en klar beskrivelse av testen, fordelt på en rekke trinn, samt en beskrivelse av forventet resultat.
For eksempel: sett bruker X i statusen Opptatt, send et anrop til en svargruppe. Ingen anrop skal ringe ut på bruker X.
Testen har et resultat: Bestått eller mislyktes. Hvis testen mislykkes, opprettes en Fix-Task for å fikse feilen/resultatet.
I 1.20-utgivelsen hadde vi omtrent 1000 regresjonstester og hundrevis av tester for nye funksjoner å gå gjennom, noe som tok omtrent 2 dager for hele teamet.
Etter at alle tester er fullført, blir alle Fix-Tasks utført og de mislykkede testene kjøres igjen til alle tester viser grønt lys.
Utgivelsesdag
Før selve oppdateringen utføres en risikoanalyse. Analysen holdes av plattformteamet som er ansvarlig for all infrastruktur og drift, men alle utviklere som bidro med nye funksjoner deltar vanligvis i orienteringen.
Når den store dagen begynner, er alt forberedt ned til minste detalj. Ingeniørteamet er delt inn i en Nattmannskap og en Morgenmannskap. Morgengjengen deltar ikke i oppdateringen i løpet av kvelden, men holder seg frisk til å være i beredskap tidlig på morgenen etter, i tilfelle noe uventet skulle gå galt med oppdateringen.
For kveldsgjengen er det Oppgaver og løpeplaner for alt som skal fullføres i løpet av den faktiske oppdateringstiden. Vi lever som vi lærer, noe som betyr at noen velger å være på kontoret mens andre jobber hjemme.
De på kontoret kan ta del i det obligatoriske godteriet og forfriskningspizzaen med løs vekt. For de av dere som lurer på, er det x antall familiepizzaer toppet med: salami, jalapeño og løk.
Når klokken begynner å nærme seg 22:00, kobler folk seg til vårt Mission Control Center (en konferanse i Lingon) og arbeidet starter «på ordentlig».
Løpeplanen er helt avhengig av hva som må oppdateres. I tillegg til å oppdatere ulike mikrotjenester, kan det være synkroniseringer som kjører og konverterer eksisterende data til nye formater, nye databasetabeller opprettet, indekser generert osv.
I normale tilfeller kan alt dette gjøres helt uten forstyrrelser. Det er fordelen med en arkitektur basert på statsløse mikrotjenester.
Det siste som skjer er at den nye frontend-versjonen lastes opp og verifiseres. Når du er ferdig, trykker vi på neste knapp, i dette tilfellet frontend-knappen. Den fine knappen er det som faktisk skyver utgivelsen til alle brukere, så nå får du som sluttbruker det grønne Ristet brød i appen som forteller deg at det er en ny versjon å oppdatere til.
Hvis alt går etter planen, slutter kvelden vanligvis rundt midnatt. Oppdateringssjekklisten inkluderer et obligatorisk utgangspunkt med high fives og back dunks, noen ganger virtuelle.
Dagen etter utgivelsesdagen
Ofte er det sengetid som gjelder kveldsgjengen. Dagens første forsoning vil finne sted klokken 13.00 hvis ingenting uforutsett har skjedd. Morgengjengen holder tribunen og jobber som vanlig om morgenen og resten av oss nyter vi all den nye funksjonaliteten som nå er live!
Så der. Nå vet du hvordan en utviklingssprint ser ut hos oss!
