こんにちは。現場の最前線でCI/CDと格闘しているエンジニアです。
Bitbucket Pipelinesを使っていると、ふとこう思いませんか？
「なんでテストを実行するだけでこんなに時間がかかるんだ？」
その原因の多くは、Dockerイメージの肥大化とレイヤーキャッシュの非効率さにあります。特にCIは毎日何度も走るもの。1回のビルドで1分短縮できれば、チーム全体で年間数百時間の節約になります。
今日は、Bitbucket Pipelinesを「爆速」にするための、現場で使える最適化テクニックを伝授します。これをマスターすれば、あなたの開発体験は劇的に変わりますよ。
—
1. なぜ「重いイメージ」は悪なのか？
Bitbucket Pipelinesの仕組みはシンプルです。ジョブが走るたびに、指定したDockerイメージをネットワーク経由でプルし、コンテナを立ち上げます。
- イメージが重い： ダウンロードに時間がかかる（待ち時間の増大）。
- レイヤーが非効率： キャッシュが効かず、変更に関係ないパッケージまで再インストールする（CPU/メモリの無駄）。
これらを解決するための「3種の神器」を紹介します。
—
2. 【極意その1】マルチステージビルドで「捨てられる環境」を作る
実行環境に、ビルドに必要なコンパイラや開発ツールを含める必要はありません。必要なのは「実行バイナリのみ」です。
ステージ1: ビルド環境 (Node.jsの重いイメージ)
FROM node:18-alpine AS builder
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build
ステージ2: 実行環境 (軽量なNginxイメージ)
FROM nginx:alpine
ビルドした成果物だけをコピーしてくる
COPY –from=builder /app/dist /usr/share/nginx/html
ポイント： `builder`ステージにある重い依存関係やソースコードは、最終イメージには一切含まれません。これにより、デプロイ先でも高速に起動するミニマムな環境が手に入ります。
—
3. 【極意その2】Alpine Linuxへの移行とパッケージ管理の鉄則
可能な限り `alpine` ベースのイメージを選びましょう。OSサイズが数MBレベルに収まります。ただし、パッケージインストール時は「キャッシュを残さない」のが鉄則です。
悪い例: apk updateのキャッシュがレイヤーに残る
RUN apk add git
良い例: –no-cacheでキャッシュを捨て、&&でコマンドを繋ぐ
RUN apk add –no-cache git && \
rm -rf /var/cache/apk/
この「&&で繋ぐ」書き方は非常に重要です。Dockerは命令ごとにレイヤーを作るため、コマンドを分けると削除コマンドが別レイヤーになり、結局サイズが減らないからです。
—
4. 【極意その3】Bitbucket Pipelinesのキャッシュ機能を使い倒す
Dockerレイヤーのキャッシュだけでなく、Bitbucket Pipelines独自のキャッシュ機能を併用します。`bitbucket-pipelines.yml`にこれを書き込むだけで、依存関係のダウンロード時間が激減します。
image: node:18-alpine
pipelines:
default:
- step:
caches:
- node # ここが重要！node_modulesをキャッシュする
script:
- npm install
- npm test
これで、毎回 `npm install` する必要がなくなります。
—
5. HelloWorld: 最速パイプラインの構成
では、これらを統合した「最高に効率的な基本形」を見てみましょう。
bitbucket-pipelines.yml
image: node:18-alpine
pipelines:
default:
- step:
name: Build and Test
caches:
- node
script:
- npm ci # npm installより高速で安全なインストール
- npm run test
動作確認の手順:
1. リポジトリのルートに `bitbucket-pipelines.yml` を作成します。
2. Bitbucketの「Pipelines」タブを開き、有効化します。
3. コミットをプッシュすると、自動的にビルドが開始されます。
最初は「緑色のチェックマーク」が出るまでドキドキするかもしれませんが、一度成功してキャッシュが効き始めれば、2回目以降のビルド時間は驚くほど短くなるはずです。
—
最後に：エンジニアとしてのマインドセット
CI/CDの最適化は、単なる「時短」ではありません。
「速いフィードバックループ」は、チームの心理的安全性を高めます。
テスト結果が1分でわかれば、エンジニアは自信を持ってコードをマージできます。逆に15分かかれば、どうしても慎重になり、デプロイの回数は減ってしまうでしょう。
まずは、あなたのプロジェクトのDockerfileに `FROM … AS builder` を1行書くところから始めてみてください。その小さな1歩が、明日のあなたとチームを大きく助けるはずです。
何か詰まったら、いつでも聞いてくださいね。応援しています！