

ソース管理、バージョン管理について知恵をお貸しください。

C#にて自社パッケージ開発をしているのですが、パッケージとは名ばかりで、  
結局のところユーザーごとにカスタマイズすることが多く、ソースの管理に  
手を焼いております。

現在はTeam Foundationを利用し始めております。  
基本プロジェクトとしてベースとなるプロジェクトを作成し、  
それをユーザーごとに新しいプロジェクトとしてコピーした後に  
カスタマイズしております。

そうしますと、当然ながらバグがあった場合にすべてのプロジェクトに  
手作業にてパッチ当て作業が発生しますので、ユーザー数手間がかかることになります。

仕方が無いと言えばそうかなと思うのですが、考え方やTeam Foundationの使い方、  
管理のしやすいプログラム構成の良い方法等がございましたらご教示いただけませんでしょうか？

宜しくお願いいたします。


CC BY-SA 3.0
2015-11-30T15:35:23.123
19481
2016-06-22T19:43:34.830
2016-06-22T19:43:34.830
10492
13462
question
c# 構成管理
顧客ごとにカスタマイズされるソースコードの管理方法


gitでお客さん毎にブランチを作ったこともありますが、10顧客の時点でギブアップでした。

結論としては顧客ごとの管理は実は管理ではなく問題の先送りをしているだけで、技術的負債を積み上げるだけなのでやらない。ソースは一本だけで、顧客固有の機能はプラグインなどで実装する、となりました。

コアのブランチ、カスタム機能のブランチ、さらにお客さん毎のブランチなどとしていれば、理論的には管理可能なのです。

でも、そのうち「取り急ぎ」のコミットが顧客ブランチにされるし、バグが見つかれば、他のお客さんの稼働中のコード全部の開発ブランチを作って、テスト＆マージになり、その間に先の「取り急ぎコミット」がコンフリクトを起こしたりします。マージも毎回数百のコミットの検証をしないといけない。

仮にうまく管理できていたとしても、先に稼働開始したv1.0のソースを１年後にいじるのは厳しいです。書類上のバグ管理ができていたとしても、自信を持ってマージ一発とはいかないです。ソース以外にもデータの移行もありますね。

「管理が甘い」「数百コミット程度でギブアップはヘタレ」「ユニットテストをきちんと書いていれば問題ない」という意見もあるかもしれませんが、個人的にこう言う仕事のやり方はスケールしないし、管理に手間を掛けるのは生産的だと思えません。ウェブサービスの時代に逆行していると思います。従って最初の結論になりました。

プラグイン化するとは結局内部のAPIの設計をすることで、APIのバージョンのメジャー番号が同じ(v1.x)時は下位互換性を担保します。下位互換が担保できない時はバージョンをあげますv1.x
->
v2.x。こうすればお客さんの管理はv1系列、v2系列というメジャー番号だけで管理できますね。v1系列ならパッチは簡単にあたるけど、v1->v2は移行作業が必要とすぐわかります。

参考：[セマンティックバージョニング](http://semver.org/lang/ja/)


CC BY-SA 3.0
2015-12-01T16:23:53.370
19526
2016-01-20T05:35:00.997
2016-01-20T05:35:00.997
7837
7837
19481
answer