クリーンアップ
TeamCity のクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。
サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。
特定のプロジェクトに関連するクリーンアップルールは、プロジェクト設定 | クリーンアップ規則で構成されます。これらのルールは、どのデータをクリーンアップし、何を保存するかを定義します。これらは、プロジェクトまたはビルド構成に割り当てることができます。
クリーンアップルールを構成して、廃止されたビルドとそのアーティファクトを削除し、データベースとキャッシュから不要なデータを削除して、ディスクスペースを解放し、TeamCity UI からビルドを削除し、TeamCity のワークロードを減らすことをお勧めします。
クリーンアップにより、<TeamCity Data Directory>/system
およびデータベースに保存されているデータが削除されます。また、クリーンアップ中に、サーバーはさまざまなメンテナンスタスクを実行します(たとえば、VCS フルパッチキャッシュをリセットします)。
サーバーのクリーンアップ設定
サーバーのクリーンアップ設定は管理 | サーバー管理 | クリーンアップ設定で構成されます。
ビルド履歴のクリーンアップはバックグラウンドプロセスとして実行されます。つまり、サーバーメンテナンスのダウンタイムはありません。
クリーンアップするデータの量によっては、プロセスにかなりの時間がかかる場合があり、その間、サーバーのパフォーマンスが低下する可能性があります。オフピーク時間にクリーンアップをスケジュールすることをお勧めします。デフォルトでは、TeamCity は 3:00 AM で毎日クリーンアップを開始します。毎日の開始時刻を変更したり、カスタム cron 式を構成して、必要な規則でクリーンアップを開始したりできます。
手動でクリーンアップを開始するも可能です。
クリーンアッププロセスの制限時間も指定できます。指定した時間枠内にすべてのデータがパージされない場合、残りのデータは次のクリーンアッププロセス中に削除されます。
クリーンアップが有効になっていると、TeamCity はデフォルトで 1 年間(365 日)サーバー監査レコードを保存します。
手動クリーンアップ起動
サーバーのクリーンアップ設定の前回のクリーンアップセクションでは、以下のことが可能です。
以前のサーバークリーンアップの日付と期間に関する情報を確認して、特定のタイミングでクリーンアッププロセスを開始するかどうかを判断します。
今すぐクリーンアップを開始ボタンを使用して、手動でクリーンアップを実行します。
クリーンアップ中に、TeamCity は進行状況を報告します。必要に応じて、クリーンアッププロセスを停止できます。残りのデータは、次のクリーンアップ中に削除されます。
クリーンアップ規則
クリーンアップルールは、現在のプロジェクト、そのサブプロジェクト、ビルド構成のデータをクリーンアップする方法を定義します。
プロジェクト設定のクリーンアップ規則ページでは、現在のプロジェクトとそのビルド構成のクリーンアップルールを表示および管理できます。このプロジェクトにサブプロジェクトがある場合は、オプションでそれらのルールも表示できます。
プロジェクトのクリーンアップルールには 2 つのタイプがあります。
基本ルールは、どのデータをいつ削除するかを定義します。これらは構成が簡単で、最も一般的なクリーンアップケースをカバーします。各プロジェクトとビルド構成に 1 つの基本ルールが割り当てられます。基本ルールの構成方法を読む。
キープルールは、クリーンアップ中に保持するデータを定義します。それらは非常に柔軟性がありますが、基本ルールよりも構成に多くの労力を要します。プロジェクトまたはビルド構成に複数の保持ルールを割り当てることができます。キープルールの構成方法を読む。
キープルールはよりきめ細かく、すべてのビルドを特定のタグ(たとえば、release
)または特定のブランチで保持するなどのケースをカバーできます。キープルールを使用するには、さまざまな種類のビルドとそのデータをよりよく理解する必要がありますが、柔軟性も向上します。
基本ルールを設定して一般的なクリーンアップシナリオを構成し、複数の保持ルールを追加して、保持する正確なデータを調整できます。または、保持ルールのみに依存してクリーンアップロジックを構成することもできますが、基本ルールを無効にする前に、それらがすべての貴重なデータを保持していることを確認してください。
クリーンアップ中に、TeamCity はベースルールとキープルールを分析および結合して、保存および削除するデータの範囲を決定します。
プロジェクトに割り当てられたクリーンアップルールは、そのすべてのサブプロジェクトとビルド構成によって継承されますが、独自のルールによってオーバーライドできます。次の図は、サンプルプロジェクト A 全体にルールがどのように伝播するかを示しています。
オーバーライドされたルールは、親プロジェクトの階層内で最も近い元の定義にいつでもリセットできます。
基本ルール
単一の基本ルールが各プロジェクトまたはビルド構成に割り当てられます。基本ルールを使用すると、保存するビルドの成功数、および / またはビルドを履歴に保持する期間を定義できます。
基本ルールでは、次のクリーンアップレベルを使用できます。
アーティファクト : ビルドログを含むすべてのデータが保持されます。隠されたアーティファクトも保持されます。
履歴 : 統計チャートに表示されるビルド統計値を除いて、すべてのビルドデータが削除されます。
すべて :TeamCity にはビルドデータが残っていません。
各レベルには、その上のリストが含まれます。
デフォルトでは、すべてが永久に保持されます。カスタム設定を選択すると、上記の各レベルで次を指定できます。
日数 :
指定された日数より古いビルドは、指定されたレベルでクリーニングされます。開始点は、現在の日付ではなく、最後に成功したビルドビルドの日付です。1 日は、暦日ではなく、24 時間に相当します。成功したビルドの数 :
最後に一致した成功したビルドより古いビルドのみが指定されたレベルでクリーンアップされます(保存された成功したビルド間のすべての失敗したビルドが保持されます)。
両方の条件が指定されている場合、適用されたすべてのルールに従ってクリーンアップする必要があり、キープルールによって保持されないビルドのみが実際に削除されます。TeamCity は、各ルールに従って保持する最も古いビルドを見つけて、古いビルドをすべてクリーンアップします。見つかった 2 つのうち最も古いものよりも。
成功したビルドの数の制限がレベルに指定されているが、履歴に成功したビルドがない場合、TeamCity はこのレベルのデータをクリーンアップしないことに注意してください。
アーティファクトレベルでは、アーティファクト名のパターンを指定することもできます。指定したパターンに一致するアーティファクトは、クリーンアップに含まれるか、クリーンアップから除外されます。Ant のようなパターン(英語)の後に改行で区切られたルールを使用します。例:
名前の一部として
file
を使用してアーティファクトをクリーンアップするには、構文+:**/file*.*
を使用します。名前の一部として
file
を持つ*.jar
アーティファクトをクリーンアップから除外するには、-:**/file*.jar
を使用します。
依存関係ビルドの基本ルールの動作
基本ルールの依存関係ブロックで、依存関係ビルド構成のビルドアーティファクトのクリーンアップ動作オプションを選択することもできます。TeamCity は、他のビルドでスナップショットの依存関係として使用されるビルドを常に保持します。これらのビルドは、依存するビルドが削除されるまで、クリーンアップ手順によってビルド履歴から削除されません。これらのビルドのアーティファクトは、以下のオプションに基づいて削除できます。
TeamCity は、オプションで、アーティファクトの依存関係によって他のビルドで使用されるビルドとそのアーティファクトを保持できます。次のオプションを使用できます。
デフォルトを使用は、デフォルトのクリーンアップルールで構成されたオプションを使用します。
クリーンアップを防止すると、現在のビルド構成のビルドのアーティファクトまたはスナップショットの依存関係のソースとして使用されたビルド(およびそのアーティファクト)が保護されます。
クリーンアップを妨げないでください(デフォルト)。依存関係ビルドのクリーンアップ関連の処理は、現在のビルド構成のビルドで使用されているという事実を無視します。
例: 依存ビルド構成 A は B にアーティファクトの依存関係があります。A にクリーンアップの防止オプションが使用されている場合、A のビルドにアーティファクトを提供する B のビルドは、ビルドのクリーニング中に処理されないため、ビルドそしてそれらのアーティファクトは保存されます。
機能ブランチを使用したビルド構成の基本ルールの動作
ビルド構成に複数のブランチからのビルドがある場合、ベースクリーンアップルールを適用する前に、TeamCity はこの構成のビルド履歴を複数のグループに分割します。TeamCity は、アクティブなブランチごとに 1 つのグループを作成し、非アクティブなブランチからのすべてのビルドに対して 1 つのグループを作成します。次に、基本クリーンアップルールが各グループに個別に適用されます。
パーソナルビルドの基本ルールの動作
ベースクリーンアップルールは、非個人用ビルドと個人用ビルドに別々に適用されます。つまり、3 つの成功したビルドを保持するルールがある場合、3 つの非個人ビルドと 3 つの個人ビルドが(上記の各ブランチグループで)保存されます。
ビルド構成テンプレートの基本ルール
TeamCity 2019.2 以前は、ビルド構成テンプレートに基本ルールを割り当てることが可能でした。互換性のために、ビルド構成テンプレートの既存のクリーンアップルールはすべてそのままで、クリーンアップ規則ページでアクセスできます。
ルールを守る
キープルールは、クリーンアップ中に保存する特定のデータを定義します。複数の保持ルールをプロジェクトまたはビルド構成に割り当てることができます。
各保持ルールでは、次の設定を構成できます。
保存するデータを作成する : 履歴、アーティファクト、ログ、統計、またはすべて。
アーティファクトを依存関係に保持するかどうか。このオプションは、依存関係ビルド構成のビルドもクリーンアップするかどうかを制御します。このオプションを有効にすると、一部のビルドがこのルールによって保持される場合、その依存関係ビルドのすべてのアーティファクトも保持されます。このオプションは、基本ルールの依存関係オプションと同様に機能します。
ビルド範囲 : ルールの影響を受ける時間間隔または最後のビルドの数。
必要に応じて、保存され、そのステータス、タグ、およびブランチにより構築しフィルタリングすることができます(ブランチフィルターパターンマッチングではサポートされています)。ルールを個人用または非個人用のビルドのみに制限することもできます。
制限を、一致する各ブランチに個別に適用するか、選択したブランチのすべてのビルドに単一のセットとして適用する必要があるかを選択します。
この条件は、影響を受けるビルド構成ごとに 1 回適用されます。フィルターでブランチが指定されていない場合は、ビルド構成内の各ブランチ、またはセットとしてのすべてのビルド構成ブランチのいずれかに適用されます。
例: 最後の 10 ビルドの統計を保持することを選択し、このルールに 2 つのブランチを選択した場合、選択した両方のブランチから最後の 10 ビルドを保持するために「すべて選択」を選択するか、最後の 20 ビルドを保持するために「選択した各ブランチ」を選択できます。ブランチごとに 10。
TeamCity は、次の順序で保持ルールを処理します。
影響を受けるプロジェクトまたはビルド構成のビルドをフィルタリングします。
選択したすべてのブランチにルールを適用するか、選択した各ブランチのビルドに個別にルールを適用するかを決定します(説明を参照)。
指定された範囲でのみビルドを保持します。
保存するビルドデータの種類を決定します。
依存関係ビルドのアーティファクトを保持する必要があるかどうかを決定します。
ルールの保持動作に関する注意事項:
複数のタグを入力すると、これらのタグのいずれかでマークされたすべてのビルドにルールが適用されます。
すべての「以降の日数」範囲オプションで、TeamCity は特定の日付の小数時間を考慮せず、選択した日(深夜から 11:59 PM まで)から開始日に戻る時間間隔で開始されたビルドにのみルールを適用します。影響を受ける範囲(選択した日から構成された日数の制限を引いたもの)。
削除されたビルド構成のクリーンアップ
プロジェクトまたはビルド構成が削除されると、対応するビルドデータがクリーンアップ中に削除されますが、削除から 5 日(432, 000 秒)が経過した場合に限ります。
タイムアウトを変更するには、teamcity.deletedBuildTypes.cleanupTimeout
内部プロパティを必要な秒数に設定して、データを削除から保護します。
すべてのデータを保持し、クリーンアップ中に影響を受けないビルドがあります。これらは:
- 固定ビルド
依存関係の「クリーンアップを防ぐ」オプションがビルド構成で有効になっている場合に、他のビルドでスナップショット依存関係のアーティファクトとして使用されるビルド。このようなビルドは、ビルド履歴リストで
アイコンでマークされます
1 日未満前に削除されたビルド構成のビルド
関連ページ:

