ビルド、リリース、テストのアイテム保持ポリシーを設定する

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

アイテム保持ポリシーを使うと、システムに格納されている実行、リリース、テストを保持する期間を設定できます。 記憶域スペースを節約するには、以前の実行、テスト、リリースを削除することをお勧めします。

Azure DevOps の [プロジェクトの設定] では、以下のアイテム保持ポリシーを使用できます。

1. パイプライン - 成果物、シンボル、添付ファイル、実行、pull request の実行を保持する期間を設定します。
2. リリース (クラシック) - ビルドを保存し、既定値と最大の保持設定を表示するかどうかを設定します。
3. テスト - 自動および手動テストの実行、結果、添付ファイルを保存する期間を設定します。

注意

オンプレミス サーバーを使っている場合、プロジェクトのアイテム保持ポリシーの既定値や、リリースが完全に破棄されるタイミングを指定することもできます。 リリースの保持の詳細については、この記事の後半で説明します。

前提条件

既定では、共同作成者、ビルド管理者、プロジェクト管理者、リリース管理者の各グループのメンバーが、アイテム保持ポリシーを管理できます。

アイテム保持ポリシーを管理するには、次のサブスクリプションのいずれかを持っている必要があります。

• Enterprise
• Test Professional
• MSDN Platforms

また、Azure Test Plans の月次アクセスを購入し、Basic + Test Plans アクセス レベルを割り当てることもできます。 ユーザー ロールによるアクセスのテストに関する記事を参照してください。

保持ポリシーを構成する

1. プロジェクトにサインインします。

2. プロジェクトの設定の Settings タブに移動します。

3. [パイプライン] の [設定] または [リリースの保持]、または [テスト] の [保持] を選びます。

   • [設定] を選び、実行、成果物、シンボル、添付ファイル、pull request の実行に関するアイテム保持ポリシーを構成します。
   • [リリースの保持] を選び、リリースのアイテム保持ポリシーを設定して、リリースを削除するか完全に破棄するタイミングを構成します。
   • [保持] を選んで、手動および自動のテスト実行を保持する期間を設定します。

   

実行アイテム保持ポリシーを設定する

ほとんどの場合、完了した実行を一定の日数を超えて保持する必要はありません。 アイテム保持ポリシーを使うと、各実行を削除前に何日間保持するかを制御できます。

1. プロジェクトの設定の Settings タブに移動します。

2. [パイプライン] セクションで [設定] を選びます。

   • 成果物、シンボル、添付ファイルを保持する日数を設定します。
   • 実行を保持する日数を設定します
   • pull request の実行を保持する日数を設定します
   • 各パイプラインの最近の実行を保持する日数を設定します

警告

Azure DevOps では、パイプラインごとの保持規則がサポートされなくなりました。 YAML とクラシック パイプラインのアイテム保持ポリシーを構成する唯一の方法は、上記のプロジェクトの設定を使うことです。 パイプラインごとのアイテム保持ポリシーを構成することはできなくなりました。

各パイプラインで保持する最近の実行数の設定については、もう少し説明が必要です。 この設定の解釈は、パイプラインで構築するリポジトリの種類によって異なります。

• Azure Repos: Azure Pipelines により、パイプラインの既定のブランチとリポジトリの各保護ブランチに対して、構成した最新の実行数が保持されます。 何らかのブランチ ポリシーが構成されているブランチは、保護ブランチと見なされます。

  たとえば、main と release の 2 つのブランチがあるリポジトリを考えてみましょう。 pipeline's default branch は main ブランチであり、release ブランチにはブランチ ポリシーがあるので、保護ブランチであるとします。 この場合、3 つの実行を保持するようにポリシーを構成した場合、main の最新の 3 つの実行と、release ブランチの最新の 3 つの実行の両方が保持されます。 さらに、このパイプラインの最新の 3 つの実行も (ブランチに関係なく) 保持されます。

  このロジックをさらに明確にするために、このパイプラインの実行一覧が次のような内容で、最新の実行が一番上にあるとします。 この表は、最新の 3 つの実行を保持するように構成した場合、どの実行が保持されるかを示しています (日数設定の効果は無視します)。

  実行番号	[Branch]\(ブランチ)	保持される/保持されない	なぜですか?
  実行 10	メイン	保持されています	メインの最新の 3 つとパイプラインの最新の 3 つ
  実行 9	branch1	保持されています	パイプラインの最新の 3 つ
  実行 8	branch2	保持されています	パイプラインの最新の 3 つ
  実行 7	メイン	保持されています	メインの最新の 3 つ
  実行 6	メイン	保持されています	メインの最新の 3 つ
  実行 5	メイン	保持されない	メインの最新の 3 つもパイプラインもなし
  実行 4	メイン	保持されない	メインの最新の 3 つもパイプラインもなし
  実行 3	branch1	保持されない	メインの最新の 3 つもパイプラインもなし
  実行 2	release	保持されています	リリースの最新の 3 つ
  実行 1	メイン	保持されない	メインの最新の 3 つもパイプラインもなし

