前提:
- https://github.com/motemen/git-pr-release を使っている
- 原則として全ての Pull Request は develop ブランチに対してマージされ、リリース作業時に develop ブランチが master ブランチにマージされる
- ただし緊急性の高い hot fix は直接 master ブランチにマージされる
- hot fix が発生したあと master にはあるが develop にはない commit ができてしまうのでそれを develop にバックポートしなくてはならない
- バックポートは Jenkins job により merge master into develop というそのまんまの名前の Pull Request が自動的に作られる
のだが、 Quipper 開発チームはだいたい Pull Request をマージしたあとトピックブランチもその場で消しており、手癖でついうっかり master ブランチを消してしまう、という事故が何度も起こっていた。 master ブランチがないと次回のリリース作業時に git-pr-release がコケてしまい、 master が消された Pull Request を探し出して restore しなければならず、うざい。
なので、 ad hoc だが master ブランチが削除されたら GitHub から Delete イベントの webhook を受け取り Slack で通知するウェブアプリケーションを書いた。
仕組みと流れ:
- これ用に Slack の Incoming Webhook を一個作る
- Incoming Webhook の宛先を @slackbot にする
- すると自分自身宛に Direct Message が届く
- または通知用の channel / private group を必要に応じて作る
- Slack 現状では Integration 経由で post されたメッセージの本文に @mention や highlight が含まれていても desktop 通知が飛んでこない(ので気付かず意味がない)なのでこの通知専用の channel / group を作ってそこに join し、そこへの全ての post について desktop 通知を受け取る設定に変更する、という運用にした
- channel / group を作る利点は、 1) channel topic / channel purpose などの欄にメモを残せる(もろもろ情報まとめた Google Docs へのリンクとか) 2) 複数人が通知を受け取る体制にもできる
- ウェブアプリケーションを Heroku にデプロイして Incoming Webhook の投稿用 URL を環境変数にセットする
- GitHub で「master ブランチが消されたら通知してほしいリポジトリ」の設定画面から新しい Webhook を追加する
で、 master ブランチが消されると通知がきて気づくので俺が restore しにいくというオペレーションを確立できた(テスト用リポジトリではうまくいった)
GitHub API を使って自動で restore までさせることも考えたが、
- 本当に master を消す必要がでたとき人知れず勝手に復活する挙動は謎すぎてよくない(webhook の件を知らないひとが思いつくのは不可能だろう)
- この程度のことにそこまで込み入った作り込みをするのはオーバースペック
- 自分自身にあえてちょっと面倒くささを課すことで周囲に注意を促すモチベーションの維持につながる
- 単純に自分が「機械に人間が行動をコントロールされている」的なシチュエーションが好き
などの理由から人力に頼る部分を多く残す(そのかわりに仕組みも実装も単純な)形に落ち着いた。