web-dev-qa-db-ja.com

企業のコミュニケーション、構成管理、テスト要件が重いMercurialリポジトリ構造

私は、分散バージョン管理のTaoで自分自身を再教育するのに苦労しているさらに別のSubversionユーザーです。

Subversionを使用していたとき、私はプロジェクトマイナーアプローチの大ファンでした。そして、以前の雇用主のほとんどと一緒に、リポジトリブランチを構築しました。タグとトランクは次のとおりです。

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

実際のソースツリー自体の中で、次のような構造を使用します。

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

アイデアは（そして今もそうですが）リポジトリの構造を使用して、エンジニアリングチーム間のコミュニケーションを構造化することを支援することでした。ビジネスの顧客向けの部分と、その他のさまざまな利害関係者およびドメインの専門家。

つまり、「プロジェクト」ディレクトリの1つにあるソースドキュメントは、一度しか使用されません（そしてお金を稼ぎます）。 "productLines"ディレクトリの1つにあるドキュメントは、その特定のラインの製品が販売される回数と同じくらいの金額を稼ぎます。 「ライブラリ」ディレクトリの1つにあるドキュメントは、それらを使用する製品が販売される回数と同じ回数だけお金を稼ぎます。

これにより、コストの償却の概念が明確になり、ビジネス全体でソースドキュメントを再利用するためのサポートを構築できます。

また、ビルド自動化ツールが動作できる共通の構造があることも意味します。 （私たちのビルドスクリプトは、ソースツリーをたどって、各コンポーネントのビルド方法を指定する構成ファイルを見つける「ビルド」フォルダーを探します。ドキュメントの生成とテストでも同様のプロセスが発生します）。

重要なことに、私が作業している製品は通常、パフォーマンス測定と特性評価テストを実行するのに長い時間がかかります。 20から200時間;数GBから数GBのどこかで生成TB処理済みテスト結果/中間データ（保存して特定のシステム構成に関連付ける必要があるため、時間の経過によるパフォーマンスの向上を測定できるようにする必要があります）。この問題により、構成通常、パフォーマンス測定と特性評価テストを実行するために必要な計算リソースは限られているため（64-128コアの小さなクラスター）、管理は重要な考慮事項であり、一元化の要件も課します。

最後に一言。継続的インテグレーションシステムは、ビルドをトリガーする必要があることを認識しています。静的分析;トランクが変更されるたび、「タグ」ブランチが変更されるたび、および「自動化」ブランチブランチが変更されるたびに、煙のテストとユニットテストが実行されます。このようにして、個々の開発者は個人のブランチでCIシステムを使用できます。これは重要な機能であるIMHOです。

さて、これが私の質問です。Mercurialを使用して、上記のすべてをどのように再現できますか（可能な場合は改善します）。

-編集：

私の現在の考え方は、中央のSubversionリポジトリを使用して全体的な構造を定義することですが、開発者がローカルでリポジトリを利用できるようにhgをクライアントとして使用できるようにすることです。

mercurialorganizationcontinuous-integrationsvnconfiguration-management
16
William Payne

スポークの答え は素晴らしいですが、コメントとしては大きすぎるので、追加する価値があると思う点がいくつかあります。

支部組織

Mercurialを使用すると、最初の組織図をすべて無視できます。スポークが言うように、各リポジトリには独自のタグ、ブランチ（名前付き、匿名）のセットがあり、ビジネスニーズに応じて編成できます。

bespokeProjectTwoにchartingライブラリの特別なバージョンが必要な場合は、chartingに分岐し、新しい機能を追加してbespokeProjectTwoで使用します。新しい機能（およびそのバグ）は、標準のchartingライブラリを参照する他のプロジェクトでは使用されません。メインのchartingライブラリにバグが修正されている場合は、それらの変更をブランチにマージできます。他のプロジェクトでもこれらの機能が必要な場合は、それらのプロジェクトでspecialブランチを使用するか、ブランチをメインラインにマージして閉じることができます。ブランチ。

また、AUTOMATIONブランチのような特定の機能を提供するためにブランチ名を構造化するポリシーを持つことを妨げるものは何もありません。

ディレクトリ構成

Mercurialのようにソースディレクトリを正確に保持できない理由はありません。唯一の違いは、Subversionでは単一のモノリシック(src)リポジトリ、Mercurialでは、論理的にグループ化されたリポジトリに分割した方がよいでしょう。あなたのソースツリー構造から、おそらく以下のそれぞれを個別のリポジトリとして抽出します：

src-+
      +-(developmentAutomation)
      +-libraries-+
      |           +-(log)
      |           +-(statistics)
      |           +-(charting)
      |           +-(distributedComputing)
      |           +-(widgets)
      +-productLines-+
      |              +-(flagshipProduct)
      |              +-(coolNewProduct)
      +-project-+
                +-bigImportantCustomer-+
                |                      +-(bespokeProjectOne)
                |                      +-(bespokeProjectTwo)
                +-anotherImportantCustomer-+
                                           +-(anotherBespokeProject)

これにより、productまたはbespoke projectがライブラリの任意の組み合わせを使用できるようになります。どんな改訂でも。製品またはプロジェクトの特定のバージョンで使用されているライブラリを管理する簡単な方法については、 Mercurial sub-repositories を参照してください。

ワークフロー

Spoikeが提案するワークフロー（開発者が祝福されたレポからプルし、ローカルで動作し、プルリクエストを発行し、最後にインテグレーターがそれらの変更をプルしてマージする）の代替は、仲介者として継続的インテグレーションシステムを使用することです。

以前と同様に、開発者はblessされたレポからプルしてローカルで作業しますが、完了すると、blessされたレポから再度プルし、マージしてからblessされていないレポにプッシュします。祝福されていないリポジトリへの変更はすべて（手動または自動で）レビューされ、承認された場合にのみ祝福されたリポジトリに移動されます。

