У свим почетним стартапима, стално видим исти образац: инжењери постављају мајсторе и развијају гране, формалне циклусе ослобађања и постављају окружења. Ово је трећи чланак у мојој серији о менталним моделима за стартапе (молимо вас да га проверите, ту је пуно занимљивог материјала). То се обично дешава када је производ тек почео. Инжењерске праксе долазе из навике, а не од потребе и обично из претходних радних места у већим компанијама где су неуспјеси у производњи били скупи и тежак процес био је прави одговор. The real challenge not stability, it is finding revenue and users Али у стартупу, увођење тих процеса прерано повлачи фокус од учења и ка церемонији. Овај неусклађеност између онога што посао заиста треба и како тим ослобађа код је где ментални модели испод долазе.Сваки нуди другачији начин размишљања о одлукама о ослобађању, заједно са практичним саветима о томе шта заиста ради када сте пре-приход и још увек тражите одговарајуће. Ово је за осниваче и инжењере који осећају да их њихов процес успорава, али нису сигурни зашто. Who is this for? Mentalni model 1 ili vaš proces oslobađanja je projekcija straha Процес ослобађања није неутрална инфраструктура, али је огледало онога што се тим највише плаши да прекине. (регресије, прекиди, изгубљено поверење) градите тврђаве: окружења за постављање, капије за одобрење, дугачке рецензије, возови за ослобађање. If the deepest fear is breaking production (пропуштање времена на функције које нико не жели, недостатак прилагођавања производу тржишту) градите сензоре: брзе распореде, брзе повратне информације, стално експериментисање. If the deepest fear is building the wrong thing Većina timova nikada ne donosi ovaj izbor svesno. Oni nasleđuju tokove posla iz prošlih poslova, kopiraju „najbolje prakse“ iz Big Tech blogova, ili podrazumevaju sve što se oseća profesionalno. Rezultat je proces oblikovan nečijom realnošću i gotovo uvek realnošću zrele kompanije sa plaćanjem klijenata, potrebama usaglašenosti i ozbiljnim posledicama za prekid rada. Svaka softverska kompanija živi sa dva straha koja nikada u potpunosti ne nestaju: 
 
 
 Ризик од извршења: испорука грешака, разбијање онога што функционише, оштећење производње. Ризик откривања: изградња погрешне ствари, недостатак фиксације, трчање из стазе. Ови страхови повлаче у супротним правцима, а ваш процес ослобађања је механизам који бира између њих. Тешки процеси као што су капије за постављање, одобрења и возови за ослобађање осигуравају од ризика од извршења. Компромис је стваран, али није симетричан. грешка у производњи је проблем који можете поправити за сат времена. Изградња погрешног производа за шест месеци је проблем од којег се не можете опоравити. Pravi izbor gotovo uvek sledi fazu kompanije: 
 
 
 Пре-приход, пре-ПМФ: Још увек доказујете основну хипотезу, тако да готово нико изван тима не користи производ. Кућа једва постоји још – осигурање од пожара је прерано. Страх од ирелевантности, а не нестабилности. Често бродови, уче брже од ваших конкурената. Бугови су срамни, али преживљавају. Изградња нешто што нико не жели је фатална. Пост-ПМФ, са приходом: Реални клијенти зависе од вас, тако да време застоја значи изгубљени приход, штету репутацији. Сада ризик извршења постаје егзистенцијалан. Време је да се инвестира у стабилност: капије, тестирање, повратак, посматрање. Strah bi trebalo da se razvija kao i poslovanje.Proces koji je savršen u jednoj fazi postaje aktivno štetan u drugoj. 
 
 
 Пре него што расправљате о гранама, гасоводима или прегледате правила, зауставите се и одговорите на три питања: 
 
 
 
 Šta se trenutno najviše plašim: da razbijem nešto što funkcioniše ili da izgradim nešto što nije važno? Да ли плаћам купце који зависе од поузданости, или још увек тражим прве? Is this process shaped by my current reality, or am I carrying forward someone else's old fears? Пре него што расправљате о гранама, гасоводима или прегледате правила, зауставите се и одговорите на три питања: 
 
 
 
 Šta se trenutno najviše plašim: da razbijem nešto što funkcioniše ili da izgradim nešto što nije važno? Да ли плаћам купце који зависе од поузданости, или још увек тражим прве? Да ли је овај процес обликован мојом тренутном стварношћу, или преносим нечије старе страхове? Mentalni model 2 - pozajmljena zrelost Увозити структуре ослобађања од зрелих компанија ствара илузију напретка док тихо смањује брзину учења. Kada je usklađenost proizvoda sa tržištem neizvesna i sledeći pivot bi mogao biti sutra, poznati tok posla se oseća kao čvrsta zemlja.Ali vaš proces objavljivanja ne odražava samo kako isporučujete kod. Process is comfort. Конвејев закон нам говори да софтверска архитектура одражава организациону структуру. A company that knows what it's building releases differently than one still figuring it out. Гледао сам овај образац из прве руке. Покретање пре прихода са нултим корисницима који плаћају, где је производ још увек био хипотеза. Уместо тестирања те хипотезе, први месец је отишао у "правилну" инфраструктуру: развој и главне гране, одвојена стажирање и прод окружења, ЦИ / ЦД цевоводи, Јира и Јира шаблони. Изгледало је професионално, али имали смо два окружења за софтвер који су додирнули људи изван тима. Процеси ослобађања: провера реалности 
 
 
 
 
 
 
 
 
 
 
 
 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 Рад се одвија на одвојеној развојној граници док главне границе остају стабилне.Функције и поправке се спајају у сетовима, са посвећеним ослобађањем и брзим поправкама које се користе за контролу када промене дођу до производње. сиромашни Бацкинг одлаже повратне информације и скрива проблеме. GitHub Flow Нови рад се врши на краткотрајним гранама функција. Свака промена пролази кроз захтев за повлачење, прегледа се, спаја у главни, а затим се континуирано располаже. Добро Прегледи додају латенцију учењу. Trunk Based Програмери праве мале промене директно на главне или спајају врло краткотрајне гране.Незавршене функције су скривене са заставама и често се депоновања дешавају. Добро Брзо повратне информације, разбијте све брже. Release Trains Карактеристике које су спремне за брод са следећим возом, док недовршени рад чека следећи. сиромашни Календари споро откривање. Startupe i zrele kompanije žive u različitim svetovima – i svaki svet diktira svoja pravila preživljavanja. Велики тимови, паралелни токови рада, високи трошкови неуспјеха производње чине ГитФлов и сличне процесе разумним избором, минимизирајући спајање пакла и хаоса. Mature companies optimize for coordination risk. Доминантни ризик није прекидање производње (једва имате кориснике). Брзина одређује све. Startups need to optimize for learning latency. feedback Копирање ГитФлоу-а (или било ког тешког процеса) пребацује вашу бочицу са открића на церемонију. Ваш конкурент са хаотичном историјом Гит-а прошле недеље је испоручио три експеримента. 
 
 
 
 
 
 Pozajmljena zrelost stvara lažni osećaj sigurnosti. - Дуги циклуси чине пивоте скупим - Велике гране карактеристика сакривају проблеме интеграције до касно - Преглед оверхеад гори когнитивну енергију боље потрошену на кориснике Процес изгледа озбиљно споља.Унутра, одлаже само учење које одређује да ли компанија живи или умире. Pozajmljena zrelost stvara lažni osećaj sigurnosti. - Дуги циклуси чине пивоте скупим - Велике гране карактеристика сакривају проблеме интеграције до касно - Преглед оверхеад гори когнитивну енергију боље потрошену на кориснике Процес изгледа озбиљно споља.Унутра, одлаже само учење које одређује да ли компанија живи или умире. практичне   Један заштићен гране са краткотрајним гранама које трају сате или дане, а не недеље. За производњу. не Branch, no release branches, no hotfix branches.If three engineers need a branching strategy diagram, нешто је већ погрешно. 1. GitHub Flow is enough. main main develop   Са карактеристикама и солидном посматрањем, производња је једино окружење које говори истину, а окружења постављања су скупе лажи које одржавате да бисте се осећали безбедно. 2. Test in production.   Они вам омогућавају да одвојите испоруку од ослобађања, што значи да можете свакодневно распоређивати код и пребацити функције када су спремне. Знамења вам омогућавају да испоручите непотпуни рад невидљиво, А / Б тестирање са стварним корисницима, плаћене сегменте у односу на експерименталне функције и убије неуспјехе одмах. 3. Feature flags are non-negotiable. Алати као што су Верцел, Нетлифи, Рендер и Железница генеришу јединствене URL-ове за преглед за сваки ПР, тако да заинтересоване стране виде стварне промене одмах без заједничког окружења за одржавање и без изговора "раде на мојој машини". 4. Preview deployments for every change. У овој фази, покривеност тестирања јединице је прецењена јер вам није потребна покривеност од 80%, потребни су вам брзи уловци. Алати као што су ГитХуб Цопилот, Цурсор, или посвећени ПР преглед ботови одмах указују на очигледне проблеме, што је брже и јефтиније него блокирање на колеге. 5. AI-assisted code reviews over waiting for humans. Користите Сентри за грешке и ПостХог или Микпанел за понашање корисника, са свим упозорењем директно на Слацк тако да знате када нешто прекине у секунди, а не када фрустрирани корисник пошаље е-пошту. 6. Observability over exhaustive testing. Управљајте упозорењима о грешкама, обавештењима о распореду, догађајима аналитике и повратним информацијама у апликацији на посвећене канале и додајте једноставан виџет за повратне информације вашем производу тако да корисници постану ваш тим за квалитет у реалном времену. 7. Slack as mission control. * Оптимизирајте за брз опоравак, а не савршену превенцију. ** Петминутни повратак превазилази 2-дневни циклус КА, тако да често испоручујете, пажљиво посматрајте и одмах вратите ако нешто прекине. Доња линија Ваш процес ослобађања је опклада о томе шта ће вас прво убити.Пре него што се тржиште производа уклопи, опасност је да се изгради погрешна ствар док се писта смањује. 
 
 
 
 Процес одражава страх.Знајте који страх одговара вашој фази. Позајмљена зрелост је скупа. Да је ГитФлов подешавање имало смисла у вашој последњој компанији. Вероватно није сада. Оптимизирајте колико брзо можете да промените правац, а не колико се чврста основа осећа. Брзо брод. научите брже

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

Овај аудио је произведен на оригиналном језику приче!

Ваш процес ослобађања је пројекција страха

About Author

КОМЕНТАРИ

ХАНГ ТАГС

ОВАЈ ЧЛАНАК ЈЕ ПРЕДСТАВЉЕН У

Related Stories

Building a website with React and Bulma

Building the Cloud Future: Sreedevi Velagala's Trek in AWS Architecture

Leadership Success Story: Srinath Muralinathan's Transformative Projects at Amazon

Scaling Web Testing with Automation: Srikanth Srinivas’s Digital Strategy Breakthrough

Building a website with React and Bulma

Building the Cloud Future: Sreedevi Velagala's Trek in AWS Architecture

Leadership Success Story: Srinath Muralinathan's Transformative Projects at Amazon

Scaling Web Testing with Automation: Srikanth Srinivas’s Digital Strategy Breakthrough

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps