Bitbucket Pipelinesを「爆速」にする：巨大リポジトリとShallow Cloneの深淵なる最適化
エンジニアの皆さん、お疲れ様です。テックリードの視点から一つ問わせてください。
「CIの待ち時間にコーヒーを淹れに行く習慣」は、今すぐ捨ててください。
大規模なモノレポや、数年分のコミット履歴を抱えた巨大リポジトリにおいて、`git clone` は開発の最大のボトルネックです。Bitbucket Pipelinesのデフォルト設定のまま運用しているなら、あなたは貴重なCPU時間と、何よりエンジニアの集中力をドブに捨てています。
今日は、Bitbucket Pipelinesにおいて「Shallow Clone」を極めるための理論と実践を伝授します。
—
1. なぜ「深さ(depth)」を意識する必要があるのか？
Gitのクローンはデフォルトでは「全履歴」を取得します。数GBに及ぶ過去のバイナリや、数万のコミットログは、CI環境では多くの場合「ノイズ」です。
Shallow Cloneのメリット
- 通信量の大幅削減: 必要なデータ量だけを転送するため、ビルド開始時間が劇的に短縮されます。
- メモリ・ディスク消費の最適化: CIコンテナのストレージ制限に引っかかるリスクを低減します。
潜むリスクと解法
`depth: 1`（直近のコミットのみ）は最速ですが、以下のケースで詰みます。
- タグベースのデプロイ: `git describe` でバージョンを判定している場合、過去のタグが見えず失敗する。
- 差分検知: `git diff HEAD~1` などで直近のコミットしか見えないため、複数コミットを跨いだ処理ができない。
—
2. 最適な `depth` を導き出す「魔法の数値」
結論から言います。「固定の数値」ではなく「目的」で選んでください。
| 設定値 | 用途 | 推奨度 |
| :— | :— | :— |
| `depth: 1` | 単純なユニットテスト、リンターのみ | ★★★★★ |
| `depth: 50` | 一般的なビルド、簡単な差分判定 | ★★★★☆ |
| `depth: full` | リリース用タグ生成、複雑なchangelog作成 | ★★☆☆☆ |
ベストプラクティス：CI設定の構成例
`bitbucket-pipelines.yml` での記述は以下の通りです。
pipelines:
default:
- step:
name: Build and Test
# git-lfsを使っている場合は注意が必要だが、基本はこれで高速化
clone:
depth: 50 # 直近50コミットまで取得。大抵のCIジョブはこれで十分。
script:
- npm install
- npm test
branches:
master:
- step:
name: Full Clone for Release
clone:
depth: full # リリース時はタグ情報を全て必要とするためフル取得
script:
- ./scripts/build-release.sh
—
3. 生産性を底上げする「現場のハック」
① Gitの「神」設定をチームで共有する
リポジトリ直下に `.gitconfig` を置き、CIだけでなくローカル開発環境でもクローンを最適化させます。
全員に設定を強制するなら、リポジトリの設定に含める
git config –global fetch.shallow true
git config –global core.compression 0 # 圧縮時間を削減
② 絶対に入れるべきプラグイン：Bitbucket Cloudの「Pipelines UI」
Bitbucketの画面上でログを追うのは非効率です。「Bitbucket Pipelines CLI」 を導入してください。ターミナルから `bb pipelines` と打つだけで、ブラウザを開かずに失敗したパイプラインの状況を確認できます。
③ 隠れたキーボードショートカット
Bitbucketの画面で `Shift + ?` を押してください。ショートカット一覧が出ます。特に便利なのは以下の通り：
- `p`: 次のパイプラインへ移動
- `r`: 現在のパイプラインを再実行（修正後の確認に必須）
—
4. チームへの展開ルール：テックリードからの提言
「設定をいじって事故った」とならないために、以下のルールをチームに導入してください。
1. 「デフォルトは浅く、例外は明示的に」: 全てのステップで `depth: 1` を基本とし、どうしても必要な場合のみ `depth` を増やすという文化を作る。
2. パイプラインの計測: `bitbucket-pipelines.yml` に `time` コマンドを仕込み、各ステップの実行時間をコメントとして残す習慣をつける。
3. キャッシュの活用: `clone` の深さを調整するのと同時に、`bitbucket-pipelines.yml` の `caches` を併用すること。`node_modules` や `pip` のキャッシュは、クローン時間の短縮以上に「実ビルド時間」を削ります。
definitions:
caches:
npm: ~/.npm
pipelines:
default:
- step:
caches:
- npm
# … 以降の設定
—
最後に：なぜ「速さ」にこだわるのか
CIが速いということは、「コードを書いてからフィードバックを得るまでのループ」が短いということです。
このループが1分短縮されるだけで、チーム全体では1日あたり数時間の生産性が生まれます。その時間は、新しい機能を実装したり、負債を返済したり、あるいはチームで技術談義をするために使うべきです。
Bitbucketは単なるホスティングサービスではありません。あなたのチームが進化するための「加速装置」です。今日の設定変更が、明日のチームの爆速開発の第一歩になることを確信しています。
さあ、今すぐ `depth` を削りに行きましょう。現場からは以上です。