• 他のすべての Git リポジトリ: Azure Pipelines は、パイプライン全体に対して構成された最新の実行数を保持します。

• TFVC: Azure Pipelines は、ブランチに関係なく、パイプライン全体に対して構成された最新の実行数を保持します。

実行のうち削除される部分

実行が削除されると、次の情報が削除されます。

• ログ
• すべてのパイプラインとビルド成果物
• すべてのシンボル
• バイナリ
• Test results
• 実行のメタデータ
• ソース ラベル (TFVC) またはタグ (Git)

ユニバーサル パッケージ、NuGet、npm、その他のパッケージは、パイプラインの保持に関連付けられていません。

実行が削除されるタイミング

アイテム保持ポリシーは 1 日に 1 回処理されます。 負荷分散の目的で 1 日を通して作業を分散しているため、ポリシーが処理される時間は変動します。 このプロセスを変更するオプションはありません。

次の条件がすべて当てはまる場合、実行は削除されます。

• 保持設定で構成された日数を超えています
• 保持設定で構成された最近の実行の 1 つではありません
• 無期限に保持するようにマークされていません
• リリースによって保持されていません

パイプラインの実行時に保持リースを自動的に設定する

保持リースは、構成された保持期間を超えてパイプライン実行の有効期間を管理するために使われます。 リース API を呼び出すことで、パイプライン実行に保持リースを追加または削除できます。 この API をパイプライン内で呼び出すには、スクリプトを使い、runId と definitionId に定義済み変数を使います。

保持リースは、特定の期間のパイプライン実行に追加できます。 たとえば、テスト環境に配置するパイプライン実行の保持期間は短く、運用環境に配置する実行は保持期間を長くすることができます。

パイプラインの実行時に保持リースを手動で設定する

[Pipeline run details] (パイプライン実行の詳細) ページの [その他の操作メニュー] を使って、パイプライン実行を保持するように手動で設定できます。

実行を削除する

[Pipeline run details] (パイプライン実行の詳細) ページの [その他の操作メニュー] を使って実行を削除できます。

注意

現在、アイテム保持ポリシーが実行に適用されている場合、実行を削除する前にそれらを削除する必要があります。 手順については、パイプライン実行の詳細の実行の削除に関する記事を参照してください。

ビルドとリリースのアイテム保持ポリシーを設定する

クラシック リリース パイプラインのリリース アイテム保持ポリシーによって、リリースとそれにリンクされた実行を保持する期間が決まります。 これらのポリシーを使うと、最後に変更または配置された後に各リリースを保持する日数と、各パイプラインで保持すする必要があるリリースの最小数を制御できます。

リリースの保持タイマーは、リリースが変更されるかステージに配置されるたびにリセットされます。 保持するリリースの最小数の設定は、日数よりも優先されます。 たとえば、少なくとも 3 つのリリースを保持するように指定した場合、指定した日数に関係なく、最新の 3 つが無期限に保持されます。 ただし、これらのリリースが不要になった場合は、手動で削除できます。 リリースの保持のしくみの詳細については、以下の FAQ を参照してください。

リリース パイプラインの作成者である場合は、[保持] タブでパイプラインのリリースのアイテム保持ポリシーをカスタマイズできます。

YAML パイプラインとビルド パイプラインのアイテム保持ポリシーは同じです。 パイプラインの保持設定は、[パイプライン] の [プロジェクトの設定] の [設定] セクションで確認できます。

グローバル リリースのアイテム保持ポリシー

オンプレミスの Team Foundation Server または Azure DevOps Server を使っている場合、プロジェクトに対してリリースのアイテム保持ポリシーの既定値と最大値を指定できます。 また、リリースが完全に破棄される (ビルド エクスプローラーの [削除済み] タブから削除される) タイミングを指定することもできます。

