Bitbucketを「ただのGitサーバー」で終わらせるな：ブランチ権限で構築する鉄壁のDevOpsパイプライン
多くのチームがBitbucketを単なるコードの置き場として使っている。だが、それはフェラーリで近所のコンビニに行くようなものだ。
Bitbucketの真価は、「誰が、どこに、どのような状態でコードを流し込むか」をコードベースで統制できる点にある。本稿では、リリース事故を撲滅し、開発者の認知負荷を最小化するための「ブランチ権限の極限設定」を伝授する。
—
1. ブランチ制限の設計思想：階層による「権限の非対称性」
全てのブランチに一律のルールを適用するのは悪手だ。我々は以下の3階層で権限を切り分けるべきだ。
A. プロダクション・ゲート（master/main）
- 権限： 「書き込み」は一切禁止。管理者であっても直接プッシュさせない。
- 必須設定：
- Pull Request Required: 必須。
- At least 1 approval: 必須（Seniorエンジニア以上の承認を条件にする）。
- Successful builds: 必須。CIパイプラインがグリーンであること。
- Reset approvals on new commits: 最重要。 コードが修正されたら承認をリセットし、再レビューを強制する。
B. ステージング・ゲート（develop）
- 権限： 特定のCIサービスアカウントのみプッシュ可能、あるいは特定グループのみ許可。
- 必須設定：
- 開発者の直接プッシュを禁止し、PRベースの開発フローを強制。
- マージ戦略を「Squash」に固定し、Gitログを綺麗に保つ。
C. フィーチャー・ゲート（feature/）
- 権限： 開発者は自由に行き来可能。
- 必須設定：
- 特に制限は設けないが、`branching model`を設定し、命名規則を強制する。
—
2. 現場で震えるほど役立つ「高度なハック」
特定のパスに対する書き込み制御
Bitbucketの`Branch Permissions`と`Code Insights`を組み合わせれば、「特定のディレクトリ（例: `/infra` や `/docs`）の変更には、必ずSREチームの承認が必要」というルールを作れる。
これには `CODEOWNERS` ファイルを併用するのがベストプラクティスだ。
.bitbucket/CODEOWNERS
/infra/ @sre-team
/src/ @backend-team
/frontend/ @frontend-team
このファイルをルートに置くことで、該当ディレクトリの変更時に自動で正しいレビュアーがアサインされる。
タグ作成の「権限ロック」
タグはリリースそのものだ。誤って上書きしたり、ゴミタグを作らせないために、ワイルドカードによるタグ制限をかけること。
- `refs/tags/` への書き込みを「管理者のみ」に限定。
- 自動リリースツール（Semantic Release等）のサービスアカウントのみがタグを作成できるように設定する。
—
3. 生産性を劇的に向上させる「神ツール・設定」
キーボードショートカットを脳に焼き付けろ
マウスを触る回数を減らせ。これが開発スピードの源泉だ。
- `a` : PR画面で承認（Approve）
- `c` : コード上でコメント追加
- `j` / `k` : ファイルリストの上下移動
- `Shift + ?` : 全ショートカットを表示（毎日見よ）
入れるべき「神プラグイン」
- Bitbucket Smart Commits: コミットメッセージに `JIRA-123 #comment fix typo` と書くだけで、JiraとBitbucketが勝手に連携する。これを使わない手はない。
- Refined Bitbucket: UIを圧倒的に使いやすくするブラウザ拡張。画面の占有率を最適化し、レビュー速度が30%は向上する。
—
4. 設定のコード化：Bitbucket APIによる自動化
GUIで設定をポチポチするのは一度きりだ。チーム規模が大きくなれば、リポジトリの設定は `bitbucket-pipelines.yml` とセットでスクリプト管理すべきだ。
設定反映の自動化例 (curl):
ブランチ制限をAPIで強制適用するスクリプトの一片
curl -X POST “https://api.bitbucket.org/2.0/repositories/{workspace}/{repo}/branch-restrictions” \
-H “Authorization: Bearer $TOKEN” \
-H “Content-Type: application/json” \
-d ‘{
“kind”: “push”,
“pattern”: “master”,
“users”: [],
“groups”: [“senior-engineers”],
“access_key”: null
}’ # masterへのpushはseniorグループのみ許可
—
最後に：テックリードからの提言
ツールは「縛るため」にあるのではない。「安心して爆速で開発するため」にある。
権限を厳格にすることで、「masterを壊したらどうしよう」という不安からエンジニアを解放せよ。それが結果として、チームのデプロイ頻度を上げ、リードタイムを短縮する。
ルールは一度決めて終わりではない。四半期ごとに「この制限は我々を遅くしていないか？」と問い直すこと。それが、真に強いDevOps組織のあり方だ。
さあ、今すぐブランチ設定を見直し、コマンドラインに集中できる環境を構築せよ。