ビルド トリガーと理由の指定

  • [アーティクル]

更新 : 2011 年 5 月

必要な場合はいつでも手動でビルドをキューに配置できますが、チームのニーズに最もよく合うのは、ほとんどの場合、自動トリガーを使用して定義されたビルド処理です。 ビルドがトリガーされると、特定の理由が Reason プロパティに記録されます。 このトピックでは、ビルド処理を開発するときに、使用可能なすべてのビルドのトリガーとビルドの理由を使用する方法について説明します。

  • ビルド トリガーを使用してチームの目標を達成する

    • ビルド ブレークからチームを保護する

    • 継続的インテグレーションを使用して品質を維持する

    • BVT を毎晩実行することで製品の品質をチェックする

  • 自動ビルド トリガーを使用する

    • 変更がチェックインされたときに継続的インテグレーション トリガーを使用してビルドをキューに配置する

    • 変更がチェックインされたがビルドの実行頻度に制限があるときにビルドのロール トリガーを使用してビルドをキューに配置する

    • チーム メンバーが変更をチェックインしようとする際、また、ビルドに失敗した場合に変更をブロックしようとする際にゲート チェックイン トリガーを使用してビルドをキューに配置する

    • スケジュール トリガーを使用してビルドを定期的にキューに配置する

  • ビルドを手動でキューに配置する

    • ビルドをキューに配置する

    • プライベート ビルドをキューに配置する

  • カスタム コードを使用して完了したビルドを作成する

  • ビルドのトリガーと理由を使用する

ビルド トリガーを使用してチームの目標を達成する

ビルド ブレークからチームを保護する

開発者が変更をチェックインしたことでビルドが中断された場合、小規模のチームにとってそれは大きな負担となります。 また、大規模なチームにとっては、生産性の低下とスケジュールの遅延の点から、コストが増大する可能性があります。 ゲート チェックイン トリガーを使用して、このような問題に対してコード ベースの一部またはすべてを保護することができます。

継続的インテグレーションを使用して品質を維持する

継続的インテグレーションとは、共有リポジトリにコードを統合する回数をできる限り増やすというプロセスです。 コードの統合時に、ビルド ブレークまたはテストの失敗を通じて、コードのエラーを適時に認識することができます。 継続的インテグレーション トリガーを使用して、継続的インテグレーションを実装できます。 ビルドのロール トリガーは、継続的インテグレーション トリガーと似ており、チェックインが発生するたびにビルドを実行できるほど強力なビルド システムがない場合に役立ちます。

ゲート チェックイン トリガーは、継続的インテグレーションへの厳密なアプローチとして機能します。 継続的インテグレーション トリガーは、ビルド ブレークや失敗したコア単体テストなどの問題についてチームに警告しますが、ゲート チェックイン トリガーはこのような種類の問題をブロックしてコードベースに入らないようにします。

ビルド システムを使用して継続的インテグレーションをサポートする方法の詳細については、「連続的なビルドおよび配置」を参照してください。

BVT を毎晩実行することで製品の品質をチェックする

定期的なテスト実行をスケジュールして、ビルドの品質を評価できます。 これらのテストは、多くの場合、ビルド確認テスト (BVT: Build Verification Test) またはスモーク テストと呼ばれます。 通常これらのテストは、特定のビルドでアプリケーションの主要な区分を検証するために使用されるテストの幅広いスイートから構成されます。 スケジュール トリガーを使用して、毎晩の BVT 実行を実装できます。

スケジュール トリガーについては、「スケジュール トリガーを使用してビルドを定期的にキューに配置する」を参照してください。 BVT 処理を設定する方法の詳細については、「方法: アプリケーションのビルド後にスケジュールされているテストを構成および実行する」を参照してください。

自動ビルド トリガーを使用する

ビルド定義には、ビルド トリガーを指定する必要があります。 ほとんどの場合、ビルド処理は自動的に実行します。 このセクションで説明する自動トリガーのいずれかを選択できます。

変更がチェックインされたときに継続的インテグレーション トリガーを使用してビルドをキューに配置する

継続的インテグレーション トリガーを使用してビルドを定義すると、チーム メンバーが変更をチェックインするたびにビルドがキューに配置されます。 ビルド定義のワークスペースにより、ビルド定義をトリガーするファイルが決まります。 ビルド ワークスペースの詳細については、「ビルド ワークスペースの使用」を参照してください。

継続的インテグレーションによりトリガーされたビルドには IndividualCI の Reason が割り当てられます。

変更がチェックインされたがビルドの実行頻度に制限があるときにビルドのロール トリガーを使用してビルドをキューに配置する

ビルドのロール トリガーを使用してビルドを定義すると、変更がチェックインされたときにビルドがキューに配置されますが、次の制限が適用されます。

  • このビルド定義のビルドが既に実行されている場合、追加のビルドはキューに配置されません。

  • [最小ビルド間隔 n 分] チェック ボックスをオンにし、0 ～ 2147483647 の整数値を入力した場合、ビルドの頻度をさらに制限できます。

