ENTERPRISE GIT / REPOSITORY & RELEASE

Enterprise開発における
Repository分離とRelease運用

― branch管理より「昇格管理」で考える

同僚向け勉強会 / Git運用の話

まず前提: 小規模ならシンプルでOK

個人開発や小規模Webサービスでは、こんな運用でも十分成立することが多い。

main に merge → deploy

特に問題は起きないし、これで回る。

ただ、Enterprise向け開発になると事情がかなり変わってくる。

Enterpriseになると要件が増える

例えば、こういう要件が出てくる。

顧客承認が必要
staging環境での検証が必要
本番環境への権限を制限したい
rollback可能にしたい
監査ログを残したい

すると、単純なbranch運用だけでは整理しきれなくなってくる。

整理しきれないと、こうなる

「この修正、本番に入ってたっけ？」
QA中にコードが変わる
rollback が怖い
branch が増殖する

心当たり、ありませんか？今日はこのへんを整理する話。

今日話すこと

実際にEnterprise向け案件で検討した運用をもとに、3つを整理します。

1 なぜ Repository を分けるのか
2 branch をどう役割分離するのか
3 release をどう管理するのか

なぜEnterpriseではRepositoryを分けるのか
Repository境界 = 昇格境界
今回の構成
よく起きる問題
提案する運用
各branchの役割
開発フロー（feature → dev → main）
Tag運用
本番Repositoryへの昇格
Code Freeze の考え方
避けたいこと
この運用のメリット

なぜEnterpriseではRepositoryを分けるのか

最初に重要なのは、「本番保護」がかなり重要になるという点。

小規模開発では main = production でも成立することがある
でもEnterprise案件（顧客環境 / 金融系 / 大企業 / 閉域環境）では…
開発者が直接本番へ触れないようにしたいケースが珍しくない

その結果として、Repository自体を分離する構成が採用されることがある。

Repository分離の構成（俯瞰）

開発Repository │ ▼ 本番Repository

Repository を跨ぐところが、品質・承認のチェックポイントになる。

Repository境界 = 昇格境界

branch管理より「昇格管理」を重視する

feature/* │ ▼ dev │ ▼ 開発repo/main │ ▼ 本番repo/staging │ ▼ production

Repository を跨ぐごとに、

品質
安定性
承認レベル

を上げていく構造。

視点を変える

「どの branch を使うか」
よりも
「どのコードを、どの環境へ昇格させるか」

を管理することが重要になる。

今回の構成

開発 REPOSITORY

dev → 開発環境
main → 次段階へ受け渡し

本番 REPOSITORY

staging → 本番前検証
main → production

この構成自体、Enterprise開発としてはかなり合理的。

この構成のメリット

開発と本番の責務分離

どこで何を担保するかが分かれる

権限制御

本番Repoへの書き込みを絞れる

監査対応

誰が何を昇格させたか残る

本番保護

事故が本番に直行しにくい

よく起きる問題 ①「本番に入ってたっけ？」

複数環境・複数Repository構成では、

どの commit が本番なのか…？

を追跡しづらくなる
特に tag運用が曖昧だと、かなり起きやすい

よく起きる問題 ② QA中に dev が変化する

例えば QA 中に、別 feature が merge されると…

別feature が merge ↓ 昨日は OK だったのに、今日は落ちる

原因は QA対象が固定されていないこと。

よく起きる問題 ③ main の役割が曖昧

main が…

release branch なのか
staging 用なのか
単なる mirror なのか

が曖昧になると、チーム内の認識がズレる。

提案する運用（全体像）

開発 REPOSITORY

feature/* │ ▼ dev │ ▼ main # = Release Candidate

本番 REPOSITORY

staging │ ▼ main # = production

各 branch の役割

`feature/*`

個別開発用 branch

`dev`

開発統合 branch。日常開発を集約する場所

開発repo/`main`

Release Candidate。次段階へ渡せる品質を持つ

本番repo/`staging`

本番前検証環境

本番repo/`main`

production

ポイント: 開発repoの main を「Release Candidate」として扱う

開発フロー ① feature は dev から切る


git checkout dev
git pull
git checkout -b feature/add-search-filter

日常開発はすべて dev を起点にする。

開発フロー ② feature → dev

各 feature は dev へ統合する。

feature/* │ ▼ dev

ここでは、開発QA / 動作確認 / 軽い検証などを行う。

開発フロー ③ dev → main（= Release Candidate）

release したいタイミングで、dev → main へ PR を作成する。

dev │ ▼ main # Release Candidate

main は「次段階へ渡せる品質」 = QA済 / deploy可能 / rollback可能な状態を維持する。

Tag 運用はかなり重要

main へ昇格した commit には tag を付与する。


git checkout main
git tag v1.4.0-rc1
git push origin v1.4.0-rc1

tag は branch ではなく「commit」に付く。 v1.4.0-rc1 = 「この commit が release candidate」という意味。

rollback / traceability / 監査対応で、これがかなり効いてくる。

本番Repositoryへの昇格

開発repo/main の内容を本番repo/staging へ受け渡す。

このとき、こういう PR 名にすると分かりやすい：

Promote v1.4.0-rc1

その後 regression test / infra確認 / 顧客確認
問題なければ staging → main へ昇格し、本番反映

staging │ ▼ main # production

Code Freeze の考え方

Enterprise案件では「Code Freeze」という言葉が出てくる。ただ、重要なのは…

開発全体を止めることではなく、本質は「release対象を固定すること」。

dev = 開発継続 main = release固定

これで、QA中に dev が変化しても影響を受けにくくなる。

避けたいこと: 本番Repoだけを修正する

本番repo だけ修正 ← これはNG

これをやると…

差分追跡が困難
同期漏れ
rollback困難

理想は「修正は必ず開発repoで行い、昇格させる」

この運用のメリット

Release対象が明確

v1.4.0-rc1 のように追跡できる

QAが安定する

QA対象が固定される

rollbackしやすい

tag 単位で戻せる

traceability が向上

どの commit が staging / production へ昇格したか追える

最後に

Enterprise向けGit運用は、branchを増やせば解決ではない。
重要なのは「どのRepositoryが何を責務に持つか」「どのbranchがどの品質を持つか」。

dev = 開発統合 main = Release Candidate tag = Release Identifier

「誰が、どのコードを、どこへ昇格させたのか」を追跡できることが、Enterpriseでは非常に重要。

branch管理より「昇格管理」で考える

おわり / Q&A

議論したいポイントあればどうぞ 🙌

PDF化したいときは index.html?print-pdf をブラウザで開いて印刷 → PDF保存

Enterprise開発におけるRepository分離とRelease運用