Bitbucket Pipelines：10分で構築し、その後の一生を楽にする「極限のCI/CD」設計術
「Bitbucket Pipelinesの設定？ YAMLを書いて適当に動かせばいいんでしょ？」
もしそう思っているなら、あなたはエンジニアリングの最も強力なレバレッジポイントを捨てていることになります。
CI/CDパイプラインは単なる「自動化ツール」ではありません。それは、あなたのチームの「開発の鼓動」です。この鼓動が速く、正確であればあるほど、チームの生産性は指数関数的に向上します。
今日は、Bitbucket Pipelinesを単に「動かす」レベルから、「開発体験（DX）を極限まで高める」レベルへ引き上げるための、現場の血肉が通った設計術を伝授します。
—
1. 10分で構築する「失敗しない」骨格
まず、パイプラインの基本形を正しく作りましょう。重要なのは「再利用性」と「可読性」です。
bitbucket-pipelines.yml
image: node:18-alpine # 実行環境を固定。latestは厳禁。事故の元です。
definitions:
# よく使うステップを定義して、DRY（Don’t Repeat Yourself）を徹底する
steps:
- step: &test-unit
name: Unit Test
caches:
- node
script:
- npm ci
- npm test
pipelines:
default:
- step: test-unit # 定義したステップを使い回す
branches:
main:
- step: test-unit
- step:
name: Deploy to Production
deployment: Production
script:
- pipe: atlassian/aws-s3-deploy:1.1.0 # 信頼されたPipeを活用する
variables:
AWS_ACCESS_KEY_ID: $AWS_KEY
AWS_SECRET_ACCESS_KEY: $AWS_SECRET
AWS_DEFAULT_REGION: ‘ap-northeast-1’
S3_BUCKET: ‘my-prod-bucket’
【プロの知見】なぜこれが必要か？
- Dockerイメージの固定: `latest`タグは、ある日突然パイプラインが壊れる最強の呪いです。必ずバージョンを固定してください。
- キャッシュ戦略: `caches: – node` を忘れると、毎回の`npm install`で数分をドブに捨てることになります。
—
2. 開発スピードを劇的に高める「裏技」と設定
隠れたキーボードショートカット
Bitbucketの画面を開いて `Shift + ?` を押してみてください。ショートカット一覧が出ます。特にPRレビュー中に `k`（前のファイル）や `j`（次のファイル）で移動し、`a` でコメントを残す癖をつけるだけで、レビュー速度は体感で2倍になります。
「神プラグイン」の活用
- Atlassian Pipes: 自分でシェルスクリプトを書く前に、[Bitbucket Pipe Registry](https://bitbucket.org/product/features/pipelines/integrations)を確認してください。AWS, GCP, Slack, SonarCloudなど、枯れた実装が公式レベルで提供されています。車輪の再発明は、CI/CDでは悪です。
—
3. チーム開発で絶対に守るべき「3つの鉄則」
① 環境変数の「リポジトリ隔離」
GUIから設定する環境変数は便利ですが、管理不能になりがちです。
- 機密情報: 必ず「Secured」フラグを立てること。
- 構成情報: `bitbucket-pipelines.yml` の `variables` に記載できるものは、リポジトリに含めて可視化する（機密情報は除く）。
② 「失敗の可視化」をSlackに飛ばす
パイプラインが落ちた時、Bitbucketの画面を見に行くのは遅いです。`after-script` を使い、失敗時のみ通知を飛ばす設定を全プロジェクトに共通化してください。
after-script:
- pipe: atlassian/slack-notify:2.0.0
variables:
WEBHOOK_URL: $SLACK_WEBHOOK_URL
MESSAGE: ‘Pipeline failed: $BITBUCKET_BUILD_URL’
③ パイプライン・アズ・コードの共有化
チームが複数ある場合、`bitbucket-pipelines.yml` をコピペしてはいけません。
「共通設定用のリポジトリ」を作成し、そこからテンプレートを読み込むか、CI/CDの構成ルール（命名規則、ステップ順序）をドキュメントではなく「設定ファイル」としてリポジトリに保存・共有してください。
—
4. 最後に：テックリードからのアドバイス
CI/CDを構築する際、「いかに早く壊すか」を意識してください。
テストが遅ければ、それはテストではなく「待ち時間」です。`parallel`（並列実行）を使い、テストを分割し、フィードバックループを極限まで短くすること。
「10分で構築する」のはスタートラインに過ぎません。そこから、いかに「1分で失敗に気づき、1分で修正デプロイできるか」という高みを目指してください。
あなたのパイプラインは、あなたのチームのエンジニアリング・レベルそのものです。妥協なき設計を。応援しています。