はじめに
現在開発しているプロダクトでは、プロジェクト毎にスクラッチでプロダクトを開発しています。
作り始めは数が少なかったのでリポジトリの1ブランチですべてのプロジェクトのコードを管理していました。
しかし、プロジェクトの数が増えるごとに煩雑化してきたためうまく分割できないか？と考え始めたのが始まりです。
前提
今回決定した構成はおそらく100点の回答じゃないだろうなと自分でも感じています。
ただ、ほかの会社でも似たような現象があるんじゃないか？と思って記事にしてみました。
いろいろ意見をもらえると嬉しいです。
私について
Gitにちょっとだけ詳しいPythonエンジニアです。
SIerで言ってた派遣先でリリース担当になった際にGitを猛勉強して以来、転職先では自分が一番Gitに詳しいという理由でリポジトリの管理者をよくやっています。
よりよいリポジトリの構成については勉強中なので、この記事で行った施策に疑問を抱いている節があります。
困っていたこと
大きく以下の3つの点で困っていました。
- プロジェクトごとに異なるバージョンの自社ライブラリを使いたい
- mainブランチの肥大化
- 各プロジェクトのリリースが煩雑
異なるバージョンのライブラリを使いたい
Pipfileでライブラリのバージョンを管理しているのですが、rootディレクトリにあるPipfileをプロジェクトを変えるたびに変更する必要がありました。
プロジェクトごとに管理をしたかったが、現状のリポジトリ構成ではできないのが問題となっていました。
mainブランチの肥大化
プロジェクトが増えれば増えるほどmainブランチが肥大化し、ソースコードを管理し辛くなっていました。
リリースが煩雑
リリースのたびにプロジェクトに必要なファイルを精査する必要があり手順が煩雑になっていた
解決策
これらを解決するために以下の2つの手段を考えました。
- プロジェクトごとのリポジトリを作成する
- リポジトリごとのブランチを作成する
リポジトリを作成する
メリット
- ほかのプロジェクトと完全に切り離せる
デメリット
- 別プロジェクトとの切り替えが行いにくい
- 全プロジェクトにかかる変更があったときに反映させにくい
- 似たようなリポジトリを大量に作成することになる
ブランチを作成する
メリット
- 別プロジェクトとの切り替えが容易
- 全プロジェクトにかかる変更を反映させやすい(リポジトリ分割と比較した場合)
デメリット
- ブランチを大量生成することになる
どの解決策を選んだか
どちらを選んでもブランチorリポジトリが大量に増えてしまうデメリットはなくせませんでした。
業務の都合上複数プロジェクトを掛け持ちで作業することが多かったため別プロジェクトとの切り替えが容易なブランチをプロジェクトごとに作成する方針に決定しました。
おわりに
似たような分野のプロダクトを開発しているのでそもそもアーキテクチャから見直してあげれば解決しそなところが悔しい部分です。
個人的にブランチが大量に生えちゃっているのがかなり不健全だと思うのでそのあたりが改善できるように今後も検討を続けていきたいです。
もっといい方法がありそうなので募集しています；；