バージョン管理でプロジェクトを構成するには、少なくとも 10 の異なる方法があることを知っています。使用されているいくつかの方法と、どの方法があなたに適しているか興味があります。私はSVN、TFS、そして現在/残念ながらVSSを扱ってきました。バージョン管理の実装が非常に貧弱で、問題はありませんが、素晴らしいとは言えませんでした。
ボールを転がすために、ここに私が見たもののレビューがあります.
この例は SVN ベースですが、ほとんどの VCS に適用されます (分散バージョン管理にはあまり適用されません)。
サイト /division/web/projectName/vb/src/[trunk|branches|tags] の一部である個々のプロジェクトを分岐します
サイト全体を分岐します。私が見た場合、コア コンポーネントを除くサイト全体が分岐されました。/部門/[幹|枝|タグ]/web/プロジェクト名/vb/src/
メインラインをデフォルトで使用し、大きな変更が必要な場合にのみ分岐します。
Javaを使用して高度にコンポーネント化された開発を実践しており、トランクには独立したライフサイクルを持つ約250のモジュールがあります。依存関係はMavenを介して管理され（これがベストプラクティスです）、すべてのイテレーション（隔週）でアクティブに開発されたモジュールに新しいバージョンのタグが付けられます。厳密なセマンティクスを持つ3桁のバージョン番号（major.minor.build-メジャー変更は下位互換性がないことを意味し、マイナー変更は下位互換性を意味し、ビルド番号の変更は下位互換性と上位互換性を意味します）。私たちの究極のソフトウェア製品は、Mavenの依存関係として、数十の個別のモジュールを取り込むアセンブリです。
リリースされたバージョンのバグ修正または拡張を行う必要があり、HEADバージョンを提供できない場合は、モジュール/アセンブリを分岐します。すべてのバージョンにタグを付けるとこれが簡単になりますが、ブランチには、ツールによって部分的に引き起こされる大きな管理オーバーヘッド（特に、ブランチを特定のHEADチェンジセットと同期させる）が発生します。Subversionはブランチの管理に最適ではありません。
リポジトリ内のかなりフラットで、とりわけ予測可能なツリー構造が重要であることがわかりました。これにより、手動リリースプロセスから多くの苦痛と危険を取り除くリリースツールを構築することができました（リリースノートの更新、プロジェクトのコンパイル、単体テストの実行、タグの作成、SNAPSHOTの依存関係なしなど）。ツリー構造に分類やその他のロジックを入れすぎないようにしてください。
大まかに次のようなことをします。
svnrepo/
trunk/
modules/
m1/ --> will result in jar file
m2/
...
assemblies/
a1/
...
tags/
modules/
m1/
1.0.0/
1.0.1/
1.1.0/
m2/
...
assemblies/
a1/
iteration-55/
...
branches/
m1/
1.0/
...
外部の依存関係については、Mavenのようなものを強調しすぎることはできません。リポジトリ内のバージョン管理された一意に識別されたバイナリアーティファクトへの参照として依存関係を管理します。
内部モジュール/プロジェクト構造の場合：標準に固執します。均一性が鍵となります。繰り返しになりますが、Mavenは構造を指示するため、ここで役立ちます。あなたがそれらに固執する限り、多くの構造は素晴らしいです。
SVN の例:
トランク/
ブランチ/
タグ/
トランクは、いつでもリリースできる場所に保管する必要があります。あなたが知っている巨大なギャップのあるバグがあってはなりません (もちろん最終的にはそうなるでしょうが、それはあなたが努力すべきことです)。
新しい機能を作成する必要があるたびに、デザインの変更などを行います。最初にそのブランチにタグを付けます。次に、ブランチタグが終了したら、最後にタグを付けます。これは、トランクに再びマージするのに役立ちます。
リリースをプッシュする必要があるたびに、タグを付けます。このようにして、何かがひどくうまくいかない場合は、以前のリリースにロールバックできます。
この設定により、トランクは可能な限りクリーンに保たれ、ブランチでの開発の大部分を維持しながら、迅速なバグ修正を行ってプッシュすることができます。
編集：サードパーティのものの場合は異なります。回避できる場合は、ソース管理下にありません。ソース管理外のディレクトリに保存し、そこから含めます。jquery のようなものについては、ソース管理下に置いています。その理由は、プッシュ用のスクリプトを簡素化するためです。単純に svn export と rsync を実行させることができます。
私のプロジェクトでは、常にこの構造を使用しています。
- トランク
- 構成
- ドキュメント
- sql
- イニシャル
- 更新
- src
- アプリ
- テスト
- 第三者
- lib
- ツール
- タグ
- 枝
ソリューションファイルは、ビルドファイルと一緒にトランクディレクトリのすぐ下に配置されます。
バイナリをリポジトリに配置しないというロジックは理解できますが、大きな利点もあると思います。過去から特定のリビジョン（通常は古いタグ）を引き出すことができるようにしたい場合は、必要なものすべてをsvnチェックアウトから取得できるのが好きです。もちろん、これにはVisual Studioや.NETフレームワークは含まれていませんが、適切なバージョンのnant、nunit、log4netなどを使用すると、チェックアウトからビルドに非常に簡単に移行できます。この方法で始めるのは、「svncoproject」の後に「nantbuild」を続けるのと同じくらい簡単です。
私たちが行うことの1つは、ThirdPartyバイナリを別のツリーに配置し、svn：externalを使用して必要なバージョンを提供することです。生活を楽にするために、使用されたバージョンごとにフォルダを用意します。たとえば、ThirdParty / Castle/v1.0.3フォルダーを現在のプロジェクトに取り込むことができます。このように、製品をビルド/テストするために必要なすべてのものは、プロジェクトルートの内部または下にあります。ディスクスペースのトレードオフは、私たちの経験ではそれだけの価値があります。
私はきめの細かい、非常に組織化された自己完結型の構造化されたリポジトリを好みます。リポジトリのメンテナンス プロセスの一般的な (理想的な) アプローチを示す図があります。たとえば、リポジトリの初期構造 (すべてのプロジェクト リポジトリに必要) は次のとおりです。
/project
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PAプレアルファ
を意味A するアルファ
B を意味するベータ
ARを意味するアルファリリース
BRを意味するベータリリース
RCを意味するリリース候補
STを意味する安定していることを意味する
ビルドとリリースには違いがあります。
N.x.Kに対応するバージョン番号があります。ここで、NとKは整数です。例: 1.x.0、5.x.1、10.x.33N.M.Kに対応するバージョン番号があります。ここでN、MとKは整数です。例: 1.0.0、5.3.1、10.22.33。最近、私はソフトウェア構成管理に特化したトレーニングを開発しました。ここでは、バージョン番号付けのアプローチと、このリポジトリ構造が最適である理由について説明しています。ここにプレゼンテーションのスライドがあります。
「複数の SVN リポジトリと単一の会社のリポジトリ」に関する質問に対する私の回答もあります。質問でリポジトリ構造のこの側面に対処する限り、役立つ場合があります。
同じツリーにすべてのアーティファクトと構造があるため、次のようなものがあります。
トランク
配備
チームが採用する SCM のポリシーと手順は、チームが使用する開発プロセスに大きく依存すると思います。50 人のチームで複数のメンバーが同時に主要な変更に取り組んでおり、リリースが 6 か月ごとにしか行われていない場合、全員が自分のブランチを持ち、独立して作業し、変更をマージするだけで済むのは非常に理にかなっています。彼が望むときに他の人。一方、5 人全員が同じ部屋にいるチームの場合は、ブランチの頻度を大幅に減らすことが理にかなっています。
コミュニケーションとコラボレーションが良好で、リリースが頻繁に行われる小さなチームで作業していると仮定すると、IMO を分岐することはほとんど意味がありません。あるプロジェクトでは、SVN のリビジョン番号をすべてのリリースの製品バージョン番号に丸めただけで、タグ付けさえしませんでした。製品に重大なバグが見つかったというまれなイベントでは、リリースされたリビジョンから直接分岐するだけでした。しかし、ほとんどの場合、ブランチでバグを修正し、予定どおり週末にトランクからリリースしました。リリースが十分に頻繁に行われている場合、次の公式リリースまで待てないバグに遭遇することはほとんどありません。
私は他のプロジェクトに取り組んできましたが、これは絶対に避けられませんでしたが、軽量の開発プロセスと控えめなセレモニーのおかげで、軽量のバージョン管理ポリシーを非常に効果的に使用することができました.
また、私が書いたものはすべて、特定のコード ベースの実稼働インスタンスが 1 つしかないエンタープライズ IT コンテキストから来ていることにも触れておきます。100 の異なる顧客サイトにデプロイされた製品に取り組んでいた場合、すべてのインスタンスにわたる独立した更新サイクルをすべて管理するには、分岐とタグ付けの慣行がもう少し骨の折れる作業になるはずです。
AJAXTookit や、いくつかのプロジェクトで使用されている他のサード パーティの拡張機能などの外部依存関係はどうですか?
ソース管理は、バイナリではなくソースコード用です。サードパーティのアセンブリ/jar は別のリポジトリに保管してください。Java の世界で作業している場合は、Maven や Ivy などを試してください。.Net プロジェクトの場合、単純な共有ドライブは、その構造と更新方法に関する適切なポリシーがある限り、うまく機能します。
SVN に切り替える前に、1 つの巨大なリポジトリ (4G 以上) で VSS の悪い世界から移行しました。会社の新しいリポジトリをどのようにセットアップするか、本当に苦労しました。当社は非常に「古い」学校です。私は若い開発者の 1 人で、45 歳です。私は、社内の多くの部門のプログラムに取り組んでいる企業開発チームの一員です。とにかく、私はこのようにディレクトリを設定しました
+ devroot
+--Dept1
+--Dept1Proj1
+--Dept2Proj2
+--Dept2
+--Dept2Proj1
+--Tools
+--Purchase3rdPartyTools
+--NLog
+--CustomBuiltLibrary
分岐機能を含めたかったのですが、正直なところ、現時点では多すぎます。このスキームを使用してまだ苦労していることがいくつかあります。