Azure DevOps Services を使っている場合、プロジェクトのこれらの設定を表示できますが、変更することはできません。

グローバル リリースのアイテム保持ポリシー設定は、プロジェクトの [リリースの保持] 設定から確認できます。

• Azure DevOps Services: https://dev.azure.com/{organization}/{project}/_settings/release?app=ms.vss-build-web.build-release-hub-group
• オンプレミス: https://{your_server}/tfs/{collection_name}/{project}/_admin/_apps/hub/ms.vss-releaseManagement-web.release-project-admin-hub

[最大アイテム保持ポリシー] には、すべてのリリース パイプラインに対してリリースを保持できる期間の上限を設定します。 リリース パイプラインの作成者は、ここに指定した値を超える定義の設定を構成することはできません。

[既定のアイテム保持ポリシー] には、すべてのリリース パイプラインの既定の保持値を設定します。 ビルド パイプラインの作成者は、これらの値をオーバーライドできます。

破棄ポリシーを使うと、リリースが削除された後、一定期間保持することができます。 個々のリリース パイプラインでこのポリシーをオーバーライドすることはできません。

[ファイルのコピー] タスクを使ってより長くデータを保存する

[ファイルのコピー] タスクを使うと、アイテム保持ポリシーで設定した期間よりも長くビルドと成果物のデータを保存できます。 [ビルド成果物の発行] タスクを使って保存したデータは定期的にクリーンアップされ、削除されるため、[ファイルのコピー] タスクは [ビルド成果物の発行] タスクよりも推奨されます。

YAML

- task: CopyFiles@2
  displayName: 'Copy Files to: \\mypath\storage\$(Build.BuildNumber)'
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: '_buildOutput/**'
    TargetFolder: '\\mypath\storage\$(Build.BuildNumber)'

クラシック

1. パイプラインに [ファイルのコピー] タスクを追加します。

2. [ファイルのコピー] タスクを構成します。

よく寄せられる質問

実行またはリリースが無期限で保持されるようにマークした場合でも、アイテム保持ポリシーは適用されますか?

いいえ。 個々の実行またはリリースが無期限に保持されるようにマークした場合、パイプラインのアイテム保持ポリシーも、管理者が設定した上限値も適用されません。 これは、無期限の保持を停止するまで保持されます。

運用環境に配置した実行がより長く保持されるように指定するにはどうすればよいですか?

クラシック リリースを使って運用環境に配置する場合は、リリース パイプラインのアイテム保持ポリシーをカスタマイズします。 運用環境に配置されたリリースを保持する必要がある日数を指定します。 さらに、そのリリースに関連付けられた実行が保持されることを示します。 これは、実行のアイテム保持ポリシーをオーバーライドします。

マルチステージの YAML パイプラインを使って運用環境に配置する場合、構成できるアイテム保持ポリシーはプロジェクト設定のみです。 ビルドが配置される環境に基づいて保持をカスタマイズすることはできません。

実行を無期限に保持するようにマークしませんでした。 ただし、保持されている実行数が多いことを確認しています。 これを防ぐにはどうすればよいですか?

この場合は、次のいずれかの理由が考えられます。

• 実行は、プロジェクトの誰かが無期限に保持されるようにマークしています。
• 実行はリリースによって使われ、そのリリースはこれらの実行の保持をロックしています。 先ほど説明したように、リリースのアイテム保持ポリシーをカスタマイズします。

実行が不要になった、またはリリースが既に削除されていると思われる場合は、実行を手動で削除できます。

[保持する最小リリース数] 設定はどのように機能しますか?

[保持する最小リリース数] はステージ レベルで定義されます。 これは、リリースが保持期間を過ぎている場合でも、ステージに最近配置されたリリースの指定した数が Azure DevOps によって常に保持されることを示します。 ステージで配置が開始されたときにのみ、そのステージで保持する最小リリースに従ってリリースが考慮されます。 成功した配置と失敗した配置の両方が考慮されます。 承認待ちのリリースは考慮されません。

異なる保有期間を持つ複数のステージにリリースを配置する場合、保持期間はどのように決定されますか?

最終的な保持期間は、リリースが配置されるすべてのステージの保持日数設定と、その中で最も長い保持日数を考慮して決まります。 [保持する最小リリース数] はステージ レベルで管理され、複数のステージに配置されたリリースかどうかに基づいて変更されることはありません。 関連付けられた成果物の保持は、これが true に設定されているステージにリリースが配置されたときに適用されます。

