エンジニアの皆さん、こんにちは。現場で「CI/CDの実行時間が長すぎて待ち時間が苦痛……」と悩んだことはありませんか？
特にBitbucketで大規模なリポジトリを扱っていると、`git clone` が終わるのを眺めているだけで貴重な数分間が消えていく。これは、Gitの歴史（全コミット履歴）をすべてダウンロードしようとする、デフォルトの律儀すぎる挙動が原因です。
今日は、その「全履歴ダウンロード」という無駄を削ぎ落とし、`shallow clone`（浅いクローン）を活用して、CI/CDのパイプラインを劇的に加速させるための「現場のハック」を伝授します。
—
1. なぜ「全履歴」がボトルネックになるのか？
Gitはデフォルトで、リポジトリの誕生から現在までの「数万件の全コミット履歴」をすべて手元に持ってこようとします。プロジェクトが数年続けば、クローンするデータ量は数GBに達することもあります。
しかし、CI/CDで必要なのは「今この瞬間のコード」と「その直前の状態」だけですよね？ 過去の数年分の歴史をサーバー上で引きずる必要はありません。この「無駄」を切り捨てるのが `shallow clone` です。
2. Bitbucket Pipelinesでの実装：魔法の `depth` 指定
Bitbucket Pipelinesでは、`clone` セクションに `depth` を設定するだけで、ダウンロードする履歴の深さを制御できます。
最小構成の `bitbucket-pipelines.yml`
image: atlassian/default-image:latest
pipelines:
default:
- step:
name: Build and Test
# 重要なのはここ！depthを指定して履歴を切り詰める
clone:
depth: 1 # 最新の1コミット分だけを取得する
script:
- echo “クローン完了！爆速でビルドを開始します。”
- npm install
- npm test
3. `depth` の値をどう選ぶか？（現場のベストプラクティス）
「じゃあ、とりあえず `depth: 1` でいいの？」と思うかもしれませんが、ここには少しだけ罠があります。
- `depth: 1` を選ぶべき場面
- 単純なビルドやテストのみを行う場合。
- gitの履歴情報を必要としないリリースパイプライン。
- メリット: 圧倒的な速度。ネットワーク帯域の節約。
- `depth: 50` 程度を検討すべき場面
- コミットメッセージでバージョン管理をしている場合（例：`git log` を叩いてリリースノートを自動生成する）。
- マージベースを正しく判定したい場合。
- 特定のコミット間での差分を検知するツール（Linterの差分実行など）を使う場合。
先輩からのアドバイス:
まずは `depth: 50` くらいから始めてみてください。最新の履歴が十分に確保されつつ、全履歴をダウンロードするコストを大幅に抑えられます。これで問題が起きなければ、徐々に減らして限界に挑戦するのが「現場の知恵」です。
4. 知っておくべきリスクと回避策
`shallow clone` は万能ではありません。注意すべき点が一つだけあります。
- リスク: 過去のブランチ情報や、深い履歴を辿るプラグインが正しく動作しないことがあります。
- 回避策: もし「履歴が足りない！」というエラーが出たら、`git fetch –unshallow` をスクリプトの冒頭で実行してください。これで必要な分だけ履歴を後から追加で持ってくることができます。
script:
# 必要に応じて履歴を拡張する
- git fetch –unshallow || echo “既に履歴は十分です”
- ./build-script.sh
—
最後に：自動化は「引き算」から始まる
多くのエンジニアは「何を追加すれば速くなるか」を考えがちですが、DevOpsの真髄は「不必要な処理をいかにして削ぎ落とすか」にあります。
`depth` を適切に設定するだけで、あなたのチームのCI/CD実行時間は、今日から確実に数分短縮されます。1日5回プッシュするとして、1分短縮できれば1ヶ月で1時間以上の「開発者の時間」が守られることになります。
この数分を削る積み重ねが、チームの生産性を劇的に変えるのです。ぜひ次のプッシュから試してみてください。また何か詰まったら、いつでも聞きに来てくださいね！