Steven
Steven6 min de lectura

Què és realment una release de 127 commits

GeekBye v1.7.0 van ser 127 commits en onze dies. Des de fora, això sembla un centenar de coses petites. Des de dins van ser dues grans funcionalitats entrellaçades al final — i una d'elles es va construir al lloc equivocat, i després es va arrencar i reconstruir a mitja release. Aquesta és l'anatomia d'una gran release.

Engineering
Release
Arquitectura
GeekBye Releases
Què és realment una release de 127 commits

Hi ha una versió d'aquesta entrada de blog que simplement enumera tot el que hi ha a GeekBye v1.7.0 — una pantalla d'inici redissenyada, un flux de calibratge, una barra lateral plegable, noves opcions de configuració, i així contínuament. Seria exacta i no t'ensenyaria res. Perquè la història honesta d'una release de 127 commits no és la llista. És la forma.

Aquesta és la forma. Cent vint-i-set commits sonen com cent vint-i-set coses petites. Gairebé mai ho és. v1.7.0 van ser dues grans funcionalitats, construïdes en paral·lel en branques de llarga durada durant uns onze dies, entrellaçades al final. Entendre una gran release significa entendre aquests dos fils — i l'únic lloc on vam construir alguna cosa al punt equivocat i la vam haver d'arrencar de nou a mitja volada.

Fil un: calibratge

