【入門編】Bitbucketのストレージ容量を最適化する:不要なGit LFSキャッシュのクリーンアップと過去のアーティファクト削除 – バージョン管理・CI/CD活用バイブル

エンジニアの皆さん、こんにちは。現場で泥臭いトラブルと格闘しながら、システムの「健全さ」を保つことこそがDevOpsの真髄だと信じている先輩エンジニアです。

今日は、Bitbucketを使っているチームが必ず一度は直面する「ストレージ制限」の壁について、現場レベルの処方箋を授けます。特にGit LFS(Large File Storage)やパイプラインのアーティファクトは、放置するとあっという間にクラウド上の容量を食いつぶし、いざという時のデプロイを阻害する「隠れた爆弾」になります。

これをスマートに解消して、クリーンなリポジトリ環境を手に入れましょう。

—

1. なぜストレージが「爆速」で埋まるのか?

Bitbucketのストレージ制限は、主に以下の2つが原因です。

  • Git LFSの肥大化: 画像、動画、バイナリデータなど、巨大なファイルを履歴に残しすぎている。
  • 不要なパイプライン・アーティファクト: CI/CDのビルド結果(バイナリやテスト結果)がデフォルト設定で残り続けている。

これらを放置すると「リポジトリのクローンが遅くなる」「ストレージ料金が跳ね上がる」という負のスパイラルに陥ります。

—

2. ステップ1:Git LFSの「断捨離」

Git LFSは、一度プッシュすると「過去の全履歴」がサーバー上に残ります。使っていない巨大ファイルを歴史から消し去る必要があります。

BFG Repo-Cleanerの活用

標準の`git filter-branch`は遅くて複雑です。伝説的なエンジニアは迷わず「BFG Repo-Cleaner」を使います。

1. BFGのダウンロード(Java環境が必要です)

から取得

2. 100MB以上の巨大ファイルを履歴から抹消
java -jar bfg.jar –strip-blobs-bigger-than 100M

3. ゴミ掃除とリポジトリの再パック
git reflog expire –expire=now –all && git gc –prune=now –aggressive

4. 強制プッシュ(※チーム全員に周知して同期してください)
git push –force

先輩からのアドバイス: この操作は歴史を書き換える「禁断の術」です。必ずバックアップを取ってから、開発メンバー全員が作業を止めているタイミングで行ってください。

—

3. ステップ2:パイプライン・アーティファクトの自動クリーンアップ

Bitbucket Pipelinesで生成されるビルド成果物は、明示的に設定しない限り溜まり続けます。`bitbucket-pipelines.yml`にライフサイクルルールを組み込むのが鉄則です。

設定ファイルへの追記(推奨)

最近のBitbucketでは、アーティファクトの保持期間を管理画面から設定可能ですが、パイプラインの設計思想として「不要なものは残さない」を徹底しましょう。

bitbucket-pipelines.yml
pipelines:
default:

  • step:

name: Build and Test
artifacts:
# ビルドに必要な最小限のみを指定する

  • dist/

script:

  • npm install
  • npm run build

# ビルド後のクリーンアップを意識する

  • rm -rf node_modules/.cache

運用ハック: 不要な中間生成物を残さないよう、`script`の最後で`rm -rf`コマンドを打つ癖をつけましょう。これだけで、サーバー側のI/O負荷とストレージ消費を大幅に抑えられます。

—

4. 精度高い「HelloWorld的」な動作確認

ストレージを整理したら、本当に容量が減ったかを確認しましょう。

1. Bitbucket上の確認:

  • `Repository settings` > `Repository details` を開き、「Size」を確認します。

2. LFSの追跡状況を確認:

  • ローカルで `git lfs ls-files` を実行し、本当に消したいファイルがリストから消えているか確認します。

3. パイプラインの再実行:

  • 一度パイプラインを回し、アーティファクトが適切に生成され、それが設定した保持期間後に削除されるかをテスト環境でシミュレーションしてください。

—

最後に:現場で震えるほど役立つ「心構え」

ツールを導入するのは誰でもできます。しかし、「リポジトリの健康状態を維持する」のは、真のエンジニアにしかできない仕事です。

今回紹介したメンテナンスを定期的に(例えば月に一度)行うだけで、チームの生産性は劇的に向上します。リポジトリが軽快になれば、新しく入ってきたメンバーも「このプロジェクトは管理が行き届いている」と感じ、安心して開発に集中できるはずです。

これが、現場で信頼されるエンジニアへの第一歩です。困ったことがあれば、いつでもまた聞きに来てくださいね。応援しています!

タイトルとURLをコピーしました