Hvad en release på 127 commits egentlig er

Der findes en version af dette blogindlæg, der bare lister alt i GeekBye v1.7.0 — en redesignet startskærm, et kalibreringsforløb, en sammenklappelig sidebar, nye indstillinger og så videre. Den ville være korrekt, og den ville ikke lære dig noget. For den ærlige historie om en release på 127 commits er ikke listen. Det er formen.

Her er formen. Ethundrede syvogtyve commits lyder som ethundrede syvogtyve små ting. Det er det næsten aldrig. v1.7.0 var to store funktioner, bygget parallelt på langlivede branches over cirka elleve dage og flettet sammen til sidst. At forstå en stor release betyder at forstå de to tråde — og det ene sted, hvor vi byggede noget det forkerte sted og måtte rive det ud igen midt i flyvningen.

Tråd ét: kalibrering

Den første tråd var kalibrering — en AI-stemmevurdering af dine kommunikationsevner. Du starter et live-opkald med en AI-"karrierecoach", arbejder dig gennem et struktureret sæt af faser (opvarmning, adfærd, teknisk kommunikation, respons under pres, målsætning), og til sidst får du en score på seks dimensioner: selvsikkerhed, klarhed, præcision, engagement, ro og relevans. Under overfladen måler den også konkrete talemålinger — dit taletempo, hyppigheden af fyldord, og om dine pauser fremstår som strategiske eller tøvende.

Resultatet er ikke en karakter, det er et udgangspunkt. Kalibrering producerer dine styrker, dine vækstområder og — afgørende — en anbefalet sværhedsgrad at begynde at øve på. Den kalibrerer, hvor produktet skal møde dig. Hver evne kommer tilbage som et udfoldeligt feedbackkort med et resumé, et konkret forslag og en faktisk citeret linje fra dit eget opkald som eksempel. Det er den funktion, resten af øvelsesoplevelsen er bygget ovenpå.

Tråd to: et helt nyt vindue

Den anden tråd var et premium-redesign — og at kalde det et redesign underdriver det. Det var ikke en ny hud på de eksisterende skærme; det var reelt et andet applikationsvindue, bygget ud i seks eksplicitte faser: en sammenklappelig sidebar i Notion-stil, en header-dropdown, der erstattede den gamle sessionsliste, browser-agtig navigation med historik og brødkrummer, og premium-genopbygninger af Home, Profiles, Meetings og Settings.

To store funktioner. Det var, hvad 127 commits faktisk var. Og den sværeste del ved at skibbe dem var ikke at skrive nogen af dem — det var sammenfletningen. De to branches var indbyrdes afhængige; den ene blev merget ind i den anden, og kalibreringsbranchen måtte hente main-branchen ind fire separate gange bare for at undgå at drive ud af sync, mens redesignet flyttede sig under den. Antallet af commits er ikke omkostningen ved en stor release. Langlivede branches og integrationsrækkefølge er.

Den del, der er læsningen værd: vi byggede kalibrering det forkerte sted

Her er fejlen, og den er en god en, fordi den er så almindelig.

GeekBye har en fast arkitektonisk regel: alle AI-operationer bor på backend. Klienten er en tynd skal, der taler med en server. Alle vidste det.

Og alligevel blev kalibrering først bygget i klientens lokale database. En dedikeret tabel, en databasemigrering, et repository på 254 linjer, IPC-handlere og en bank på 515 linjer af vurderingsspørgsmål — alt sammen boende på brugerens maskine. Det virkede. Det brød også stilfærdigt den kontrakt, hele appen er bygget på.

Tre dage senere slettede én commit 680 linjer på tværs af otte filer for at flytte det hele til backend, hvor kalibreringsdata blev en ordentlig server-side-model, og spørgsmålslogikken og scoringen blev et backend-anliggende. En anden commit slettede spørgsmålsbanken på 515 linjer i klienten helt. Diffen er næsten morsom: én indsættelse, sekshundrede og firs sletninger.

Ingen satte sig for at skrive 680 linjer engangskode. Det skete, som det altid sker: klient-genvejen er lige der, det er hurtigere at prototype lokalt, og "vi flytter det til backend senere" føles harmløst. Men når din arkitektur allerede fortæller dig, hvor kilden til sandhed bor, er det ikke en genvej at bygge det et andet sted — det er omarbejde, du har planlagt for dig selv på forhånd. Læren, der hang ved: læg det, hvor kontrakten siger, første gang, selv når den lokale version er hurtigere at stille op.

Fejlen, som kun integration kunne finde

Endnu en kvittering, for det er den signaturagtige fejltilstand for store releases. Da kalibrering og den nye navigation først var koblet sammen og faktisk kørte, begyndte appen at udløse en rate limit — HTTP 429'ere — uden nogen åbenlys grund.

Årsagen var ren integration. Kalibreringsstatus blev hentet på komponentniveau, så hver navigation hentede den igen — og Reacts strict mode, som med vilje dobbeltkalder effekter i udvikling for at afsløre fejl, fordoblede det igen. Resultatet var fire til otte identiske kalibreringsforespørgsler, der affyredes pr. skærmskift, nok til at udløse serverens rate limiter. Rettelsen samlede fetching til et par kald ved mount.

Du kunne ikke have fundet denne fejl ved at teste kalibrering alene eller navigationen alene. Den eksisterer kun ved sømmen — hvor to uafhængigt korrekte funktioner mødes. Det er den skat, en stor release opkræver: den sidste kilometer er ikke at bygge funktionerne, det er at opdage alt det, der kun går i stykker, når de endelig er i samme rum.

Tre ting en stor release lærte os

1. En release på 127 commits er to eller tre store temaer, ikke hundrede små. Find trådene. Arbejdet — og risikoen — bor i, hvordan de fletter sammen, ikke i antallet.
2. Læg kilden til sandhed, hvor kontrakten siger, den bor, første gang. Vi slettede 680 linjer for at flytte kalibrering fra klient til backend. Den lokale genvej er omarbejde, du har planlagt på forhånd; arkitekturen fortalte dig allerede svaret.
3. Integration afslører fejl, som isolation ikke kan. 429-stormen boede ved sømmen mellem to korrekte funktioner og dukkede kun op, da de kørte sammen. Afsæt tid til en integrationsrunde, ikke kun test pr. funktion.

Dette er en fætter fra v1-æraen til en historie, vi ville fortælle igen i meget større skala — se hvad en version 2 egentlig kræver: 206 commits af ærlige tilstande (v2.0.0), hvor den samme sandhed om at "et stort tal er i virkeligheden nogle få store idéer" udspiller sig på tværs af hele v2-omskrivningen. For det forrige kapitel i v1-historien, sådan streamer du en live-rapport uden flimret (v1.6.13); og for hele buen, anatomien af at skibbe software til perfektion.