ジャズSCM継続的インテグレーション - ストリームとワークスペースの構築？

Question

私は、Rational Team Concert（RTC）IDEとJazzビルド・エンジンを使用して、Spring Rooアプリケーション用の継続的な統合ビルドをセットアップ中です。ビルド定義をセットアップするときは、「Jazz Source Control」タブの「Build Workspace」フィールドで、ユーザーのリポジトリー・ワークスペースまたはストリームのいずれかを選択できます。

RTC Continuous Integration Best Practicesや他のジャズのリソースが一貫し、これは好ましいアプローチであると信じて私をリードし、ビルドのユーザーに関連付けられた専用のリポジトリー・ワークスペースを使用して参照してください構築。ストリームから直接ビルドに関する情報を見つけることができませんでした。私たちのプロジェクトのストリームには、ビルドに必要なすべての成果物が含まれています。私は、継続的な統合ビルドがストリームから機能することをテストして確認しました。私はこの目的のために特定のワークスペースを作成して管理する必要がある理由を考えることができません。

私の質問は、ストリームから直接ビルドすることで火を放っていますか？私が気付いていないこのアプローチに潜在的な下流の合併症はありますか？

Answer 1

今後別のSOユーザーに同じ質問がある場合は、自分の質問に回答してください。

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

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

Answer 2

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

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

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

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

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

ここでのオプションとそのメリットの詳細については、私のブログ記事とジャズパフォーマンスに関するホワイトペーパー（http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a-guide-to-better-performance/）を参照してください。その記事は今ではほぼ一年経っていますが、依然として有効です。また、Jazz Deployment Wiki（https://jazz.net/wiki/bin/view/Deployment/WebHome）を見て、パフォーマンスのトラブルシューティングとパフォーマンス上の問題のセクションをチェックすることもできます。