Bitbucket Pipelines：並列実行の「極意」でCI時間を限界まで削ぎ落とす
「CIの待ち時間が長すぎて、コーヒーを飲みにいく回数が増えた」
もしチームでそんな冗談が飛び交っているなら、それはエンジニアの生産性が溶けている証拠だ。
Bitbucket Pipelinesのデフォルト設定で漫然とテストを走らせているなら、今すぐそのパイプラインを見直すべきだ。今回は、私がテックリードとして現場で叩き込んできた、「並列処理（Parallel Steps）」を駆使してCI時間を物理的に半分以下にする戦略的アプローチを伝授する。
—
1. なぜ「直列実行」が最大の悪なのか
テストスイートが巨大化すると、1つのステップで全てを実行するのは悪手だ。CPUリソースを無駄にし、直列の待ち行列がボトルネックになる。
Bitbucket Pipelinesの `parallel` キーワードは、単なる機能ではない。これはビルド時間を「分割統治（Divide and Conquer）」するための強力な武器だ。
実践的な `bitbucket-pipelines.yml` 構成例
以下は、単体テストを3つのグループに分割し、同時並行で走らせるための構成だ。
pipelines:
default:
- step:
name: Build and Lint
image: node:18
script:
- npm ci
- npm run lint
- parallel: # ここで並列実行を定義
- step:
name: Unit Tests (Group A)
script:
- npm run test:unit — –shard=1/3 # シャーディングで負荷分散
- step:
name: Unit Tests (Group B)
script:
- npm run test:unit — –shard=2/3
- step:
name: Unit Tests (Group C)
script:
- npm run test:unit — –shard=3/3
ポイント:
- `parallel` 内の各ステップは、それぞれ別々のコンテナとして立ち上がる。つまり、実行時間は「最も遅いステップ」に収束する。
- `shard`（分割）戦略を取ることで、テストの偏りを防ぎ、全テスト時間を均等化するのがプロの技だ。
—
2. CI時間を限界まで削るための「プロのハック」
① キャッシュ戦略の最適化（Caching）
並列実行を多用すると、ネットワーク帯域がボトルネックになる。`node_modules` や `.m2` などの依存関係はキャッシュを徹底しろ。
definitions:
caches:
# 依存関係のキャッシュを定義
node: ./node_modules
pipelines:
default:
- step:
caches:
- node
script:
- npm ci
② 「失敗した時だけ」の最適化
全てのテストを毎回走らせる必要はない。`git diff` を活用し、変更があったディレクトリのテストのみを実行するスクリプトをCI側に仕込むのがテックリードの嗜みだ。
—
3. チーム開発を加速させる「神・設定術」
設定ファイルの共有化：YAMLのDRY原則
パイプラインが巨大化すると `bitbucket-pipelines.yml` が肥大化して地獄を見る。`definitions` セクションを活用して、ステップのテンプレート化を徹底せよ。
definitions:
steps:
- step: &test-template
image: node:18
caches:
- node
script:
- npm run test:unit
pipelines:
default:
- step: test-template # 参照を使うことで保守性を担保
チーム開発で必須の「プラグイン＆ツール」
1. Bitbucket Pipelines CLI: ターミナルからパイプラインの状態を監視せよ。ブラウザを開く時間は無駄だ。
2. Commitlint: コミットメッセージのフォーマットを強制し、`pipeline` の条件分岐をコミットタイプ（feat, fix, docsなど）で制御できるようにしろ。
—
4. テックリードからの最終提言
並列処理を導入する際、最も重要なのは「テストの独立性」だ。
並列で走らせると失敗するテストがあるなら、それは「テストコードが環境依存している」か「DBの共有リソースで競合している」という設計ミスに他ならない。
「並列化を阻むテストは、技術的負債のサインである」
この視点を持ってリファクタリングを繰り返せば、CIの時間は勝手に短縮されていく。
まとめ：今日からやるべきアクション
1. 現在のCIのボトルネックを特定せよ（どのステップが一番遅いか？）。
2. 重いテストをシャード（分割）して `parallel` で囲め。
3. キャッシュ設定を再確認し、無駄なダウンロードをゼロにしろ。
パイプラインのチューニングは、一度やればチーム全員の時間を数分ずつ毎日節約できる、最高の投資だ。今すぐ手を動かせ。あなたのコードが世界を変える時間を、CIが阻害してはならない。