ビルドとテストの失敗への対応
ビルドの実行中、通常、次のいずれかの種類の障害が発生する可能性があります。
テスト失敗 - ビルド中に試行されたユニットテストまたは機能テストの失敗。
ビルド問題 - ビルド中に発生したその他の問題: リモートリポジトリにアクセスできない、ビルドアーティファクトの取得またはアップロードに失敗する、コンパイルエラーなど。
ビルドの問題を表示
TeamCity では、ビルドの問題を検出して調査する方法が複数あります。
ビルド結果ページ
ビルド結果ページ には、この個々のビルド実行に関する最も詳細な情報が表示されます。 概要 タブには、この実行中に発生したビルドとテストの問題の概要を示す展開可能なセクションが表示されます。
ビルドの問題が初めて発生すると、ビルドのステータスメッセージに「(新規)」が追加されます。 これにより、ビルド履歴をスクロールするときに、固有の問題と繰り返し発生する問題をすばやく区別できます。
任意の問題をクリックすると、この課題に対応する ビルドログの一部を表示できます。
失敗したテストでは、 現在の失敗/最初の失敗 トグルも表示され、繰り返し発生する問題が最初に発生したビルドにすばやく移動できます。
新しいビルドが同じテストに失敗することなく完了しているのに、古いビルドの結果を表示している場合、失敗は取り消し線で表示されます。 この場合、この新しいビルドを指す すでに修正済み タブが表示されます。
テストのステータスが失敗から成功へ、またその逆へと頻繁に変わる場合、TeamCity はそのテストを 不安定 としてマークします。 詳細については、専用の 不安定なテスト セクションを参照してください。
問題タブ
プロジェクトの 問題 タブには、子サブプロジェクトの問題も含め、現在アクティブなすべてのビルドの問題の概要が表示されます。
このページでは、ビルドとテストの失敗を切り替えたり、問題を状態別にフィルタリングしたりできます。
ビルドの問題とテスト失敗を管理
TeamCity の問題管理機能は、調査とミュートという二つの基本概念を中心に展開されます。
調査
調査済み 問題とは、TeamCity ユーザーが割り当てられている問題です。 これらのユーザーは、対応するビルドの問題やテストの失敗を修正する責任があります。
ユーザーには、割り当てられた調査の合計数が TeamCity ヘッダーに表示されます。 この UI 要素をクリックすると、 自分の調査 ページが開き、これらの調査の詳細情報を表示できます。
TeamCity は、調査中の問題を可視化するために警察官アイコンを表示します。 このアイコンの上にマウスを置くと、問題に関する詳細情報が表示され、ユーザーは問題を再割り当てしたり、手動で修正済みとしてラベル付けしたりできます。
ユーザーが調査を修正済みとしてマークすると、アイコンの色が緑に変わります。 このアイコンは、同じ問題が発生することなく新しい実行が終了するまで表示されたままになります。
問題のステータスを手動で "Fixed" に設定すると、TeamCity ヘッダーのユーザーの調査カウンターは減りますが、問題が引き続き発生する場合、新しいビルドの失敗を防ぐことはできません。 TeamCity にこの問題を無視させたい場合は、修正済みとしてラベル付けするのではなく、 ミュートします。
TeamCity は問題の調査を自動的に作成し、これらの失敗の原因である可能性が最も高いユーザーに割り当てることができます。 これを行うには、 調査の自動割り当て ビルド機能を構成します。
ミュート
ミュート済み 問題とは、ビルドが正常終了を報告することを妨げない問題です。 ミュートされた問題が原因で失敗したビルドは、正常に終了したと表示され、ミュートされた問題の数が表示されます。
ビルドの問題またはテストをミュートすると、解決されると予想される既知の問題を一時的に無視したり、失敗すると予想されるテストを無視したり、ビルドで問題が発生した場合でも後続のステップまたは ビルドチェーン 構成が実行されるようにしたりできます。
TeamCity は、ミュートされた問題を可視化するためにスピーカーアイコンを表示します。 このアイコンの上にマウスを置くと、この問題に関する詳細情報が表示されます。
失敗したテストのミュート
テストのミュートは、「少なくとも 1 つのテストが失敗しました」 ビルド失敗条件で失敗するビルドにのみ影響し、他の条件には影響しません。 ビルドに他の失敗条件 (たとえば、ゼロ以外の終了コード) が適用される場合、失敗したテストがミュートされていてもビルドは失敗します。
失敗したがミュートされたテストがあるときにビルドを成功させるために、ビルドスクリプトを調整する必要がある場合があります。 発生したエラーがテストの失敗のみであった場合は、他のビルド障害条件（たとえば、 「ビルドプロセスの終了コードがゼロでない場合は失敗します」 ）のためにビルドが失敗しないことを確認してください。 詳細については、関連する問題 TW-16784(英語) を参照してください。
アクティブな問題を管理
ビルド結果ページ と 問題タブ の両方に、ユーザーが問題をミュート、ミュート解除、調査、修正済みとしてマーク、別のユーザーに再割り当てできる UI 要素が表示されます。 複数の問題に同じアクションを一度に適用するには、 問題 タブに移動して必要なエントリを選択します。
調査とミュートを編集する場合、TeamCity では次の設定を指定できます：
調査 / ミュート範囲。 同じプロジェクト内のすべての構成 (その子サブプロジェクトを含む) に属するビルドでこの問題をミュート / 調査するには、「プロジェクト全体」を選択します。 「選択したビルド構成」オプションを使用すると、必要な構成に対してのみ問題をミュート / 調査できます。
調査と担当者。 ミュートされた問題は、失敗したビルドが成功したように見え、根本的な問題が見えにくくなる可能性があります。 そのため、ミュートと調査を組み合わせて、誰も調査していない問題をミュートしたままにしないようにすることをお勧めします。
自動ミュート解除 / 解決ポリシー。 TeamCity が問題のミュートを解除する、または修正済みとしてマークする条件を指定できます。
修正時に自動的に— 問題が新しいビルドで解決された場合、TeamCity はミュートを解除し、関連する調査を終了します。 これは、今後のビルドで問題が再発した場合にチームが迅速に対応できるようにするデフォルトのシナリオです。"fixed" の問題は、ステータスが手動で変更された問題 (調査 セクションを参照)、または新しいビルドで解消された問題です。 ブランチとの関係 も参照してください。
手動で— アクティブな調査を終了し、ミュートを取り消せるのは TeamCity ユーザーのみです。 これらのテストは不安定で、実行が成功しても問題が解決されたことを保証できないため、このモードは 不安定なテストのミュート/調査に推奨されます。特定の日付に— TeamCity は、指定された日付に調査を終了するか、問題のミュートを解除します。 この条件は、チームがすぐに修正できないが、CI ルーチンを実行し続ける必要がある、重大ではない問題に役立ちます。
設定を子サブプロジェクトにコピーします。 このプロジェクトとその子サブプロジェクトに存在する調査/ミュートを編集する場合、TeamCity では更新した設定をこれらのサブプロジェクトに伝播するかどうかを選択できます。 そうしない場合、子サブプロジェクトの調査/ミュートは異なるものになります (たとえば、別のユーザーに割り当てられるなど)。
必要な権限
プロジェクト内の調査 / ミュートを管理および表示するには、ユーザーにこのプロジェクトで次の権限が付与されている必要があります。
ミュートを管理するための「プロジェクト内のミュート / ミュート解除の問題」
調査を管理するための「調査の割り当て / 割り当て解除」
既存の調査 / ミュートを表示するための「プロジェクトとすべての親プロジェクトを表示」
これらの権限は、デフォルトでプロジェクト管理者とシステム管理者に付与されます。
ブランチとの関係
調査とミュートはブランチ固有のものではありません。 問題が調査またはミュートされると、その問題が現れるすべてのブランチに対して調査 / ミュートされます。 ただし、TeamCity はブランチ固有のビルドをチェックして、問題が修正されたかどうかを判断します。 これは、「修正時に自動的に」ミュート解除 / 調査終了条件の問題の処理方法に影響します。
複数のブランチで障害が発生し、そのうちの 1 つがデフォルトのブランチである場合、デフォルトのブランチで障害が解消されると問題は解決されたとみなされます。
デフォルト以外のアクティブなブランチのみで障害が発生した場合、これらすべてのブランチで障害が解消されると問題は解決されたとみなされます。
不安定なテスト
不安定なテストとは、ビルド実行間で違いがないように見える、成功または失敗の両方で終了する可能性のある不安定なテストです。 TeamCity は、次のいずれかに該当する場合、テストを不安定と見なします：
テストのフリップレートが高い場合。 フリップとは、テストのステータスが成功から失敗に、またはその逆に変わる 1 回の発生です。 TeamCity は、指定されたテストの合計呼び出し回数に対するこのようなフリップの比率を計算します。 この比率は、エージェントごと、ビルド構成ごと、または特定の期間 (デフォルトでは 7 日間) にわたって測定されます。 常に失敗または成功するテストのフリップレートは 0 に近くなります。 呼び出されるたびに「フリップ」するテストのフリップレートは 100% に近くなります。
基礎となるコードの変更なしに反転されたテスト。 同じリビジョンを処理した前回のビルド実行と比べて、テストが反対のステータスで終了した場合 (つまり、新しい変更が処理されていない場合)、TeamCity はこのテストを不安定と見なします。
1 つのビルド中に複数回呼び出されたテストが、異なるステータスで終了しました。 このヒューリスティックは、
呼び出し回数が 1 より大きい TestNG(英語) ユニットテストと、 テスト再試行回数 が 0 より大きい .NET ランナーによって実行されるテストでサポートされます。
次の場合、テストは不安定であるとはみなされません。
同じ VCS 変更に対して、異なる構成の複数のビルドが実行され、これらのビルド間でテスト結果が異なります。 このような結果は、環境の問題によって発生する可能性が最も高くなります。
VCS ルートには ブランチが設定されており、テストによってデフォルト以外のブランチが反転します。
TeamCity は、不安定なテストを テスト タブ（ビルド結果ページ ）に表示します…
... そして親プロジェクトの 不安定なテスト ページにあります。
JUnit(英語) テストの場合、サードパーティの tempus-fugit(英語) ライブラリを JUnit と一緒に使用できます。 以下の最小例のように、 @断続的 でテストにアノテーションを付け、 断続的テストランナー テストランナーを使用するだけで十分です。
このようなテストが 1 つのビルド内の複数の呼び出しで少なくとも 1 回フレークすると、 フレーク故障ヒューリスティックがトリガーされます。
失敗したテストと同様に、不安定なテスト (または複数のテスト) に調査を割り当てることができます。 不安定なテストでは、解決メソッドが自動的に "Manual" に設定されます。それ以外の場合、テストが成功すると調査は自動的に除去されますが、これは不安定なテストが修正されたことを意味しません。