Bitbucket PipelinesでE2Eの「死」を可視化せよ：スクリーンショット自動保存でデバッグを爆速化する
「ローカルでは通るのに、CIでだけ落ちる」。
この悪魔のような現象に直面したとき、多くのエンジニアはログの海を彷徨い、何度もリトライを繰り返して時間を浪費する。特にE2Eテストにおいて、原因不明の失敗はチームのベロシティを著しく低下させるガンだ。
Bitbucket Pipelinesを使っているなら、「失敗した瞬間のスクリーンショット」をアーティファクトとして自動回収する仕組みは、もはや贅沢品ではなく生存戦略である。今日は、CypressやPlaywrightの実行結果を確実に手元に引き寄せる、現場の極限設定を伝授する。
—
1. なぜアーティファクトを「戦略的」に使うべきか
Bitbucketの`artifacts`機能は、単なるファイルの退避場所ではない。CI/CDパイプラインにおいて、「失敗の証拠を永続化するアーカイブ」として設計すべきだ。
実践的YAML構成：`bitbucket-pipelines.yml`の最適解
以下の構成は、テスト実行後に発生した失敗ログとスクリーンショットを、後からでも確実に追跡できるようにしたものだ。
pipelines:
default:
- step:
name: E2E Testing with Playwright
image: mcr.microsoft.com/playwright:v1.40.0-jammy
script:
- npm install
- npx playwright test –reporter=line
artifacts:
# 失敗時に生成されるスクリーンショットとトレースファイルを確保
# フォルダごと丸ごと保存するのが「後から解析」の鉄則
- test-results/
- playwright-report/
after-script:
# 失敗時のみ通知を飛ばすフック。ここにSlack Webhook等を仕込む
- if [ $BITBUCKET_EXIT_CODE -ne 0 ]; then echo “Test failed, artifacts uploaded.”; fi
この設定の「魂」：
- ワイルドカードの活用: `test-results/`と指定することで、テストがどこで落ちても確実にスクリーンショットを拾い上げる。
- after-scriptでのハンドリング: CI上の「失敗」を検知して即座に通知するフックを仕込むことで、エンジニアがCIのダッシュボードを監視する時間をゼロにする。
—
2. チーム開発で「デバッグ体験」を統一する神ルール
設定ファイルだけでは不十分だ。チーム全体が「再現性」に執着するためのエンジニアリング文化を作れ。
絶対守るべき3つのルール
1. パスの固定化: スクリーンショットの出力先は、全プロジェクトで`/test-results`に統一する。CIの設定をコピペで使い回せるようにするためだ。
2. ファイル名にタイムスタンプとステータスを埋め込む: `failure-{testName}-{timestamp}.png`のように命名規則を強制せよ。これにより、時系列でのデバッグが可能になる。
3. CIのアーティファクトは「閲覧」ではなく「ダウンロード」を前提に: BitbucketのUI上で見るだけでなく、ローカルのPlaywright/Cypress UIに食わせて解析するフローをチームに徹底させる。
—
3. 現場で使える「隠れたテクニック」と生産性向上術
VS CodeでBitbucket Pipelinesを制する
VS Codeの拡張機能「Bitbucket Pipelines」は必ず入れろ。わざわざブラウザを開かなくても、失敗したステップのログをエディタ内で確認できる。
- ショートカット活用: `Cmd + Shift + P` (Mac) から `Bitbucket Pipelines: Show Status` を叩く癖をつけろ。これだけでコンテキストスイッチのコストが劇的に下がる。
「再現性」を極限まで高めるDocker戦略
CI環境とローカル環境でライブラリのバージョンがズレると、スクリーンショットすら意味をなさなくなる。
- 神設定: `bitbucket-pipelines.yml`で使用するDockerイメージと、ローカルで使う `devcontainer` のイメージを完全に一致させろ。
- Dockerfileのキャッシュ戦略: `COPY package.json .` の後に `npm install` を実行し、Dockerのレイヤーキャッシュをフル活用する。ビルド時間が数分短縮されるだけで、一日の試行回数は倍になる。
—
4. テックリードからの提言：CIは「失敗から学ぶ装置」である
E2Eテストの失敗は、不吉な予兆ではない。システムの脆さが露呈した「改善のチャンス」だ。
スクリーンショットが保存されていれば、「あ、このモーダルが表示される前にボタンを押そうとしていたのか」と、10秒で原因が判明する。一方で、ログだけを頼りにすれば、1時間かけても再現条件が見つからないこともある。
「ログを追うな、証拠を見ろ」。
この精神をCI/CDの設計に組み込め。Bitbucket Pipelinesのアーティファクト機能は、君たちのチームが「闇雲なデバッグ」という暗闇から脱出し、真に価値あるプロダクト開発に時間を割くための最強の武器となるはずだ。
さあ、今すぐYAMLファイルを書き換え、チームの生産性を一段上のステージへ引き上げろ。健闘を祈る。