ゾンビリポジトリを葬れ：GitHubライフサイクル管理の極意
GitHub上のリポジトリは、コードの墓場ではない。放置されたリポジトリは、技術的負債の温床であり、脆弱性の放置という名の「時限爆弾」だ。
DevOpsの最前線に立つエンジニアにとって、リポジトリの管理は単なる整理整頓ではない。それは組織のアタックサーフェス（攻撃対象領域）を最小化し、CI/CDパイプラインのノイズを低減するための極めて重要なアーキテクチャ設計である。
本稿では、リポジトリを「アーカイブ」するか「デリート」するかの冷徹な判断基準と、それをAPIレベルで完全自動化する手法を伝授する。
—
1. 「アーカイブ」vs「デリート」：その境界線はどこにあるか
多くのチームが抱える「とりあえず残しておく」という怠惰な判断は、将来のエンジニアに対する最大の背信行為である。
アーカイブすべきタイミング（Read-onlyの凍結）
- 歴史的参照価値がある: 公開ライブラリや、過去の設計思想を学ぶためのアーカイブ。
- 監査対応が必要: 法的・コンプライアンス上の理由で、数年間のコード保持が義務付けられている場合。
- 依存関係が不明瞭な既存コード: 捨てるには惜しいが、現在は動いていないレガシーシステム。
デリートすべきタイミング（完全消去）
- 機密情報の混入: 過去にAPIキーやクレデンシャルをコミットした履歴がある場合（`git filter-repo`でも不完全なリスクがある）。
- PoC（概念実証）の残骸: 1週間で捨てると決めていた実験コード。
- 依存関係が枯渇し、脆弱性が放置されている: メンテナンスする意思もリソースもない、依存ライブラリのパッチが当たらない古いコード。
—
2. セキュリティリスク：放置されたリポジトリの正体
GitHubのリポジトリを放置することは、「パッチが当たらない脆弱性を世界中に公開し続けている」のと同じだ。Dependabotが警告を出しても、誰も見ない。結果、GitHubのセキュリティアラートはノイズに埋もれ、本当に重要な警告が見落とされる。
ルール: 「メンテしないコードは、公開しておく価値よりリスクの方が常に高い」。
—
3. 【自動化ハック】GitHub APIによるライフサイクル管理の極致
UIからポチポチと設定するのは素人の仕事だ。我々は自動化する。以下は、一定期間アクティビティがないリポジトリを自動で検知し、ライフサイクルを管理するためのPythonスクリプトの断片である。
import os
from github import Github
GitHub API トークン
最小権限の原則に基づき、repoスコープのみを許可したTokenを使用すること
g = Github(os.getenv(“GITHUB_TOKEN”))
org = g.get_organization(“your-organization-name”)
def cleanup_repositories():
for repo in org.get_repos():
# 最終更新から90日以上経過しているかを確認
if (datetime.now() – repo.pushed_at).days > 90:
if repo.stargazers_count == 0 and repo.forks_count == 0:
# 誰にも使われていないPoCは即座に削除
print(f”Deleting repository: {repo.name}”)
repo.delete()
else:
# 利用者がいる場合はアーカイブしてRead-onlyにする
print(f”Archiving repository: {repo.name}”)
repo.edit(archived=True)
ヒント: このスクリプトをGitHub Actionsでcron実行し、
毎週月曜の朝に「死の宣告」を行うパイプラインを構築せよ。
—
4. 未来の自分への贈り物：READMEへの追記ルール
アーカイブする際、ただ設定を切り替えるだけでは不十分だ。将来の自分や、コードを調査するメンバーのために、以下のメタデータをREADMEの冒頭に強制的に埋め込むべきだ。
- Last Maintained Date: 最後に誰が触ったか。
- Reason for Archive: なぜ捨てたか（機能統合、リプレイス完了、PoC終了）。
- Migration Target: もしこれが「移転」なら、現在の正当なリポジトリへのリンク。
これを自動化するには、`git hooks`またはActionsで`README.md`を更新し、PRを作成するワークフローを組むと良い。
—
5. 伝説的エンジニアからの提言：リポジトリは「消耗品」であれ
リポジトリを数年単位で保持し続けるという感覚を捨てろ。「プロジェクトが終われば、そのリポジトリは消滅する」のが理想的なアーキテクチャだ。
- モノレポか、マイクロリポジトリか: プロジェクトの寿命を基準に構成を分ける。
- コンテナ化されたCI: リポジトリ固有のCI設定に依存せず、ビルドコンテナそのものを外部管理し、リポジトリが消えてもビルド環境が再現できるようにしておく。
結論
コードは財産ではない。「価値を生み出すコードのみが財産」である。
ゴミを溜め込む余裕があるなら、次のイノベーションのためにメモリを解放せよ。今すぐGitHubを確認し、不要なリポジトリに `Archived` の印を刻むか、あるいは消し去れ。それが、真のDevOpsエンジニアの流儀だ。