事前テスト済み（遅延）コミット

マッチングの変更とビルド構成

変更されたファイルを事前テスト済みのコミットまたはリモートの実行に送信するには、VCS 統合が IDE で機能し、TeamCity がコミットされたときにファイルがサーバー上のビルド構成に影響を与えることを確認できます。

TeamCity が変更をビルドと一致させることができない場合は、「送信された変更をビルド構成に適用することはできません」というメッセージが表示されます。

VCS 統合は IDE で正しく設定され、TeamCity は開発者ワークステーション上のファイルを TeamCity サーバー上に存在するビルド設定と一致させることができるはずです。それを可能にするために、VCS は開発者のワークステーションとサーバーで同じ方法で設定されるべきです。

これも:

• CVS、TFS、Perforce バージョン管理システムの場合 — バージョン管理サーバーに対してまったく同じ URL を使用します。

• VSS の場合 — VSS データベースへのまったく同じパス（マシンとパス）を使用します。

• Subversion の場合 — 同じサーバーを使用します（TeamCity はサーバー UUID(英語) と一致します）。

• Git の場合 — 現在チェックアウトされているブランチには、TeamCity サーバーによって監視されているサーバー / ブランチに「リモート」が設定されており、サーバーで監視されているブランチとの履歴に共通のコミットがある必要があります。

ファイルを変更しても TeamCity を選択してもファイルの送信先のビルド構成が見つからない場合は、個人用ビルドを開始するオプションは利用できません。

事前にテストされたコミットの一般的な Flow

• 開発者は TeamCity IDE プラグインのリモート実行ダイアログを使用して TeamCity に送信するファイルを選択します。

• 選択したファイルに基づいて、適用可能なビルド構成のリストが表示されます。開発者はビルド構成を選択して変更をテストし、事前テスト済みコミットのオプションを設定します。

• TeamCity IDE プラグインは、選択されたすべてのファイルの完全な内容である「パッチ」を作成し、それを TeamCity サーバーに送信します。パッチは開発者のマシン上にローカルに保存されます。送信されると、変更は開発者の変更ページに表示されます。開発者はコードでの作業を続行し、事前テスト済みのコミットに送信されたファイルを変更できます。

• パーソナルビルドはキューに入れられ、他のキューに入れられたビルドと同様に処理されます。

• ビルドが開始されると、通常のビルドと同じように最新のソースがチェックアウトされ、その後 IDE から送信された開発者の個人的な変更が適用されます。(全ファイルコンテンツが使用されます)

• ビルドは通常どおり実行されます

• ビルドの終わりに、個人的な変更はビルドのチェックアウトディレクトリから元に戻され、それが後続のビルドに影響しないようにします。

• TeamCity IDE プラグインは TeamCity サーバーに ping を実行して、選択されたすべてのビルド構成に個人用ビルドが用意されているかどうかを確認します。ビルドが失敗すると、通知が IDE に表示され、プロセスは終了します。

• すべての個人用ビルドが正常に終了すると、IDE プラグインは進行状況を表示し、個人用変更に参加しているファイルの現在のバージョンをバックアップし (事前テストされたコミットが開始されてからすでに変更されている可能性があるため)、ファイルの内容を復元します。保存された「パッチ」からバージョン管理コミットを実行し (VCS の競合などのエラーがあった場合はエラーを報告します)、バックアップしたばかりのファイルを復元して、作業コピーを最後に確認された状態にします。TeamCity プラグインウィンドウで事前にテストされたコミットには、エラーまたは成功マークが付けられます。