Bitbucket Pipelinesの「Deployment Environments」を使い倒せ：リリース管理を「カオス」から「可視化」へ昇華させる技術
こんにちは。現場の泥臭い課題をCI/CDでねじ伏せてきたテックリードです。
君たちのチームでは、リリース状況をSlackの通知ログや、誰かの「今、何が入ってる？」という質問で管理していないか？ もしそうなら、それは「可視化」ではなく「単なる追跡」だ。
Bitbucket Pipelinesの隠れた名機能、「Deployment Environments（デプロイ環境）」を使えば、その状況は一変する。今回は、単なる設定解説にとどまらない、現場で即戦力となる「リリース管理の極意」を伝授する。
—
1. なぜDeployment Environmentsなのか？
多くのチームがCI/CDで陥る罠は、`bitbucket-pipelines.yml`の中に全てのデプロイロジックを密結合させてしまうことだ。
Deployment Environmentsを使うと、「どのコミットが、どの環境に、誰の手によってデプロイされたか」がGUI上で完全に分離・可視化される。さらに、環境ごとの変数管理が「変数グループ」として独立するため、本番用の秘匿情報を誤ってステージングで使うといった事故を物理的に防げる。
設定のベストプラクティス
`bitbucket-pipelines.yml`を、環境定義を前提とした設計に書き換える。
bitbucket-pipelines.yml
image: node:18-alpine
pipelines:
branches:
master:
- step:
name: Build and Test
script:
- npm install && npm run build
- step:
name: Deploy to Staging
deployment: Staging # ここが重要！環境定義と紐づく
script:
- ./deploy.sh –env staging
- step:
name: Deploy to Production
deployment: Production
trigger: manual # 本番は必ず手動トリガーに。事故を防ぐ鉄則だ。
script:
- ./deploy.sh –env production
2. 実践：チームの生産性を底上げする「設定ハック」
変数管理の「環境分離」戦略
GUIの `Repository settings > Deployments` で設定できる環境変数は、必ず「Secured（暗号化）」にしておけ。そして、ネーミング規則を徹底する。
- `API_KEY` ではなく `STAGING_API_KEY`, `PRODUCTION_API_KEY` のように環境名をプレフィックスにするのではなく、Deployment Environments機能に任せて同じキー名（`API_KEY`）を環境ごとに定義するのが正解だ。
- これにより、コード側は「どの環境にいるか」を意識せず、常に同じ環境変数を読み込むだけで済む。
開発スピードを加速させる「神プラグイン・設定」
- Bitbucket Pipelines Status: ブラウザの拡張機能で、Pushのたびにパイプラインの状態をアイコンで把握せよ。
- `pipeline-id` の活用: スクリプト内で環境変数 `$BITBUCKET_BUILD_NUMBER` を使って、Dockerイメージのタグやログの保存先に含めること。後から「あの時のデプロイ」を特定する速度が10倍になる。
—
3. 現場で震えるほど役立つ「チーム開発の作法」
1. 「デプロイ待ち」の可視化を徹底する
Bitbucketの画面右側にある「Deployments」ダッシュボードを、チームの朝会で必ず開け。誰がどのブランチをどの環境に流したか、GUI上のタイムラインを見るだけで「誰が今ボトルネックになっているか」が一目瞭然だ。
2. 環境ごとの「ロック」機能を悪用せよ
重要なリリース作業中に別のコミットが紛れ込むのを防ぐため、Deployment設定の「Environment lock」を活用する。本番デプロイ中はステージングから本番への追従を一時的にロックすることで、意図しない上書きを防止できる。
3. YAMLのDRY化（AnchorとAlias）
`bitbucket-pipelines.yml`が長大化したら、YAMLのAnchor機能を使って共通ステップを抽象化せよ。
共通設定を定義
definitions:
steps:
- step: &build-test
name: Build & Test
script:
- npm install
- npm test
pipelines:
default:
- step: build-test # 再利用
- step:
name: Deploy to Staging
deployment: Staging
script:
- echo “Deploying…”
—
結論：ツールを使いこなすのは「思想」である
Deployment Environmentsは、単なる管理機能ではない。これは「デプロイという儀式を、誰でも安全に実行できる日常業務に変える」ためのインフラだ。
GUIで現在の状況を可視化し、パイプライン定義をクリーンに保つ。この小さな積み重ねが、チームのデプロイ頻度を上げ、リードタイムを極限まで縮める。
さあ、今すぐ `bitbucket-pipelines.yml` を開き、`deployment` キーを記述してくれ。その一行が、君たちのチームの歴史を変えるかもしれない。
もし設定で行き詰まったら、いつでも聞け。CI/CDの泥沼から引き上げる準備はできている。