Gitリポジトリのリリース履歴を数千のrefで追うのはやめよう
Maybe a better way to track the release history of a Git repo
ZipRecruiterでGitモノレポのrefが数千に膨れ上がり、packed-refsの検索が遅くなる問題に直面した著者。タグ名にデプロイ情報を埋め込む運用の限界を指摘し、各(tier, app)ペアをメタ情報コミットの連結リストで表現する代替案を提示。1つのrefが最新リリースを指し、親をたどるだけで履歴を取得できる。Gitの通常の履歴メカニズムを利用するため、git logやgit diffがそのまま使え、ロールバックも容易になる。
Gitは数千のコミットを扱うようにはよく設計されているが、数千のrefを扱うようには設計されていない。
- duesabati
リリースはデプロイとは分離されるべきで、本番で動いているコードと他の環境のコードの間には事実上何の違いもないはずだ。環境ごとにリリースを作るのではなく、コードに読みやすいラベル（例えばバージョン番号）を付けて、そのバージョンのコードからアーティファクトを生成し、デプロイ時に（手動または自動ロジックで）どのバージョンのコードを使うかを決めればいい。理想的には、本番と他の環境の実行時の「違い」はすべて、まさに実行時に、つまり環境変数を通じて定義されるべきだ（通常ビルド時に作られるフロントエンドのものでも、実行時にそれを避ける仕組みがあるはず）。こうすれば挙動がはるかに予測可能になり、推論しやすくなる。また、ビルドとデプロイのパイプラインを物理的に分離できるので、必要なものに切り替える際の機敏性が大幅に向上し、ステップを明確に見てCIパイプラインの問題を修正するのが（脳にとってもLLMにとっても）ずっと楽になる。
もしどうしてもビルド時の違いが必要なら、その違いは、動くであろうと想定する環境ではなく、本当に何であるかによって特定すべきだ。なぜなら、明示的であることは常に暗黙的であるよりも優れているからだ。特にLLMや新しい開発者にとっては。
- turboponyy
> リポジトリにデプロイ履歴を記録するのは妥当に思えた
それは妥当だとは思えない。ソースコード管理に直接関係しない永続化の懸念にGitを使うことになるからだ。
「環境Xはコミットa1b2c3dを1970-01-01T00:00:00Zにデプロイした」という情報だけを保存すればよく、それをリポジトリ自体でやる必要があるとは思えない。コミットa1b2c3dは、どこでいつデプロイされようと存在する。
そのデータはデプロイを扱うものの中に保存すべきだ。