統合ビルド中は、新しく完了した開発者のすべてのタスクが収集されてビルドされます。これらのタスクは、統合テスト・プロジェクト階層によって使用される統合テスト・プロセス・ルールに基づいて収集されます。
このタスクについて
統合テスト・サイクルでは以下の事象が発生します。
統合テスト・サイクル中にソフトウェアに問題が発生する可能性があり、正しくビルドできないことがあります。目的は問題を直ちに見つけることであって、高品質なインストール域を得ることではありません。開発サイクルではソフトウェアは不安定な性質を持つため、安定度を高めることはここでは目的ではありません。
以下に、統合レベルのビルド中に発生する可能性のある問題のタイプを示します。
- マージされないパラレル分岐 (ある開発者から変更を受け取るが、別の開発者からは受け取らない)
- 開発者が変更の一部をチェックインした (例えば、特定のタスクを完了するために必要な一部のオブジェクトを開発者が関連付けし忘れた)。
- 2 人の開発者が両立しない変更を行った (例えば、両者が同じ名前の定義を追加した)。
- プログラムが構文エラーのためコンパイルに失敗した (例えば、開発者が単体テストをし忘れた)。
統合ビルド域は、最近完了したタスクが含まれるため、安定した環境ではありません。別の理由として、開発者がタスクを完了するたびに、候補が頻繁に変更されるということがあります この不安定さが標準となります。
統合テスト・サイクルは短く頻繁なため、開発サイクルのできるだけ早期に問題を見つけるのに役立ちます。
また、個別開発プロジェクトを担当する開発者は、タスクが統合テストをパスするまでは、外部の個々の変更内容を取り込みません。
統合サイクルは、ビルドとテストを毎日実行できる場合に最もよく機能します。新しくテストされたタスクがテストをパスした直後に、タスクが開発者に使用できるようにします。
通常、統合レベルのビルド・サイクルでは以下を行います。
- 開発者はサイクルに関係なく、タスクを完了することによって継続的にオブジェクトを変更してチェックインします
(この利点は、テストによってチームの作業が中断されたり気をそらされたりしないことです)。
- ビルド・マネージャーは更新を行い、コンフリクトを表示し、コンフリクトを解決し、階層を構築し、テスト対象となるインストール域またはメディアを作成します (この処理の一部は自動化して夜間ジョブとして実行できます)。
- ビルド・マネージャーは、結果のプロダクトが正しくビルドされて使用可能であることを検査する短いテスト・セットを使用して、プロダクトをテストします。不具合が検出された場合、チームのメンバーは問題を修正するためのタスクを作成します。
- 重大な不具合が検出されない場合、アプリケーションは (例えば開発テスト域として) すぐに使用できます。このサイクルは毎日発生しないことがあります。重大な不具合が検出された日には、ビルドに成功しないことがあります。
- ビルド・マネージャーが重大な不具合を検出しなかった場合、プロセスはベースラインの作成に進みます。ベースラインのおかげで、開発者が次回プロジェクトを更新するとき、ベースライン内のタスクに関連付けられたオブジェクトを開発者が使用できるようになります。
統合テスト・サイクル中に実行するタスクと、これらの操作の実行が必要な理由が理解できたら、操作をすぐに実行することができます。