Hva en release på 127 commits egentlig er

Det finnes en versjon av dette blogginnlegget som bare lister opp alt i GeekBye v1.7.0 — en redesignet hjemskjerm, en kalibreringsflyt, et sammenleggbart sidefelt, nye innstillinger, og så videre. Det ville vært korrekt og det ville lært deg ingenting. For den ærlige historien om en release på 127 commits er ikke listen. Det er formen.

Her er formen. Hundre og tjuesju commits høres ut som hundre og tjuesju små ting. Det er det nesten aldri. v1.7.0 var to store funksjoner, bygget parallelt på langlivede brancher over omtrent elleve dager, flettet sammen til slutt. Å forstå en stor release betyr å forstå de to trådene — og det ene stedet vi bygget noe på feil sted og måtte rive det ut igjen underveis.

Tråd én: kalibrering

Den første tråden var kalibrering — en AI-stemmevurdering av kommunikasjonsevnene dine. Du starter en direktesamtale med en AI-"karrierecoach", jobber deg gjennom et strukturert sett med faser (oppvarming, atferd, teknisk kommunikasjon, respons under press, målsetting), og til slutt får du en score på seks dimensjoner: selvtillit, klarhet, presisjon, engasjement, fatning, relevans. Under panseret måler den også konkrete talemålinger — taletempoet ditt, hvor ofte du bruker fyllord, om pausene dine leses som strategiske eller nølende.

Resultatet er ikke en karakter, det er et utgangspunkt. Kalibrering gir deg styrkene dine, vekstområdene dine, og — avgjørende — en anbefalt vanskelighetsgrad å begynne å øve på. Den kalibrerer hvor produktet bør møte deg. Hver ferdighet kommer tilbake som et utvidbart tilbakemeldingskort med et sammendrag, et konkret forslag, og en faktisk sitert setning fra din egen samtale som eksempel. Det er funksjonen resten av øvingsopplevelsen er bygget oppå.

Tråd to: et helt nytt vindu

Den andre tråden var en premium-redesign — og å kalle det en redesign gjør det urett. Det var ikke en omfarging av de eksisterende skjermene; det var i praksis et andre applikasjonsvindu, bygget ut i seks eksplisitte faser: et sammenleggbart sidefelt i Notion-stil, en nedtrekksmeny i toppfeltet som erstattet den gamle øktlisten, nettleserlignende navigasjon med historikk og brødsmuler, og premium-ombygginger av Hjem, Profiler, Møter og Innstillinger.

To store funksjoner. Det var det 127 commits egentlig var. Og den vanskeligste delen av å levere dem var ikke å skrive noen av dem — det var flettingen. De to branchene var gjensidig avhengige; den ene ble merget inn i den andre, og kalibreringsbranchen måtte trekke inn main-branchen fire separate ganger bare for å unngå å drifte ut av synk mens redesignen beveget seg under den. Antallet commits er ikke kostnaden ved en stor release. Langlivede brancher og integrasjonsrekkefølge er det.

Delen som er verdt lesningen: vi bygde kalibrering på feil sted

Her er feilen, og det er en god en fordi den er så vanlig.

GeekBye har en fast arkitektonisk regel: alle AI-operasjoner bor på backend. Klienten er et tynt skall som snakker med en server. Alle visste dette.

Og likevel ble kalibrering først bygget i klientens lokale database. En dedikert tabell, en databasemigrering, et repository på 254 linjer, IPC-handlere, og en bank på 515 linjer med vurderingsspørsmål — alt sammen bosatt på brukerens maskin. Det virket. Det brøt også stille kontrakten hele appen er bygget på.

Tre dager senere slettet én commit 680 linjer på tvers av åtte filer for å flytte det hele til backend, der kalibreringsdataene ble en ordentlig servermodell, og spørsmålslogikken og scoringen ble en serverkonsern. En annen commit slettet spørsmålsbanken på 515 linjer i klienten fullstendig. Diffen er nesten morsom: én innsetting, seks hundre og åtti slettinger.

Ingen satte seg fore å skrive 680 linjer med bruk-og-kast-kode. Det skjedde slik dette alltid skjer: klientsnarveien er rett der, det går raskere å prototype lokalt, og "vi flytter den til backend senere" føles harmløst. Men når arkitekturen din allerede forteller deg hvor kilden til sannhet bor, er det å bygge den et annet sted ikke en snarvei — det er omarbeid du har planlagt for deg selv på forhånd. Lærdommen som festet seg: legg det der kontrakten sier, første gang, selv når den lokale versjonen er raskere å sette opp.

Feilen bare integrasjon kunne finne

Én kvittering til, fordi det er den signaturaktige feilmodusen for store releaser. Da kalibrering og den nye navigasjonen var koblet sammen og faktisk kjørte, begynte appen å utløse en rate limit — HTTP 429 — uten noen åpenbar grunn.

Årsaken var ren integrasjon. Kalibreringsstatus ble hentet på komponentnivå, så hver navigering hentet den på nytt — og Reacts strict mode, som bevisst dobbelt-kaller effekter i utvikling for å avsløre feil, doblet det igjen. Resultatet var fire til åtte identiske kalibreringskall som avfyrte per skjermbytte, nok til å utløse serverens rate limiter. Fiksen konsoliderte hentingen til et par kall ved oppstart.

Du kunne ikke ha funnet denne feilen ved å teste kalibrering alene, eller navigasjonen alene. Den eksisterer bare i skjøten — der to uavhengig korrekte funksjoner møtes. Det er skatten en stor release krever: den siste milen er ikke å bygge funksjonene, det er å oppdage alt som bare knekker når de endelig er i samme rom.

Tre ting en stor release lærte oss

1. En release på 127 commits er to eller tre store temaer, ikke hundre små. Finn trådene. Arbeidet — og risikoen — bor i hvordan de flettes sammen, ikke i antallet.
2. Legg kilden til sannhet der kontrakten sier den bor, første gang. Vi slettet 680 linjer da vi flyttet kalibrering fra klient til backend. Den lokale snarveien er omarbeid du har planlagt på forhånd; arkitekturen fortalte deg allerede svaret.
3. Integrasjon avslører feil isolasjon ikke kan. 429-stormen bodde i skjøten mellom to korrekte funksjoner og dukket bare opp da de kjørte sammen. Sett av tid til en integrasjonsrunde, ikke bare testing per funksjon.

Dette er en v1-fetter av en historie vi ville fortalt igjen i mye større skala — se hva en versjon 2 egentlig krever: 206 commits av ærlige tilstander (v2.0.0), der den samme sannheten om at "et stort tall egentlig er noen få store ideer" spiller seg ut på tvers av hele v2-omskrivingen. For det forrige kapittelet i v1-historien, hvordan streame en live-rapport uten flimmeret (v1.6.13); og for hele buen, anatomien til å levere programvare til perfeksjon.