第8章 ブランチ戦略

ページ 1 / 5

01/ 05Git・GitHub

ブランチ戦略

読了目安 約 4実践
読みはじめる

Git と DB のブランチは 1 対 1

DB ブランチは差分だけのコピーで、何 GB でも一瞬で作れます。

  1. 2 系統『永続の幹』と『PR ごとの使い捨て』
  2. 使い捨てPR の開閉に連動して CI が自動処理
  3. スキーマ正本は Git のマイグレーション

なぜ Git と Neon でブランチをそろえるのか

Git のブランチは開発の日常になりました。では、同じ気軽さでデータベースまで分岐できたら、開発は何が変わるのでしょうか。幹と枝の役割分担を、1 本の木からたどりましょう。

mainGit: main / Neon: production
stagingGit: staging / Neon: staging
dev/alice開発者 alice 専用
dev/bob開発者 bob 専用
preview/pr-123PR #123 専用・使い捨て

各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。

この図をテキストで読む

構成図「Git のブランチ と Neon のブランチを 1対1 で対応させる」。ブロック5個、つながり4本。 【ブロック】 - main: Git: main / Neon: production - staging: Git: staging / Neon: staging - dev/alice: 開発者 alice 専用 - dev/bob: 開発者 bob 専用 - preview/pr-123: PR #123 専用・使い捨て 【図の符号】赤紫の枠=データの置き場 / 破線の枠=外部のサービス 【流れ】 - 永続の幹(消さない): main → staging - 開発者ブランチ(準永続): main → staging → dev/alice - 使い捨て(PRごと): main → preview/pr-123

PRごとに『作ってはすぐ壊す』流れ(GitHub 連携)

feature ブランチを push、PRを作成PR作成PR open イベントで CI を起動CI起動preview/pr-123 を作成(本番のコピー)ブランチ作成接続URLを返す(即時)接続URLマイグレーション適用+テスト+プレビュー検証プレビューURLをPRにコメントURL通知PRをマージ(または close)マージmerged / closed イベント終了通知preview/pr-123 を削除ブランチ削除片付け完了(待機ぶんは scale to zero)完了
開発者PRを出す人
GitHubリポジトリ / PR
CIGitHub Actions
NeonDBブランチ基盤

各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。

この図をテキストで読む

シーケンス図「PRごとに作って、用が済んだら壊す(GitHub 連携)」。参加者4人、ステップ10個。 【参加者】(左から右) - 開発者: PRを出す人 - GitHub: リポジトリ / PR - CI: GitHub Actions - Neon: DBブランチ基盤 【流れ】(上から下へ) ── ① PRを開く → 使い捨てDBを自動で作る ── 1. 開発者 → GitHub: feature ブランチを push、PRを作成 2. GitHub → CI: PR open イベントで CI を起動 3. CI → Neon: preview/pr-123 を作成(本番のコピー) 4. Neon → CI: 接続URLを返す(即時)(応答) 5. CI(自身で処理): マイグレーション適用+テスト+プレビュー 6. CI → GitHub: プレビューURLをPRにコメント(応答) ── ② PRをマージ/クローズ → 使い捨てDBを自動で壊す ── 7. 開発者 → GitHub: PRをマージ(または close) 8. GitHub → CI: merged / closed イベント 9. CI → Neon: preview/pr-123 を削除 10. Neon → CI: 片付け完了(待機ぶんは scale to zero)(応答)

コピーオンライトだから、作成も削除も一瞬で済みます。

永続ブランチ と 使い捨てブランチ を見くらべる(早見表)

各セルをクリックすると、その意味や詳しい説明がここに表示されます。

この図をテキストで読む

比較表。2列 × 8行。 【列】 1. 永続ブランチ(ずっと残す) 2. 使い捨てブランチ(PRの間だけ) 【比較】(観点ごとに) ■ 寿命 - 永続ブランチ: ずっと(消さない) - 使い捨てブランチ: PRの間だけ ■ 例 - 永続ブランチ: main / staging / dev/alice - 使い捨てブランチ: preview/pr-123 ■ 数 - 永続ブランチ: 少数 / 環境+人数ぶん - 使い捨てブランチ: PRの数だけ増減 ■ Gitとの対応 - 永続ブランチ: 長命ブランチに対応 / main / staging - 使い捨てブランチ: feature / PR と1対1 ■ 名前合わせ - 永続ブランチ: ゆるくてよい / 手動・少数 - 使い捨てブランチ: 厳密に合わせる / CIが機械照合 ■ 作成・削除 - 永続ブランチ: 手動・たまに - 使い捨てブランチ: CIが自動で作成&削除 ■ 鮮度の保ち方 - 永続ブランチ: 定期リフレッシュが必要 / 再生成 / reset from parent - 使い捨てブランチ: 常に新鮮 / 毎回作り直す ■ コスト - 永続ブランチ: 常時ぶん(ただし安い) / 待機は scale to zero - 使い捨てブランチ: PR中だけ・差分課金 【観点】 - 永続を見る: 永続ブランチ - 使い捨てを見る: 使い捨てブランチ

名前を厳密に合わせるのは、主に使い捨ての方です。

『永続』も定期的に捨てる

常設の dev ブランチを不変だと思わないのが勘どころです。作るのも消すのも一瞬なので、週次などで作り直すと本番相当の新鮮なデータで開発でき、『手元では動くのに本番で壊れる』を避けられます。

押さえておきたい用語

コピーオンライト
複製時に実体を丸ごとコピーせず、変更した部分だけを記録する方式。何 GB あってもブランチ作成が一瞬で済む。
使い捨てブランチ(ephemeral)
PR の間だけ存在し、閉じると消すブランチ。preview/pr-123 など、Git の feature ブランチと1対1で対応する。
プレビュー環境
PR ごとに使い捨て DB ブランチを立て、本番のコピーで変更を検証する仕組み。GitHub Actions などで自動化する。
reset from parent
ブランチを削除せず、親ブランチの最新状態へ中身を巻き戻す Neon の操作。常設ブランチの鮮度を保つのに使う。
scale to zero
使っていないブランチのコンピュートを自動停止する仕組み。待機中のブランチの費用がほぼ0になる。
マイグレーション
テーブル定義の変更を記録・適用する仕組み。Drizzle ではファイルとして Git 管理し、スキーマ変更の正本になる。
ゴール

データベース のまとめ読み』を読み終えました。

データベース の記事 11 本を、行き来せずひととおり読み終えられます。

ページ 1 / 5