これは、インテグレーターは変更を承認または拒否するだけで、マージは行わないことを意味します。 私の経験では、ほとんどの場合、他の誰かがマージを実行するよりも、コードを記述した開発者がマージを実行する方が優れています。

Mercurialブックで提案されているように、この手順を自動化するために hooks を使用できます。

誰もがプルするサーバーにチェンジセットをプッシュすると、サーバーはチェンジセットを永続的なものとして受け入れる前にテストし、テストスイートに合格しない場合はチェンジセットを拒否します。人々がこのフィルタリングサーバーから変更をプルするだけの場合、それは人々がプルするすべての変更が自動的に検査されることを保証するのに役立ちます。

その他の問題

大規模なテストデータセットの問題は、そのテストデータを Mercurial sub-repository に入れることでも解決できます。これにより、テストデータがリビジョン管理されたまま、コードリポジトリがテストデータで肥大化するのを防ぐことができます。

10
Mark Booth

わかりました、これに単純に答えようとしています。

知っておくべきこと

まず知っておくべきこと：Mercurialは分散バージョン管理であり、以下にリストするいくつかの知っておくべきプロパティがあります。

  • ソースは1つのリポジトリからのもので、そのリポジトリを複製できます。クローンされたすべてのリポジトリは、同期を通じて（プルおよびプッシュコマンドを使用して、アクセスを制限できる）コードを互いに共有できます。
  • コードのコピーを持つすべてのユーザーは、リポジトリのクローンを持っています。分岐したい場合は、ローカルクローンで分岐できます。つまり、すべてのユーザーが分岐する方法を整理する必要はありません。彼らは自分でこれを行うことができます。
  • タグはコミットによってMercurialで作成されます（gitのハードタグと同じです）。つまり、タグのリポジトリ構造内にディレクトリは必要ありません。

  • 人々がDVCS（githubとbitbucketで採用されている）で作業する通常のモデルは、半集中化することです。

    各ユーザーは、パブリックリポジトリ（一部の共有または安全なサーバー上）とプライベートリポジトリ（自分のワークステーション内）を持っています。どちらもインテグレーターの「祝福された」リポジトリーのクローンです。コードを公開する準備ができたと感じたときはいつでも、変更をパブリックリポジトリにプッシュできます。インテグレーターは、「祝福された」リポジトリーにコードをプルするユーザーを選択できます。

    インテグレーターが一部のユーザーのコードを簡単にマージできない場合、変更は拒否され、リポジトリーを更新してマージ自体を修正するのはその特定のユーザー次第です。頻繁にマージする場合（マージする必要のあるコードが少ないため）はそれほど難しくはなく、通常、ユーザーはマージの問題を知っている必要があります。

プロジェクトごとのリポジトリ設定

したがって、通常の設定では、プロジェクトごとに次のようになります。

  • インテグレーターが担当する読み取り専用の公開リポジトリー。それは「祝福された」ものです。

    つまりすべてのユーザーはコンテンツをプル/フェッチできますが、それをプッシュするアクセス権はありません。

  • 各ユーザーは、リポジトリの独自のパブリッククローンを持つことができます。

    共有ドライブに配置するのが最も簡単なセットアップ（bitbucketなどのホスティングを検討する場合もあります）。インテグレーターはユーザーからのプルリクエストを受け取り、これらのリポジトリから新しいコードをプルしようとします。マージが滞りなく行われると、読み取り専用リポジトリに配置されます。そうでない場合、ユーザーはローカルで更新およびマージすることによって発生するマージの競合を修正するよう求められます。

  • 各ユーザーは、リポジトリの独自のプライベートクローンを持つことができます。

    パブリッククローンからプルすることをお勧めしますが、パブリックまたはインテグレーターからプルするかどうかは関係ありません。すべてのコミットは一意に識別できるため、パブリックコミットでフェッチするのを忘れたマージコミットは比較的簡単に修正できます（プライベートからパブリックに変更をプッシュすることにより、インテグレーターの変更も自動的に取得されます）。

ソースコード編成

プロジェクトのソース自体をどのように配置するかについては、じっくり考える必要があります。アーティファクトをソース管理する必要がある場合は、それをソース管理に配置します。個人的には、バイナリやログファイルなど、ビルドやランタイムによって作成されたアーティファクト（これらの種類のアーティファクトでのマージ競合のリスクが高いため）をチェックインするという考えは好きではありません。

また、設定をチェックインすることもできます。ただし、開発者が使いやすく、リリースやライブ/本番環境（アプリ/ Webサーバーの設定など）の設定を台無しにしないことが条件です。これは、開発者がコードをチェックアウトしてから5分以内に開発を開始するのを大幅に妨げている場合は、リファクタリングする必要があるという考えにつながります。もう1つの要件は、開発者がリリース環境やライブ/本番環境を台無しにするのが難しいことです。

あるバージョンのコードに関連付ける必要のあるテストデータがあるとします。 MercurialやGitなどのDVCSシステムは、巨大なデータをチェックインすると遅くなる傾向があるため、これは少しトリッキーです。私の経験では、5 GBのバイナリファイルの後は本当に耐えられなくなります（マイレージは異なる場合があるため、どのように機能するかをテストする必要があります）。ただし、生成されたデータを独自のリポジトリに格納し、チェックインするときにテストシステムに適切にタグを付ける（または同じメタデータの目的でテキストファイルを作成する）ことをお勧めします。

これがすべて理にかなっているといいのですが。詳細を逃した場合、またはさらに説明が必要な場合は以下にコメントしてください。編集を試みます。

9
Spoike