Bitbucketの「プルリクエスト・デコレーター」を自作せよ：CIをただの「合否判定機」にするな
多くのチームがCIを「テストが通ったか落ちたか」を判定するだけのゲートキーパーとして扱っている。だが、真のDevOpsエンジニアは知っている。CIとは、エンジニアへのリアルタイムなコーチングツールであるべきだということを。
今回は、Bitbucketのプルリクエスト（PR）画面に、自前の解析ロジックを直接「インサイト（Insights）」や「インラインコメント」として流し込む、カスタム・デコレーターの実装術を伝授する。
—
1. なぜ「自作デコレーター」が必要なのか？
標準のリンターやテストカバレッジだけでは、ビジネスロジックの不整合や、チーム独自のアーキテクチャのアンチパターンは防げない。
- ドキュメントとの整合性: API定義（OpenAPI）と実装の乖離を自動検知。
- ビジネスロジックのガードレール: 特定のメソッドを呼ぶ際には必ず特定のチェックを通しているか。
- セキュリティの文脈依存チェック: 秘匿情報がハードコードされていないか、特定の脆弱性パターンが含まれていないか。
これらを「CIのログをわざわざ見に行かせる」のではなく、「PR画面上に直接表示させる」ことで、開発者のコンテキストスイッチを最小化し、爆速でのレビューを実現する。
—
2. 実装の要：Bitbucket APIを活用した「インサイト」の注入
Bitbucket Pipelines（またはJenkins等のCI）から、`POST /rest/insights/1.0/projects/{projectKey}/repos/{repositorySlug}/commits/{commitId}/reports/{reportKey}` を叩くのが最短距離だ。
実践：カスタム・デコレーターの構成例（Pythonスクリプト）
以下のスクリプトをCIパイプラインの最後に組み込む。
import requests
import json
Bitbucket Cloud API認証設定
BITBUCKET_API = “https://api.bitbucket.org/2.0”
AUTH = (“user”, “app-password”)
def post_insight(commit_id, data):
url = f”{BITBUCKET_API}/repositories/{REPO_FULL_NAME}/commit/{commit_id}/reports/custom-lint-001″
# 独自の解析結果をペイロードに載せる
payload = {
“title”: “Architectural Guardrail Check”,
“result”: “FAILED”, # PASS or FAIL
“details”: “Controller層で直接DBを叩くことは禁止されています。”,
“reporter”: “DevOps-Bot”,
“link”: “https://wiki.internal/guidelines/architecture”
}
requests.put(url, json=payload, auth=AUTH)
解析結果をAPIへ送信するパイプライン実行例
—
3. 現場を劇的に変える「生産性ハック」
① Bitbucket PR画面での神ショートカット
意外と知られていないが、PR画面では以下のキーで爆速レビューが可能だ。
- `j` / `k`: PR内のファイルリストを上下移動
- `o`: 選択したファイルを開く/閉じる
- `a`: コメントを追加
- `p`: 次のファイルへ
② 絶対に入れるべき「神プラグイン/ツール」
- Bitbucket Browser Extension (Refined Bitbucket): PR画面のUIを劇的に改善し、ツリー表示を有効にする必須ツール。
- Husky (Pre-commit hook): CIに投げる前に、ローカルでNode/Python環境のLintを強制する。CIを回す回数を減らすのが最大かつ最強の高速化だ。
—
4. チーム開発における「設定の共有化」ルール
設定ファイルを個人のPCに依存させるのはNGだ。以下の構成をリポジトリルートの `.bitbucket/` に集約せよ。
推奨ディレクトリ構成:
.bitbucket/
├── pipelines/
│ └── quality-gate.sh # 全員共通のチェック用スクリプト
└── settings/
├── lint-rules.yaml # チーム共通の規約
└── pr-template.md # PR作成時の必須テンプレート
PRテンプレートの極意:
ただの空欄にするな。以下の項目をテンプレートに強制し、エンジニアの「思考の枠組み」を固定せよ。
- 影響範囲: どのモジュールが影響を受けるか
- テスト: どのようなテストコードを追加したか
- 負債: 今回見送った改善点は何か（これを書かせると、後で拾い上げやすくなる）
—
5. テックリードからの提言：CIを「規律」にする
多くのチームが「テストが落ちたから直す」という受動的な開発をしている。しかし、デコレーターを使って「なぜその修正が必要なのか」をコードの行単位で指摘し続けると、チーム全体のコード品質は数ヶ月で劇的に向上する。
CIは単なる自動化ツールではない。チームのアーキテクチャや規約を継承するための「生きているドキュメント」である。
今日から、あなたのCIパイプラインに「独自のインサイト」を流し込んでみてほしい。エンジニアが「あ、ここ直さなきゃ」とPR上で気づくたびに、あなたのチームの開発スピードは加速していくはずだ。
—
追伸:
もし大規模チームでBitbucketのパフォーマンスに不満があるなら、`bitbucket-pipelines.yml` のキャッシュ設定（`caches`）を徹底的に見直せ。依存関係の解決時間を削るだけで、年間で数千時間の節約になる。これについてはまた別の機会に深く語ろう。