GitHubはDeployment Statusに90日の保持ポリシーを導入した。90日を超えたステータスは自動的に削除され、REST APIとGraphQL APIの応答から消える。GitHubはDeploymentの現在状態には影響しないとしているが、過去のデプロイ履歴を監査証跡や品質分析に使っている組織には実質的なデータ保持変更である。

何が変わったか

Deployment Statusは、queued、in_progress、success、failure、inactiveなど、デプロイ処理の状態を時系列で記録する。REST APIではDeploymentごとのStatus一覧や個別Statusを取得できる。新しい保持ポリシーでは、作成から90日を超えたStatusが削除されるため、APIを後から呼び出しても完全な履歴を再構成できない。

Deployment自体や現在状態が直ちに失われるわけではない。問題は、途中経過、失敗と再試行、環境URL、ログURL、説明、実行者など、過去のStatusに紐づく文脈が長期的には残らない点である。

影響を受ける用途

影響が大きいのは、四半期をまたぐ変更監査、規制対応、障害調査、デプロイ頻度や失敗率の分析、環境稼働履歴の証明である。例えば、半年後に「特定の変更がいつ本番へ入り、最初のデプロイが失敗したか」をAPIだけで調べる運用は成立しなくなる。

また、定期バッチが全履歴を毎回取得し直す設計では、古いStatusが徐々に消えるため、集計値が時間経過で変動する。データウェアハウス側で再計算した際、過去の失敗件数が減るような不整合も起こり得る。

移行方針

まず、90日を超える履歴が必要な業務要件を明文化する。保存対象はStatus ID、Deployment ID、状態、作成日時、更新日時、環境、説明、ログURL、環境URL、作成者、リポジトリとする。取得時にはAPIバージョンを固定し、ページネーションを処理する。

保存先は、アクセス制御、暗号化、保持期限、削除、監査ログを備えたデータストアを選ぶ。規制対応では、単なる可視化用データベースではなく、改ざん耐性とエクスポート可能性も確認する。GitHubから削除された後も外部保存を継続するなら、その保持根拠と削除方針をプライバシー文書へ反映する必要がある。

実装と検証

日次または数時間ごとに、新規・更新Statusを増分取得する。取得済みIDをキーに冪等なupsertを行い、APIエラー時は再実行できるようにする。90日境界付近の欠損を避けるため、最終取得時刻に安全な重複区間を設ける。

検証では、GitHub上の直近30日、60日、90日未満の件数と外部保存件数を照合する。さらに、ランダムに選んだDeploymentについて、状態遷移、作成者、ログURLが一致するか確認する。外部保存が止まった場合の監視と、最終成功時刻のアラートも必要になる。

ロールバック

GitHub側の保持ポリシーを利用者が元へ戻すことはできない。ロールバック対象は外部保存パイプラインである。新しい収集処理に不具合があれば停止し、旧集計処理を維持しつつ、欠損期間をGitHub APIから90日以内に再取得する。90日を超えた欠損は回復できない可能性があるため、移行は早いほど安全である。

実務チェックリスト

  • Deployment Statusを使う監査、分析、障害調査を列挙する
  • 必要保持期間と法的根拠を決める
  • 取得項目、APIバージョン、ページネーションを固定する
  • 日次増分取得と冪等保存を実装する
  • 収集停止と件数差分を監視する
  • 外部保存データの削除・アクセス・輸出手順を定める

編集部の見解

現在状態が残るため、通常のデプロイ画面だけを見る組織では変化を感じにくい。しかし、90日を超える監査証跡をGitHub APIに依存していた場合、待つほど復元不能な期間が増える。長期保存が必要なら、GitHubを原本の永続保管庫とみなす設計をやめるべきだ。

一次情報