El primer fil va ser el calibratge — una avaluació de veu amb IA de les teves habilitats de comunicació. Comences una trucada en directe amb un "coach de carrera" d'IA, treballes a través d'un conjunt estructurat de fases (escalfament, comportamental, comunicació tècnica, resposta sota pressió, definició d'objectius), i al final obtens una puntuació en sis dimensions: confiança, claredat, especificitat, implicació, compostura, rellevància. Per sota, també mesura mètriques de parla concretes — el teu ritme de parla, la freqüència de mots crossa, si les teves pauses es llegeixen com a estratègiques o dubitatives.

El resultat no és una nota, és un punt de partida. El calibratge produeix els teus punts forts, les teves àrees de creixement i — de manera crucial — una dificultat recomanada amb què començar a practicar. Calibra on hauria de trobar-te el producte. Cada habilitat torna com una targeta de retroalimentació desplegable amb un resum, un suggeriment concret i una frase realment citada de la teva pròpia trucada com a exemple. És la funcionalitat sobre la qual es construeix la resta de l'experiència de pràctica.

Fil dos: una finestra completament nova

El segon fil va ser un redisseny premium — i anomenar-lo redisseny el menysvalora. No era un canvi d'aparença de les pantalles existents; era efectivament una segona finestra d'aplicació, desenvolupada en sis fases explícites: una barra lateral plegable a l'estil Notion, un desplegable de capçalera que substituïa l'antiga llista de sessions, navegació a l'estil navegador amb historial i molles de pa, i reconstruccions premium d'Inici, Perfils, Reunions i Configuració.

Dues grans funcionalitats. Això és el que van ser realment 127 commits. I la part més difícil de publicar-les no va ser escriure'n cap de les dues — va ser l'entrellaçat. Les dues branques eren interdependents; una es va fusionar dins de l'altra, i la branca de calibratge va haver d'incorporar la branca main quatre vegades separades només per no desincronitzar-se mentre el redisseny es movia per sota seu. El nombre de commits no és el cost d'una gran release. Les branques de llarga durada i l'ordre d'integració sí.

La part que val la pena llegir: vam construir el calibratge al lloc equivocat

Aquí està l'error, i és un de bo perquè és molt comú.

GeekBye té una regla arquitectònica ferma: totes les operacions d'IA viuen al backend. El client és una closca prima que parla amb un servidor. Tothom ho sabia.

I tot i així, el calibratge es va construir primer a la base de dades local del client. Una taula dedicada, una migració de base de dades, un repositori de 254 línies, gestors IPC, i un banc de 515 línies de preguntes d'avaluació — tot vivint a la màquina de l'usuari. Funcionava. També violava silenciosament el contracte sobre el qual està construïda tota l'aplicació.

Tres dies després, un sol commit va eliminar 680 línies a través de vuit fitxers per traslladar-ho tot al backend, on les dades de calibratge es van convertir en un model del costat del servidor com cal, i la lògica de preguntes i la puntuació van passar a ser una qüestió del servidor. Un altre commit va eliminar de soca-rel el banc de preguntes de 515 línies del client. El diff és gairebé graciós: una inserció, sis-centes vuitanta supressions.

Ningú no es va proposar escriure 680 línies de codi d'un sol ús. Va passar de la manera que això sempre passa: la drecera del client està just aquí, és més ràpid prototipar en local, i "ja ho traslladarem al backend més endavant" sembla inofensiu. Però quan la teva arquitectura ja et diu on viu la font de veritat, construir-ho a qualsevol altre lloc no és una drecera — és refer feina que ja t'has programat a tu mateix. La lliçó que va quedar: posa-ho on diu el contracte, la primera vegada, fins i tot quan la versió local sigui més ràpida de muntar.

L'error que només la integració podia trobar

Un rebut més, perquè és el mode de fallada característic de les grans releases. Un cop el calibratge i la nova navegació es van connectar i van començar a funcionar de debò, l'aplicació va començar a activar un límit de peticions — HTTP 429 — sense cap raó òbvia.

La causa era pura integració. L'estat de calibratge s'obtenia a nivell de component, així que cada navegació el tornava a obtenir — i el strict mode de React, que deliberadament invoca dues vegades els efectes en desenvolupament per fer aflorar errors, ho va duplicar de nou. El resultat van ser de quatre a vuit peticions de calibratge idèntiques disparant-se per cada canvi de pantalla, prou per activar el limitador de peticions del servidor. La solució va consolidar l'obtenció a un parell de crides en muntar-se.

No hauries pogut trobar aquest error provant el calibratge sol, ni la navegació sola. Només existeix a la juntura — on es troben dues funcionalitats correctes de manera independent. Aquest és l'impost que cobra una gran release: l'última milla no és construir les funcionalitats, és descobrir tot el que només es trenca quan finalment són a la mateixa habitació.

Tres coses que ens va ensenyar una gran release

  1. Una release de 127 commits són dos o tres grans temes, no un centenar de petits. Troba els fils. La feina — i el risc — viu en com s'entrellacen, no en el recompte.
  2. Posa la font de veritat on diu el contracte que viu, la primera vegada. Vam eliminar 680 línies traslladant el calibratge del client al backend. La drecera local és refer feina que has programat per endavant; l'arquitectura ja et va donar la resposta.
  3. La integració fa aflorar fallades que l'aïllament no pot. La tempesta de 429 vivia a la juntura entre dues funcionalitats correctes i només va aparèixer un cop van funcionar juntes. Pressuposta una passada d'integració, no només proves per funcionalitat.

Aquest és un cosí de l'era v1 d'una història que tornaríem a explicar a una escala molt més gran — vegeu què cal realment per a una versió 2: 206 commits d'estats honestos (v2.0.0), on la mateixa veritat de "un gran nombre és realment unes quantes grans idees" es desplega per tota la reescriptura de la v2. Per al capítol anterior de la història de la v1, com transmetre un informe en directe sense el parpelleig (v1.6.13); i per a tot l'arc, l'anatomia de publicar programari fins a la perfecció.

Articles Relacionats

Quatre releases en vint-i-sis hores: canonades d'idioma i una bridge release
Steven
Steven7 min de lectura

Quatre releases en vint-i-sis hores: canonades d'idioma i una bridge release

GeekBye de la v1.7.6 a la v1.8.1: un ajust d'idioma que mai no havia sortit del portàtil, un overlay Cmd+/ que mostra les teves keybindings reals, una versió amb zero canvis de codi — i el problema de l'ou i la gallina de migrar el teu feed d'auto-update.

Engineering
Release
Desktop
Una base de codi, dues apps: com fer white-label sense fork
Steven
Steven6 min de lectura

Una base de codi, dues apps: com fer white-label sense fork

GeekBye i Pavleur són dues apps d'escriptori amb marques diferents construïdes des d'un únic repositori — sense fork, sense base de codi duplicada. Aquesta és la maquinària de build que fa que una sola base de codi compili en dos productes, i l'error d'una sola línia que va fer que la nostra segona app es presentés amb el nom equivocat.

Engineering
Arquitectura
Build
El silenci era portant
Steven
Steven8 min de lectura

El silenci era portant

Les dues últimes releases de GeekBye v1 tracten de la mateixa veritat incòmoda: la transcripció en temps real sobre una xarxa real no és sense pèrdues, i el moviment honest és deixar de fer veure que ho és. v1.8.20 va guardar una còpia de cada chunk d'àudio al disc abans de descartar-lo durant una reconnexió, i va començar a marcar en veu alta els buits de la transcripció. v1.9.0 va deixar d'enviar silenci per estalviar amplada de banda — i va descobrir que el silenci era exactament el senyal que el transcriptor feia servir per saber que una frase havia acabat. Dues releases sobre el cost de llençar coses.

Engineering
Audio
Fiabilitat