TeamCity データディレクトリ
TeamCity データディレクトリは、TeamCity サーバーが構成設定、ビルド結果、現在の操作ファイルを保存するために使用するファイルシステム上のディレクトリです。ディレクトリはすべての構成設定の主記憶域であり、TeamCity のインストールに不可欠なデータを保持しています。ビルド履歴、ユーザーとそのデータ、その他のいくつかのデータは、データベースに保存されます。ディレクトリおよびデータベースに格納されているデータの説明については、バックアップに関する注意を参照してください。このドキュメ...

統計チャート
プロジェクトの状況や個々のビルド構成を長期にわたって追跡できるようにするために、TeamCity はすべての履歴にわたって統計データを収集し、それをビジュアルチャートとして表示します。統計チャートは次のカテゴリに分類できます。プロジェクトレベルの統計はプロジェクトホーム | 統計タブで利用可能です。構成レベルの統計を作成するは、ビルド構成ホームページ | 統計タブで利用できます。統計タブで選択した統計レベルに関係なく、次のことができます。ブランチフィルターを使用して、指定されたブランチからの結果のみ...

機能ブランチを使用した作業
分散バージョン管理システム(DVCS)の機能ブランチを使用すると、メインの開発とは独立して機能を操作し、機能のすべての変更をブランチにコミットして、機能の補完時に変更をメインのブランチにマージできます。このアプローチは、ソフトウェア開発チームに多くの利点をもたらします。ただし、専用のサポートがない継続的インテグレーションサーバーでは、ビルド構成の継続的な重複、可視性の低下、最終的にはプロセスの制御の喪失など、多くの問題が発生します。機能ブランチの TeamCity サポートは継続的に増加しており...