Visose ankstyvosiose stadijose pradedančiose įmonėse matau tą patį modelį: inžinieriai sukuria meistrus ir kuria filialus, formalius išleidimo ciklus ir scenos aplinką. Tai trečiasis mano serijos straipsnis apie psichinius modelius pradedantiesiems (prašome patikrinti, ten yra daug įdomios medžiagos). Tai paprastai atsitinka, kai produktas tik pradeda veikti. Inžinerinės praktikos kyla iš įpročio, o ne būtinybės ir paprastai iš ankstesnių darbo vietų didesnėse įmonėse, kur gamybos gedimai buvo brangūs ir sunkus procesas buvo teisingas atsakas. The real challenge not stability, it is finding revenue and users Tačiau pradedant verslą, per anksti pradedant šiuos procesus, dėmesys nukreipiamas nuo mokymosi ir link ceremonijos. Šis nesuderinamumas tarp to, ko verslui iš tikrųjų reikia, ir kaip komanda išleidžia kodą, yra ten, kur apačioje pateikiami protiniai modeliai. kiekvienas siūlo skirtingą būdą galvoti apie sprendimus dėl išleidimo, taip pat praktinius patarimus apie tai, kas iš tikrųjų veikia, kai esate iš anksto pajamos ir vis dar ieškote tinkamo. Tai skirta steigėjams ir inžinieriams, kurie jaučia, kad jų procesas juos sulėtina, bet nežino, kodėl. Who is this for? Psichikos modelis 1 arba jūsų išlaisvinimo procesas yra baimės projekcija Išleidimo procesas nėra neutrali infrastruktūra, bet tai yra veidrodis to, ko komanda labiausiai bijo sulaužyti. (regresijos, pertraukos, prarastas pasitikėjimas) jūs statote tvirtoves: scenos aplinką, patvirtinimo vartus, ilgas apžvalgas, paleidimo traukinius. If the deepest fear is breaking production (praleidžiant laiką funkcijose, kurių niekas nenori, trūksta produkto rinkos suderinamumo) sukuriate jutikliai: greitas diegimas, greitas grįžtamasis ryšys, nuolatinis eksperimentavimas. If the deepest fear is building the wrong thing Dauguma komandų niekada nepriima šio pasirinkimo sąmoningai.Jie paveldi darbo srautus iš praeities darbo vietų, kopijuoja „geriausią praktiką“ iš „Big Tech“ tinklaraščių arba pagal nutylėjimą į tai, kas jaučiasi profesionaliai. Kiekviena programinės įrangos kompanija gyvena su dviem baimėmis, kurios niekada visiškai neišnyksta: 
 
 
 Vykdymo rizika: gabenti klaidas, sulaužyti tai, kas veikia, sugadinti gamybą. Atradimo rizika: statyti neteisingą dalyką, prarasti tinkamumą, išeiti iš bėgių. Šios baimės traukia priešingomis kryptimis, o jūsų išleidimo procesas yra mechanizmas, kuris pasirenka tarp jų. Sunkūs procesai, tokie kaip scenos vartai, patvirtinimai ir išleidimo traukiniai, draudžia nuo vykdymo rizikos. Kompromisas yra tikras, bet jis nėra simetriškas. Gamybos klaida yra problema, kurią galite išspręsti per valandą. Teisingas pasirinkimas beveik visada seka įmonės etapą: 
 
 
 Prieš pajamas, prieš PMF: Jūs vis dar įrodyti pagrindinę hipotezę, todėl beveik niekas iš komandos naudoja produktą. Namas vargu ar egzistuoja dar - draudimas nuo ugnies yra per anksti. bijoti nereikšmingumo, o ne nestabilumo. Laivai dažnai, mokytis greičiau nei jūsų konkurentai. Bugs yra gėdingas, bet išgyvenamas. statyti kažką niekas nenori yra mirtinas. Post-PMF, su pajamomis: Tikrieji klientai priklauso nuo jūsų, todėl neveikimo laikas reiškia prarastą pajamas, žalą reputacijai. Dabar vykdymo rizika tampa egzistencinė. Atėjo laikas investuoti į stabilumą: vartus, bandymus, atsiliepimus, stebėjimą. Baimė turėtų vystytis, kaip ir verslas.Procesas, kuris viename etape yra tobulas, kitame tampa aktyviai žalingas. 
 
 
 Prieš svarstydami filialus, vamzdynus ar peržiūrėdami taisykles, sustabdykite ir atsakykite į tris klausimus: 
 
 
 
 Ko iš tikrųjų labiausiai bijo dabar: sulaužyti kažką, kas veikia, ar statyti kažką, kas nesvarbu? Do I have paying customers who depend on reliability, or am I still searching for the first ones? Ar šį procesą formuoja mano dabartinė realybė, ar aš nešioju kažkieno senas baimes? Prieš svarstydami filialus, vamzdynus ar peržiūrėdami taisykles, sustabdykite ir atsakykite į tris klausimus: 
 
 
 
 Ko iš tikrųjų labiausiai bijo dabar: sulaužyti kažką, kas veikia, ar statyti kažką, kas nesvarbu? Ar turiu mokamų klientų, kurie priklauso nuo patikimumo, ar vis dar ieškau pirmųjų? Ar šį procesą formuoja mano dabartinė realybė, ar aš nešioju kažkieno senas baimes? Psichikos modelis 2 - pasiskolintas brandumas Importuojant išsiskyrimo struktūras iš brandžių kompanijų sukuriama pažangos iliuzija, tyliai mažinant mokymosi greitį. Kai produkto rinkos suderinamumas yra neaiškus ir kitas posūkis gali būti rytoj, pažįstamas darbo srautas jaučiasi kaip tvirtas. bet jūsų išleidimo procesas ne tik atspindi, kaip siunčiate kodą. Process is comfort. Conway įstatymas sako, kad programinės įrangos architektūra atspindi organizacinę struktūrą. A company that knows what it's building releases differently than one still figuring it out. Aš žiūrėjau šį modelį iš pirmų rankų. Pradžia prieš pajamas su nulinio mokėjimo vartotojais, kur produktas vis dar buvo hipotezė. Vietoj to, kad išbandytumėte šią hipotezę, pirmasis mėnuo pateko į "tinkamą" infrastruktūrą: plėtoti ir pagrindinius filialus, atskiras scenos ir gamybos aplinkas, CI / CD vamzdynus, Jira ir Jira šablonus. Jis atrodė profesionalus, bet turėjome dvi programinės įrangos aplinkas, kurias palietė nuliniai žmonės už komandos ribų. Išleidimo procesai: tikrovės patikrinimas 
 
 
 
 
 
 
 
 
 
 
 
 Process 
 How It Works 
 Startup Fit (pre-PMF) 
 Why 
 
 
 
 
 
 GitFlow 
 Work happens on a separate develop branch while main stays stable. Features and fixes are merged in batches, with dedicated release and hotfix branches used to control when changes reach production. 
 Poor ❌ 
 Batching delays feedback and hides problems. 
 
 
 
 
 
 GitHub Flow 
 New work is done on short-lived feature branches. Each change goes through a pull request, is reviewed, merged into main, and then deployed continuously. 
 Good ✅ 
 Reviews add latency to learning. 
 
 
 
 
 
 Trunk Based 
 Developers commit small changes directly to main or merge very short-lived branches. Unfinished features are hidden with flags and deployments happen frequently. 
 Good ✅ 
 Fast feedback, break it all faster. 
 
 
 
 
 
 Release Trains 
 Releases happen on a fixed schedule. Features that are ready ship with the next train, while unfinished work waits for the following one. 
 Poor ❌ 
 Calendars slow discovery. GitFlow Darbas vyksta atskiroje plėtros šakoje, o pagrindinės dalys išlieka stabilios. funkcijos ir pataisos sujungiamos į partijas, o specialūs išleidimo ir karštųjų pataisų šakos naudojamos kontroliuoti, kai pokyčiai pasiekia gamybą. Vargšai 🙂 Batching atideda grįžtamąjį ryšį ir slepia problemas. GitHub Flow Naujas darbas atliekamas dėl trumpalaikių funkcijų šakų. Kiekvienas pakeitimas vyksta per traukimo užklausą, peržiūrimas, sujungtas į pagrindinį, o tada diegiamas nepertraukiamai. Geras 🙂 Apžvalgos prideda latentį mokymuisi. Trunk Based Kūrėjai atlieka nedidelius pakeitimus tiesiogiai į pagrindinį arba sujungia labai trumpalaikius filialus. neužbaigtos funkcijos yra paslėptos vėliavomis, o diegimai vyksta dažnai. Geras 🙂 Greitas grįžtamasis ryšys, sulaužykite viską greičiau. Release Trains Išleidimai vyksta pagal nustatytą tvarkaraštį. funkcijos, kurios yra paruoštos laivui su kitu traukiniu, o nebaigtas darbas laukia kito. Vargšai 🙂 Lėtojo atradimo kalendorius. Startuoliai ir brandžios įmonės gyvena skirtinguose pasauliuose – ir kiekvienas pasaulis diktuoja savo išlikimo taisykles. Didelės komandos, lygiagrečiai darbo srautai, didelės gamybos nesėkmių sąnaudos daro „GitFlow“ ir panašius procesus pagrįstu pasirinkimu, sumažinant susijungimo pragarą ir chaosą. Mature companies optimize for coordination risk. Dominuojanti rizika nėra gamybos nutraukimas (jūs vargu ar turite vartotojų). Greitis lemia viską. Startups need to optimize for learning latency. feedback Kopijuojant „GitFlow“ (arba bet kokį sunkų procesą) jūsų buteliukas nukreipiamas nuo atradimo iki ceremonijos. Jūsų konkurentas su netvarkinga Git istorija praėjusią savaitę pristatė tris eksperimentus. 
 
 
 
 
 
 Pasiskolintas brandumas sukuria klaidingą saugumo jausmą. Ilgi ciklai daro pivotus brangius Dideli funkcijų filialai iki vėlavimo slepia integracijos problemas - Apžvalga viršutinė degina kognityvinę energiją geriau išleista vartotojams Procesas iš išorės atrodo rimtas. viduje jis atideda patį mokymąsi, kuris lemia, ar įmonė gyvena, ar miršta. Paskolos mokestis sukuria a . false sense of safety Ilgi ciklai daro pivotus brangius Dideli funkcijų filialai iki vėlavimo slepia integracijos problemas - Apžvalga viršutinė degina kognityvinę energiją geriau išleista vartotojams Procesas iš išorės atrodo rimtas. viduje jis atideda patį mokymąsi, kuris lemia, ar įmonė gyvena, ar miršta. Praktiškai   Vienas apsaugotas šakos su trumpalaikėmis funkcijomis, kurios trunka valandas ar dienas, o ne savaites. Gamyba – ne šakos, jokių išleidimo šakų, jokių karštų pataisymų šakų. Jei trims inžinieriams reikia šakos strategijos diagramos, kažkas jau yra negerai. 1. GitHub Flow is enough. main main develop   Su funkcijų vėliavomis ir tvirtu stebėjimu, gamyba yra vienintelė aplinka, kuri sako tiesą, o scenos aplinkos yra brangios melas, kurias išlaikote jaustis saugiai. 2. Test in production.   Jie leidžia jums atskirti laivybą nuo išleidimo, o tai reiškia, kad galite kasdien diegti kodą ir perjungti funkcijas, kai jos yra paruoštos. 3. Feature flags are non-negotiable. Tokie įrankiai kaip "Vercel", "Netlify", "Render" ir "Railway" sukuria unikalius kiekvienos PR peržiūros URL, todėl suinteresuotieji subjektai akimirksniu mato realius pokyčius be jokios bendros scenos aplinkos, kurią reikia išlaikyti, ir be "dirba mano mašinoje" pasiteisinimų. 4. Preview deployments for every change. Šiame etape vieneto bandymų aprėptis yra pervertinta, nes jums nereikia 80% aprėpties, jums reikia greito sugavimo.Tools kaip GitHub Copilot, Cursor ar specialūs PR peržiūros robotai akivaizdžiai rodo akivaizdžias problemas akimirksniu, o tai yra greitesnė ir pigesnė nei blokuoti komandos draugui. 5. AI-assisted code reviews over waiting for humans. Naudokite "Sentry" klaidoms ir "PostHog" arba "Mixpanel" naudotojo elgesiui, o viskas įspėja tiesiogiai "Slack", kad žinotumėte, kada kažkas sulaužys per sekundes, o ne kai nusivylęs vartotojas el. Laiškus. 6. Observability over exhaustive testing. Nukreipkite klaidų įspėjimus, diegimo pranešimus, analizės įvykius ir atsiliepimus programoje į specializuotus kanalus ir į savo produktą įtraukite paprastą atsiliepimų įtaisą, kad vartotojai taptų jūsų realaus laiko QA komanda. 7. Slack as mission control. **8 Optimizuokite greitą atsigavimą, o ne tobulą prevenciją.** 5 minučių grįžimas į priekį įveikia 2 dienų QA ciklą, todėl dažnai gabenate, atidžiai stebėkite ir iš karto grįžkite, jei kažkas sulaužys. Žemutinė linija Jūsų išleidimo procesas yra lažybų apie tai, kas nužudys jus pirmas. prieš produkto rinkos tinka, pavojus yra statyti neteisingą dalyką, o bėgimo takas susiaurėja. 
 
 
 
 Procesas atspindi baimę.Žinokite, kuri baimė atitinka jūsų etapą. Pasiskolintas brandumas yra brangus. kad "GitFlow" diegimas turėjo prasmę jūsų paskutinėje įmonėje. Optimizuokite, kaip greitai galite pakeisti kryptį, o ne kaip tvirtas pamatas jaučiasi. Mokykis greičiau, mokykis greičiau

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

Read My Stories

Šis garso įrašas sukurtas originalia istorijos kalba!

Jūsų išlaisvinimo procesas yra baimės projekcija

About Author

KOMENTARAI

PABAIGTI ŽYMES

ŠIS STRAIPSNIS BUVO PRISTATYMAS

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps