3

Subversion を使用してバージョン管理全体を学習し、プロジェクトのすべての異なる作業/バージョンに対してトランク、ブランチ、タグなどを使用しています。また、Jenkins との継続的インテグレーションを使用して速度を上げようとしています (ccnet を試してみましたが、セットアップは悪夢です!)。

私の質問は、私のプロジェクト SVN に次の領域があるかどうかです。

file:///E:/Data/SVN/MyProject/trunk
file:///E:/Data/SVN/MyProject/tags/version_1.0
file:///E:/Data/SVN/MyProject/branch/version_1.1

.. Jenkins でこのビルド プロジェクトをセットアップして、SVN のさまざまな領域がすべて継続的に監視され、変更がビルドされるようにするためのベスト プラクティスは何ですか?

各バージョン/トランクなどに 1 つずつ、複数のソース コード リポジトリを含む 1 つのプロジェクトをセットアップしますか? それとも、複数のビルド プロジェクトをセットアップしますか? どうすればいいのですか？

編集:これにマトリックスプロジェクトを使用する必要があります(マルチ構成プロジェクトをビルドします)?

4

2 に答える 2

6

ナイトリー ビルド (比較的頻繁に実行されず、通常は自動化されたテストが行​​われるために時間がかかるビルド) には、マトリックス プロジェクトが適しています。その主な利点は「1 つの変更点」です。同じ変更をビルドに導入するために複数のジョブを編集する必要はありません。もちろん、これはブランチ間でジョブのバリエーションがほとんどない場合にのみ機能します (ちなみに、そのバリエーションは多くの場合、Run Condition Pluginでうまく処理できます)。

この場合、マルチ構成プロジェクトはおそらく配信ビルドに最適ではありません (配信ビルドは、開発者がリポジトリにコミットして変更が適切に統合されていることを確認するときに実行されます)。その理由は、トランクにコミットする場合、トランクのみを構築したいのですが、マトリックス ビルドではすべてが構築される (コンピューティング リソースと時間が消費される) ためです。

デリバリー ビルドの場合は、パラメーター化されたビルドを使用します。メイン パラメーターはビルドするブランチになります。そのビルドは、SVN フックによってトリガーできます (このドキュメントを参照してください)。または、( Subversion プラグインを介して) ブランチをポーリングするすべてのブランチごとにトリガー ビルドを関連付け、Parameterized Trigger プラグインを介して適切なパラメーターでメイン ビルドをトリガーすることもできます。

ところで、私は実際に上記のすべてのアプローチを使用しています (SVN フックを除いて、完全に技術的な理由ではありません)。

于 2012-06-05T19:42:08.380 に答える
3

構築するブランチ/タグごとに 1 つずつ、複数のジョブを設定します。1 つのジョブが正常に動作するようになったら、それをコピーして残りのジョブを作成し、SVN URL だけを変更できます。

また、Jenkins の構成が制御不能にならないように、これらのタグ/ブランチの維持を停止するときに、古いジョブを削除する必要があります。

于 2012-06-05T19:32:59.977 に答える