SVNのバージョン管理戦略を考え出す

9

24時間体制で、会社のバージョン管理の戦略を考えてみます。現在はSVNを使用していますが、構造はありません-基本的にトランクしかなく、それにコミットするだけです。最近、開発マネージャーが「タグ」として機能する2番目のリポジトリーを開始しましたが、同じリポジトリーの一部ではなく、完全に別のリポジトリーであるため、「トランク」と手動でマージする必要があります。実際には、「Dev」と呼ばれるフォルダーが1つだけあります（実際には「Dev」フォルダーは日付によって異なりますが、「Dev」だけがメインのフォルダーです）。他のすべてのプロジェクト。プロジェクトごとに構成されているわけではなく、ブランチ/タグ/トランクなどの概念はありません。最初に設定した人（長い間、もちろん）SVNをセットアップする方法をまったく知らないようで、それ以来、何かを壊すことを恐れて適切に行う方法を学ぶことに誰も悩まされていません。CIは使用していません（残念ながら自動テストも行っていません）。

まず、プロジェクトごとに分離する必要がありますか？たとえば、2つのASP.NET Webサイト（Webアプリケーション、Webサイトではない）、Webサービス、すべてのテーブルスクリプトとストアドプロシージャの展開フォルダー、外部プロジェクト用の2つのコマンドラインクライアントWebサイトと、共通のビジネスオブジェクトなどを含む共有フォルダー。これらはそれぞれブランチ/タグ/トランクの設定を備えた独自のプロジェクトであるか、または次のようである必要があります。

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

すべてのブランチがあり、すべてにDevフォルダー全体のコピーがありますか？共有コードライブラリと少なくとも1つ（通常は両方）のWebサイトにも変更を加える必要がある状況がよくあるため、このアプローチは飲み込みやすいかもしれません。

次に、開発サーバーとライブサーバーへの定期的なリリース（用語では "プッシュ"）を行います。私がこれを処理する最良の方法を読んだことから、すべての開発はtrunk /に行き、ブランチは「一時的」であり、トランクに影響を与える可能性のある新しい機能を追加するために使用され、タグはリリース用です？それで、毎月プッシュしてみましょう、そして私は真新しいモジュールに取り組んでいます。トランクを分岐し、その分岐をコードに使用して、コードの記述とテストなどを行います。モジュールが完成したら、トランクにマージして（おそらくブランチを削除して）、デプロイの準備ができたら、タグを付けます（「May2011」としましょう）。公開後にバグ修正がある場合は、May2011タグで修正され、トランクにマージされます（トランクも修正されます）。そして、May2011は修正により再び押し出されますか？これはタグ付けの意図ですか？

version-control svn

— ウェイン・モリーナ
ソース

5

ボックス戦略の外：gitに切り替えます。

— Rein Henrichs、

それが選択肢だったら、私はそれをやります（私たちはWindowsショップなのでMercurial）。少なくともSVNで適切な環境をセットアップしようとするよりも、まったく新しいソース管理システムに移行しようとすると、さらに抵抗に直面すると思います。

— ウェインモリーナ

2

DVCSには興奮していますが、Subversionは優れたツールです。フォルダーのバージョン管理を行わないCVSまたは別のソリューションの方が悪いでしょう。

— Matthew Rodatus

2

@ウェインM-あなたはそれが実際には逆だと思うかもしれません。DVCSを使用することの利点をすべて得ることができれば、より賢明な環境構造にサインアップする方が簡単になる可能性があります。移行として、gitosvnまたはhgsubversionを使用して、peopelに安価なローカルブランチ/レポアクセスを試すことを検討することをお勧めします。それらがフックされてツールに使用されると、プライマリリポジトリのDVCSに移動したいというグループ全体の要望が存在する可能性があります。

— マークブース

5

統一されたビルドプロセスが必要な場合は、次のようにルートにブランチ/タグ/トランクを配置してください。

branches/
tags/
trunk/
  dev/
    ...

統合ビルドプロセスが必要ない場合は、必要に応じて各プロジェクト内にブランチ/タグ/トランクを配置できます。ただし、各プロジェクトに配置した後、統合ビルドに移行するのは難しい場合があります。統合ビルドには、プロジェクト間で共有コンポーネントを公開する必要がなくなるなどの利点があります。これらはすべてビルドの一部です。

個人的には、統合ビルドプロセスが好きです。さらに、私はあなたが「開発」プロジェクトを持つべきではないと思います。トランクの直下にプロジェクトがあり、トランクをdevブランチにブランチする必要があります。リリースにはタグを使用します。たとえば、次のようにします。

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

— マシュー・ロダトゥス
ソース

1

統合ビルドには、プロジェクト間で共有コンポーネントを公開する必要がなくなるなどの利点があります。これらはすべてビルドの一部です。

— Matthew Rodatus、

2

複数の統合ビルドが必要な場合は、それぞれのトランクの下にディレクトリを作成します。しかし、私は「dev」という名前は付けません-それはブランチで行う方が良いでしょう。たとえば、2つの主要な開発組織があるとします。1つはデバイスドライバーで機能し、もう1つは会社のWebサイトで機能します。おそらく、2つの別々の統合ビルドが必要です。

— Matthew Rodatus

1

svn内のコード構造に関する限り、これは本当に個人的な選択です。

プロジェクトが関連している場合やコードを共有している場合は、共通のトランクが必要であることをお勧めします。独立している場合は、別のトランクまたは別のリポジトリが必要です。プロジェクトのsvn履歴のコピーをサードパーティに提供する必要がある場合は、別のリポジトリにあるとはるかに簡単です。

したがって、あなたの場合、コードを共有していて、ブランチ/タグにその共有コードを含めたいので、上でスケッチしたレイアウトは妥当だと思われます。

タグとブランチの使用についてのあなたの説明は非常に賢明に聞こえ、私がsvnを使用することを私が期待する方法です。私が理解しているように、それは確かにタグ付けの意図です。BTWのsvnタグとブランチは実際には同じものですが、用語は適用したとおりに適用されます。

個人的には、トランクにコミットするものはすべて構築する必要があり、アトミックであり、ユニットテストを壊してはならないという警告も追加します。ブランチは、進行中の未完成の作業用です。トランクはいつの時点でも潜在的なリリース候補になると思います。

— ルーク・グラハム
ソース

テスト済みの量産対応コードのみがトランクにあるべきだと言っていますか？コミットされたコードはビルドしておそらくテストに合格し、トランクコードはもちろんテストに合格するはずです。しかし、SVNの目的は開発履歴をたどることができるようで、複数のブランチに分割されていない方が簡単です。おそらく、トランクがテスト済みの本番用の状態にあるときに、トランクをマージするブランチがあるはずですか？

— ジェファーソン氏

0

以下は、Subversionリポジトリをレイアウトする最良の方法です。

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

この方法で、個々のプロジェクトを自分でチェックアウトできます。

3つのプロジェクトすべてをチェックアウトし、モノリシックビルドスクリプト/システムを使用して統合ビルドを実行する場合は、svn：externalsでマスターモジュールを使用して、他のすべてのプロジェクトをマスターにマッピングすることを検討してください。 trunk

これは一見するとより複雑ですが、Subversionでこの問題を解決するための最も保守的で慣用的な方法です。

2

私は強く反対します。リポジトリは単にコードを格納するだけではありません。組織構造とコンポーネント間の関係を伝達します。暗黙的ではありますが、重要な通信チャネルです。各プロジェクトを個別に分割すると、人為的で不要なコミュニケーションの障壁が生じます。

— William Payne