Bitbucketの「サーバーサイドフック」がない？なら、CI/CDでねじ伏せろ！現場で使える強制力の作り方
こんにちは。日々、コードとパイプラインの海を渡り歩いているエンジニアです。
Bitbucket Cloudを使っていると、オンプレミス版のBitbucket Server（Data Center）では使えた「サーバーサイドフック（Pre-receive hook）」が使えないことに頭を抱える瞬間がありますよね。「コミットメッセージにチケット番号を強制したい」「マージ前にlintを通したい」……こうした品質統制は、チームが大きくなればなるほど重要になります。
「サーバーサイドフックが使えないから諦める」なんて、プロの仕事ではありません。Bitbucket Pipelinesを「検問所」に変えてしまえばいいのです。
今日は、Bitbucket Cloudで「コミットルールを確実に守らせる」ための、最も賢く、かつ現場で即戦力となる戦略を伝授します。
—
1. なぜ「ローカル」だけではダメなのか？
よく「Husky（Git Hooks）」を使ってローカルでチェックする方法が紹介されますが、あれは「善意のプログラマー」に依存したセキュリティです。力技でスキップされたり、設定を消されたら終わりです。
私たちが目指すのは、「ルールを守らないコードは、決してmaster（main）に辿り着けない」という物理的な封鎖網です。これを実現するのが、PipelinesによるCI強制です。
—
2. 実践：Pipelinesを「検問所」にする設定
今回は、「コミットメッセージにチケット番号（例: `PROJ-123`）が含まれているか」をチェックするパイプラインを作ります。
`bitbucket-pipelines.yml` をリポジトリのルートに作成してください。
image: atlassian/default-image:latest
pipelines:
# プルリクエスト（PR）が作成・更新された時に発火
pull-requests:
”:
- step:
name: “Commit Message Convention Check”
script:
# 最新のコミットメッセージを取得
- LAST_COMMIT_MESSAGE=$(git log -1 –pretty=%B)
# 正規表現でチケット番号が含まれているか確認
- if [[ ! “$LAST_COMMIT_MESSAGE” =~ ^[A-Z]+-[0-9]+ ]]; then
echo “❌ エラー: コミットメッセージにはチケット番号(例: PROJ-123)が必要です。”
exit 1; # ここで終了コードを返すことでパイプラインを失敗させます
fi
- echo “✅ コミットメッセージの形式チェックOK！”
この設定のポイント
- `pull-requests` ブロック: ブランチへのプッシュ時ではなく、PR作成時をトリガーにすることで、マージの直前に「最終確認」を行えます。
- `exit 1` の魔法: パイプライン内で `exit 1` を叩くと、そのステップは「失敗」と見なされます。Bitbucketの設定で「成功しないとマージ不可」というブランチ制限をかけておけば、強制力は完成です。
—
3. HelloWorldを超えた「実戦的セットアップ」
コミットメッセージだけでなく、コードスタイル（lint）やテストも同じ考え方で強制できます。以下は、パイプラインに「静的解析」を追加する構成案です。
pipelines:
pull-requests:
”:
- step:
name: “Lint & Test”
image: node:18
script:
- npm install
- npm run lint # コードスタイルが汚いならここで落とす
- npm test # テストが落ちたら当然マージ不可
—
4. 仕上げ：Bitbucket側の「最後の鍵」
パイプラインで失敗させても、Gitのコマンドラインから無理やりマージしようとする猛者が現れるかもしれません。それを防ぐのが、Bitbucketの「ブランチ制限（Branch permissions）」です。
1. Bitbucketのリポジトリ設定へ行く。
2. 「ブランチ制限（Branch permissions）」を選択。
3. `main` ブランチに対してルールを追加。
4. 「最低限の成功したビルド（Minimum successful builds）」 にチェックを入れ、今回作成したパイプラインを指定する。
これで、「パイプラインが緑色にならない限り、ボタンが押せなくなる」という鉄壁のガードが完成します。
—
最後に：なぜこれが「楽」なのか？
「ルールを強制するなんて窮屈だ」と思うかもしれません。しかし、逆です。
コードレビューの際、レビュアーは「チケット番号の書き忘れ」や「インデントのズレ」といった人間がやるべきでないチェックから解放されます。 チームメンバーは「とりあえず動くコードを送れば、あとはパイプラインが教えてくれる」という安心感の中で開発に集中できるのです。
自動化の目的は「縛ること」ではなく「ミスに気づくまでの時間をゼロにすること」です。
これをマスターすれば、あなたのチームのコード品質は劇的に向上し、レビューの質も一段階高いレベルへ引き上げられるはずです。ぜひ、今日からあなたのリポジトリにこの「検問所」を設置してみてください。
それでは、良い開発ライフを！何か詰まったら、いつでも聞いてくださいね。