ビルド定義のワークスペースにより、ビルド定義をトリガーするファイルが決まります。 ビルド ワークスペースの詳細については、「ビルド ワークスペースの使用」を参照してください。

ビルドのロールによりトリガーされたビルドには BatchedCI の Reason が割り当てられます。

チーム メンバーが変更をチェックインしようとする際、また、ビルドに失敗した場合に変更をブロックしようとする際にゲート チェックイン トリガーを使用してビルドをキューに配置する

ゲート チェックイン トリガーを使用してビルドを定義すると、チーム メンバーがバージョン管理システムに提出した変更がシェルブセットに置かれ、ビルド対象としてキューに配置されます。 ビルドを完成させるには、正常にチェックイン プロセスを経由する必要があります。 ビルド定義のワークスペースにより、ビルド定義により制御されるファイルが決まります。 ビルド ワークスペースの詳細については、「ビルド ワークスペースの使用」を参照してください。

ゲート チェックインによりトリガーされたビルドには CheckInShelveset の Reason が割り当てられます。

ゲート チェックイン トリガーを実装する方法の詳細については、「ゲート チェックイン ビルドの定義と変更内容の検証」を参照してください。 この種類のビルド定義がチームに与える影響の詳細については、「ゲート チェックイン ビルドによって制御されている保留中の変更内容のチェックイン」を参照してください。

スケジュール トリガーを使用してビルドを定期的にキューに配置する

スケジュール トリガー

スケジュール トリガーを使用してビルドを定義し、[前回のビルドから何も変更されていなくてもビルドを実行する] チェック ボックスをオフにすると、このビルド定義の直近の実行以降変更がチェックインされている場合、指定した日時にビルドがキューに配置されます。 ビルドは、前回成功したビルドと変更が関連付けられているかどうかに関係なくキューに配置されます。

この方法でトリガーされたビルドには、Schedule の Reason が割り当てられます。

ヒント

カスタム ビルド処理テンプレートを開発していて、テンプレートの 理由 (トリガー) に基づいてビルド処理のセクションを制限する (InvokeForReason アクティビティ) セクションの Reason プロパティで値として Schedule を選択する際、ほとんどの場合 ScheduleForced も選択する必要があります。

スケジュール トリガー (Reason: ScheduleForced)

スケジュール トリガーを使用してビルドを定義し、[前回のビルドから何も変更されていなくてもビルドを実行する] チェック ボックスをオンにすると、指定した日時にビルドがキューに配置されます。 ビルドは、変更がチェックインされたかどうかに関係なくキューに配置されます。

この方法でトリガーされたビルドには、ScheduleForced の Reason が割り当てられます。

ヒント

カスタム ビルド処理テンプレートを開発していて、テンプレートの 理由 (トリガー) に基づいてビルド処理のセクションを制限する (InvokeForReason アクティビティ) セクションの Reason プロパティで値として ScheduleForced を選択する際、ほとんどの場合 Schedule も選択する必要があります。

ビルドを手動でキューに配置する

特定の状況においては、ビルド処理を自動的に実行したくない場合があります。

  • ビルド定義が開発中のため、自動実行の準備ができていない。

  • 手動でのみ実行したい特殊なビルド処理がある。

このような状況では、手動トリガーを選択できます。 ビルド定義は、チーム メンバーが手動でキューに配置したときのみ実行できます。

ビルドをキューに配置する

手動以外のビルド トリガーが定義されている場合でも、ビルド定義を手動でキューに配置することができます。 ビルドを手動でキューに配置すると、Reason が Manual に設定されます。 ビルドを手動でキューに配置する方法の詳細については、「ビルドをキューに配置する」を参照してください。

プライベート ビルドをキューに配置する

シェルブセットに加えた変更をビルドする場合、プライベート ビルド ("関連ビルド" とも呼ばれます) を使用して、チェックイン前にコードの変更を検証できます。 プライベート ビルドを手動でキューに配置すると、Reason が ValidateShelveset に設定されます。 プライベート ビルドをキューに配置する方法の詳細については、「ビルドをキューに配置する」を参照してください。

カスタム コードを使用して完了したビルドを作成する

Microsoft.TeamFoundation.Build 名前空間でクラスを使用することで、完了したビルドを作成するカスタム コードを開発できます。 ビルドをこの方法でキューに配置すると、Reason が UserCreated に設定されます。 詳細については、「Extending Team Foundation: Build」を参照してください。

ビルドのトリガーと理由を使用する

ビルド処理では、次の方法でトリガーと理由を使用できます。

履歴の変更

日付

履歴

理由

2011 年 5 月

トピックを追加

情報の拡充