古いリリースがあるステージを削除しました。 この場合、どのような保持が考慮されますか?

ステージは削除されたので、現在、ステージ レベルの保持設定は適用できません。 このような場合、Azure DevOps は、プロジェクト レベルの既定の保持にフォールバックします。

私の組織からは、設定で許可されているよりも長くビルドとリリースを保持するように求められています。 より長く保持するよう要求するにはどうすればよいですか?

保持設定で許可されているよりも長く実行またはリリースを保持する唯一の方法は、無期限に保持されるように手動でマークすることです。 より長い保存期間を手動で設定する方法はありません。 サポートが必要な場合は、Azure DevOps サポート にお問い合わせください。

また、実行に関する情報と成果物をダウンロードし、独自のストレージまたは成果物リポジトリにアップロードするために、REST API を使う可能性を検討することもできます。

いくつかの実行を失いました。 元に戻す方法はありますか?

サービスのバグによって実行が失われたと思われる場合は、失われた情報を回復するため、直ちにサポート チケットを作成してください。 ビルド定義を手動で削除してから 1 週間を超えた場合、回復することはできません。 アイテム保持ポリシーにより、実行が想定どおり削除された場合、失われた実行を回復することはできません。

エージェントの Build.Cleanup 機能を使うにはどうすればよいですか?

エージェントに Build.Cleanup 機能を設定すると、プールのクリーンアップ ジョブの対象はそれらのエージェントのみになり、その他のエージェントは通常の作業を自由に実行できます。 パイプライン実行が削除されると、Azure DevOps の外部に格納されている成果物は、エージェントのジョブ実行によってクリーンアップされます。 エージェント プールがクリーンアップ ジョブで飽和状態になると、問題が発生する可能性があります。 これを解決するには、プール内のエージェントのサブセットをクリーンアップ エージェントとして指定します。 Build.Cleanup が設定されているエージェントがある場合、それらのエージェントのみがクリーンアップ ジョブを実行し、その他のエージェントは引き続きパイプライン ジョブを自由に実行します。 クリーンアップ機能を有効にするには、[エージェント]>[機能] に移動し、Build.Cleanup を 1 に設定します。

ビルドが削除されると、ファイル共有成果物はどうなりますか?

ファイル共有成果物を含むビルドが削除されると、それらのファイルをクリーンアップするために、新しいビルド タスクがビルド エージェント上のキューに登録されます。 このタスクを実行するエージェントは、次の条件に基づいて選ばれます。Build.Cleanup 機能を使用できるエージェントはありますか? ビルドを実行したエージェントは使用できますか? 同じプールからエージェントを使用できますか? 同様のプールのエージェントは使用できますか? 使用できるエージェントはありますか?

リリースの一部として発行された自動テスト結果は、そのリリースが削除されるまで保持されますか?

リリースのステージ内で発行されたテスト結果は、テスト結果に対して構成されたアイテム保持ポリシーの指定に従って保持されます。 リリースが保持されるまでは、テスト結果は保持されません。 リリースと同じ期間、テスト結果が必要な場合は、[プロジェクトの設定] の自動テスト実行の保持設定を [削除しない] に設定します。 これにより、リリースが削除されたときにのみ、テスト結果が削除されるようになります。

手動テスト結果は削除されますか?

いいえ。 手動テスト結果は削除されません。

バージョン管理のラベルやタグを保持するにはどうすればよいですか?

注意

ビルド パイプライン中に適用されたバージョン管理ラベルまたはタグのうち、[ソース] タスクから自動的に作成されなかったものは、ビルドが削除されても保持されます。 ただし、ビルド時に [ソース] タスクから自動的に作成されたバージョン管理ラベルまたはタグは、ビルド成果物の一部と見なされ、ビルドの削除時に削除されます。

ビルドが削除された場合でもバージョン管理ラベルやタグを保持する必要がある場合は、パイプラインのタスクの一部として適用するか、パイプライン以外で手動でラベルを付けるか、ビルドを無期限に保持する必要があります。

他のパイプラインで使われているパイプラインはどうなりますか?

クラシック リリースでは、自動的に使われるパイプラインは保持されます。

関連記事

• テスト結果を保持する期間を制御する
• テスト成果物を削除する