業務で、同様の構成のサービスを
「モジュールごとに別々のリポジトリを(Githubに)作成」
する方式で管理したことがあります。
その感想を、以下に記載させていただきます。
欠点
特に不便に感じたのが「Issue の管理」でした。
例えば、1つの機能開発が複数のモジュールに改修を要することはよくあることですが、
その際、
「どのリポジトリに Issue を作成すれば良いのか?」
と、毎回、悩むことになりました。
結局、
- 改修を要する全てのリポジトリに Issue を作成し、
- その中のどれか1つの Issue をマスターとし、
- その他の Issue には
See [マスターの Issue の URL]
などと記述する
という対応を取っていたのですが、面倒な上に、
「せっかく Issue を作成したのに後になってそのモジュールに改修が不要だったと判明し、そっと Issue をクローズする」
という、切ない思い(w)をすることもありました。
また、エンジニア以外の人にとっては通常、
「どの案件がどのモジュールに影響を及ぼすのか」
などは分からないので、Github の Issue を共通の案件管理ツールとして使うこともできませんでした。
(これに関しては、「それだけが理由」というわけではありませんでしたが)
今、思えば
「Issue を作成するリポジトリをどれか1つに決め、そのリポジトリ上で一元管理する」
という方法もあったかも知れませんが、それはそれで、別の問題や"やりにくさ"がありそうな気もします。
利点
逆に、利点としては
「モジュールごとの開発/テスト環境や、デプロイの仕組みを構築しやすい」
ということでしょうか?
1つ1つのリポジトリのサイズが小さくなるので、
「git clone
やgit checkout
が遅くてイライラする」
というようなことも、避けられたかと思います。
個人的には、次回、同様の構成のサービスを開発する際は
「1つのリポジトリで全てのモジュールを管理」
する方式を採りたいと考えています。
以上、ご参考までに。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/11/16 06:52