初期段階のスタートアップでは、エンジニアがマスターをセットアップし、支店を開発し、正式なリリースサイクルやステージアップ環境を構築しています。 これは、スタートアップのための精神モデルに関する私のシリーズの3番目の記事です(チェックしてください、そこに興味深い資料がたくさんあります)。 通常、製品が始まっているときに起こります。 エンジニアリングの慣習は、必要性ではなく、通常、生産の失敗が高価で重いプロセスが正しい反応だった大企業の以前の仕事から来ています。 The real challenge not stability, it is finding revenue and users しかし、スタートアップでは、これらのプロセスを早期に導入することは、学習から集中を遠ざけて儀式に向かいます。 ビジネスが実際に必要とするものと、チームがコードをリリースする方法の間のこの不一致は、以下の精神モデルが登場するところです. それぞれはリリース決定について考える異なる方法を提供し、実際のところ何が機能しているかについての実践的なアドバイスを提供します。 これは、彼らのプロセスが彼らを遅らせていると感じている創設者やエンジニアのためのものですが、なぜかわからないのです。 Who is this for? 「Mental Model 1 or Your Release Process Is A Projection of Fear」 リリースプロセスは中立なインフラストラクチャではありませんが、チームが最も恐れていることの鏡です。 (後退、中断、失われた信頼)あなたは要塞を構築します:ステージ環境、承認ゲート、長いレビュー、リリース列車。 If the deepest fear is breaking production (誰も望まない機能に時間を浪費し、製品市場に適合しない)あなたはセンサーを構築します:迅速な展開、迅速なフィードバックループ、絶え間ない実験。 If the deepest fear is building the wrong thing ほとんどのチームは決してこの選択を意識的にしない。彼らは過去の仕事からワークフローを継承し、ビッグテクのブログから「ベストプラクティス」をコピーしたり、プロとして感じるものをデフォルトにします。その結果は、他人の現実によって形作られたプロセスであり、ほとんど常に顧客の支払い、コンプライアンスニーズ、およびダウンタイムに対する深刻な結果を持つ成熟した会社の現実です。 すべてのソフトウェア会社は、決して完全に消えることのできない2つの恐怖を抱えています。 
 
 
 実行リスク:送信バグ、機能を破壊し、生産を損なう。 発見のリスク:間違ったものを構築し、適応を失い、走路から抜け出す。 これらの恐怖は反対の方向に引っ張り、あなたのリリースプロセスはそれらの間を選択するメカニズムです。ステージゲート、承認、リリース列車などの重いプロセスは、実行リスクに対して保険を提供します。 バグは1時間で修正できる問題ですが、6ヶ月間間間違った製品を構築することは、回復できない問題です。 正しい選択はほとんど常に会社の段階に従う: 
 
 
 Pre-revenue, pre-PMF: You are still proving the core hypothesis, so almost nobody outside the team uses the product. The house barely exists yet — insuring it against fire is premature. Fear irrelevance, not instability. Shipping often, learn faster than your competitors. Bugs are embarrassing but survivable. 誰も望まないものを構築することは致命的です。 Post-PMF、収入:リアルな顧客はあなたに依存しますので、ダウンタイムは、収入の損失、損失、評判の損害を意味します。現在、実行リスクは存在的になります。 恐れはビジネスのように進化すべきであり、ある段階で完璧なプロセスは別の段階で積極的に有害になる。 
 
 
 支店、パイプライン、またはルールのレビューを議論する前に、休憩して3つの質問に答えましょう。 
 
 
 
 What am I actually most afraid of right now: breaking something that works, or building something that doesn't matter? Do I have paying customers who depend on reliability, or am I still searching for the first ones? Is this process shaped by my current reality, or am I carrying forward someone else's old fears? 支店、パイプライン、またはルールのレビューを議論する前に、休憩して3つの質問に答えましょう。 
 
 
 
 実際、私は今、何を最も恐れているのですか:働く何かを破壊するか、あるいは重要でない何かを構築するか? 私は信頼性に依存する顧客を支払っていますか、それともまだ最初の顧客を探していますか? このプロセスは私の現実によって形作られていますか、それとも私は他人の古い恐怖を前進させていますか? マインドモデル2 - Borrowed Maturity 成熟した企業からリリース構造を輸入することは、進歩の幻想を生み出す一方で、黙々と学習速度を減らす。 製品市場の調和が不確実で、次のパイロットが明日になる可能性がある場合、既知のワークフローは固有の土壌のように感じますが、リリースプロセスはあなたがコードを送信する方法だけを反映するものではありません。 Process is comfort. コンウェイの法則は、ソフトウェアアーキテクチャが組織構造を反映していることを示しています. There should be a corollary: release process reflects business certainty. A company that knows what it's building releases differently than one still figuring it out. 私はこのパターンを最初の手で観てきました。ゼロの支払いユーザーを含む前収入のスタートアップ、製品はまだ仮説でした。その仮説をテストする代わりに、最初の月は「適切な」インフラストラクチャに移行しました:開発と主要支店、別々のステージ化およびプロダクト環境、CI / CDパイプライン、JiraとJiraテンプレート。 それはプロフェッショナルに見えたが、チーム外の人間が触れたことのないソフトウェアのための2つの環境を持っていた。 リリースプロセス:A Reality Check 
 
 
 
 
 
 
 
 
 
 
 
 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 リリースは固定スケジュールで行われます. Features that are ready ship with the next train, while unfinished work waits for the next one. かわいそう ゆっくり発見のスケジュール スタートアップと成熟した企業は異なる世界で暮らしており、それぞれの世界は独自の生存ルールを定めている。 大規模なチーム、並行のワークフロー、高コストの生産失敗により、GitFlowと類似のプロセスは合理的な選択肢となり、地獄と混乱を最小限に抑えることができます。 Mature companies optimize for coordination risk. 主なリスクは、生産を壊すことではありません(ユーザーはほとんどありません)。 スピードが全てを決める。 Startups need to optimize for learning latency. feedback GitFlow(または重いプロセス)をコピーすると、発見から儀式にボトルネックが変わります。 混乱したGitの歴史を持つあなたのライバルは先週、3つの実験を配信しました. You are still waiting for the release branch to stabilize. 
 
 
 
 
 
 借用された成熟度は、偽りの安全感を生み出す。 長いサイクルはピヨットを高価にする 大きな機能部門は、遅くまで統合の問題を隠す レビュー Overhead Burns Cognitive Energy Better Spend on Users(ユーザーによりよく消費される認知エネルギー) 内部は、会社が生きるか死ぬかを決定する学習そのものを遅らせる。 借入成熟度 A . false sense of safety 長いサイクルはピヨットを高価にする 大きな機能部門は、遅くまで統合の問題を隠す レビュー Overhead Burns Cognitive Energy Better Spend on Users(ユーザーによりよく消費される認知エネルギー) 内部は、会社が生きるか死ぬかを決定する学習そのものを遅らせる。 実践   1 保護 短命の機能を有する枝は、数時間または数日、数週間ではなく続きます。 プロデュース・ノー ブランク、リリースブランクなし、ホットフィックスブランクなし、3人のエンジニアがブランキング戦略図を必要とする場合、すでに何かが間違っている。 1. GitHub Flow is enough. main main develop   機能の旗と堅実な観察性により、生産は真実を語る唯一の環境であり、舞台環境は安全に感じるために維持する高価な嘘です。 2. Test in production.   彼らはあなたが発行から配送を切り離すことを可能にします、それはあなたが毎日コードを展開し、準備ができるときに機能を切り替えることを意味します. Flags はあなたが不完全な作業を目に見えないように配送し、実際のユーザーとの A / B テスト、セグメントの支払い対実験的な機能、およびすぐに失敗を殺すことを可能にします。 3. Feature flags are non-negotiable. Vercel、Netlify、Render、Railway などのツールは、あらゆるPRのためのユニークなプレビュー URLを生成するので、関係者は、維持するための共有ステージ環境なしで、そして「私のマシンで動作する」言い訳なしで、即座に実際の変更を見ることができます。 4. Preview deployments for every change. この段階では、単位テストカバーが過大評価されるのは、80%のカバーを必要としないため、迅速なキャッチが必要です。GitHub Copilot、Cursor、または専用のPRレビューボットのようなツールは、チームメイトのブロックよりも速く、安く、すぐに明らかな問題を明らかにします。 5. AI-assisted code reviews over waiting for humans. Sentry を使用してエラーと PostHog または Mixpanel を使用してユーザーの行動を確認し、すべてが直接 Slack に警告され、挫折したユーザーがメールを送信するのではなく、何らかのエラーが数秒で破られるかを知ることができます。 6. Observability over exhaustive testing. ルートエラーアラート、展開通知、分析イベント、およびアプリ内フィードバックを専用のチャンネルに送信し、ユーザーがリアルタイムのQAチームになるように製品にシンプルなフィードバックウィジェットを追加します。 7. Slack as mission control. **8 迅速な回復のために最適化し、完璧な予防ではありません。** 5 分間の回復は 2 日間の QA サイクルを打ち破りますので、頻繁に船を運び、注意深く観察し、何かが壊れたらすぐに戻ります。 Bottom Line あなたのリリースプロセスは、最初にあなたを殺すものに賭けています. 製品市場が合う前に、危険はランプが縮小する間に間違ったものを構築することです。 
 
 
 
 プロセスは恐怖を反映し、どの恐怖があなたのステージに匹敵するかを知る。 借用期間は高価です GitFlow の設定は、あなたの最後の会社で意味がありました。 逆転性は安定性を打ち負かす。基礎がどれほど固く感じるかではなく、方向をどれだけ速く変えることができるかを最適化します。 速く学ぶ!速く学ぶ!

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

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

Telegram: クリプト島と本土を結ぶ橋

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

ワークフローを10倍に向上させる方法: 必須アプリ17選

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

Telegram: クリプト島と本土を結ぶ橋

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

ワークフローを10倍に向上させる方法: 必須アプリ17選

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps