3

私は、Rational Team Concert（RTC）IDEとJazzビルドエンジンを使用して、SpringRooアプリケーションの継続的インテグレーションビルドをセットアップしているところです。ビルド定義を設定する場合、[Jazzソース管理]タブの[ビルドワークスペース]フィールドで、ユーザーのリポジトリワークスペースまたはストリームのいずれかを選択できます。

RTC継続的インテグレーションのベストプラクティスおよびその他のJazzビルドリソースは、ビルドユーザーに関連付けられた専用のリポジトリワークスペースの使用を一貫して参照しているため、これが推奨されるアプローチであると私は信じています。ストリームから直接構築に関する情報を見つけることができませんでした。プロジェクトのストリームには、ビルドに必要なすべてのアーティファクトが含まれています。継続的インテグレーションビルドがストリームから機能することをテストして確認しました。この目的のために特定のワークスペースを作成して管理する必要がある理由を考えることはできません。

私の質問は、私は小川から直接建物を建てて火遊びをしているのですか？私が気付いていないこのアプローチの潜在的な下流の合併症はありますか？

4

2 に答える 2

5

将来、別のSOユーザーが同じ質問をした場合に備えて、自分の質問に答えます。

いくつかの実験の結果、ストリームから直接ビルドすることの欠点は、JazzSourceControlタブの「変更が受け入れられた場合にのみビルドする」プロパティを無視することであることがわかりました。その結果、ストリームからのビルドは事前定義された間隔でのみ実行できます。新しい変更がストリームにコミットされたときにのみ実行されるようにビルドを構成することはできません。

ビルドがストリームからの新しい変更を受け入れ、それらを使用してビルド要求をトリガーするには、専用のワークスペースが必要です。

于 2010-11-30T20:59:20.197 に答える
1

ここにはもう1つの大きな違いがあります。それは、ビルドがどのように行われるかと関係があります。ここで違いを強調しておきましょう。

専用のビルドリポジトリワークスペースからビルドする場合、ビルドワークスペースにはすでにすべてのコードのコピーがあります。変更が配信され、ビルドが開始されると、変更されたファイル（変更セット）のみを更新して、リポジトリからビルドリポジトリワークスペースに物理的にコピーする必要があります。ほとんどの変更は小さいため、これには、リポジトリからコードベースの0.1％から2％の範囲のコピーが含まれます。

「ストリーム」からビルドする場合は、ビルドワークスペースを作成する必要があります（どこかでコンパイルする必要があります！）。したがって、これを作成するときは、コードベース全体を更新して、リポジトリからビルドリポジトリワークスペースに物理的にコピーする必要があります。これは、リポジトリからコードベースを100％取得することを意味します。

各ファイル操作には、必要なリソースを検出するための呼び出しが含まれ、リポジトリをホストしているデータベースからこのリソースをフェッチしてから、Jazzアプリケーションにネットワーク経由でこのソースファイルを提供させます。その結果、データベースサーバー、Webサーバー、およびアプリケーションサーバーに負荷がかかります。このようにダウンロードすればするほど、これらのコンポーネントにかかる負荷は大きくなります。

Jazzインフラストラクチャのこの負荷を最小限に抑えるために使用できるものがいくつかあります。コンテンツキャッシングプロキシを使用する（単純なSquidプロキシサーバーを使用する）と役立ちます。

ここでのオプションの詳細と、それらのオプションの相対的なメリットについては、私のブログ投稿とJazz Performanceの懸念に関するホワイトペーパー（http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a ）を参照してください。 -guide-to-better-performance /）。その記事はもう1年近く経っていますが、まだ有効です。また、Jazz Deployment Wiki（https://jazz.net/wiki/bin/view/Deployment/WebHome）を参照して、パフォーマンスのトラブルシューティングとパフォーマンスの問題に関するセクションを確認することもできます。

于 2013-10-30T13:46:16.787 に答える