SlackとGitHub Deployments APIで疎結合なChatOpsを実現する (original) (raw)
下記で紹介している /github deploy というコマンドは2021年4月9日の更新で現行のSlack連携からは削除された。
Removed deploy command and notification support: Today, the functionality provided by deploy command is very limited and doesn't address all the scenarios. We are removing deploy command and notifications support as part of this version. We want to relook at the scenarios and build a more holistic experience that customers need.
Deployments APIが出た頃に上記記事を書いてもう5年が経とうしている中、最近いろいろなグッズが進化してタイトルにあるような良い塩梅のChatOpsが実現できそうなのでそれのメモ。
登場人物
- GitHub Deployments API
- GitHub Deployment View
- ひっそりベータリリースされている
- 実際のビューはこういうの: https://github.com/aereal/actions-playground/deployments
- いまはログが出るだけ
- SlackのGitHub integration
- 今年夏のアップデートで
/github deployment OWNER/REPOでcreate a deploymentできるようになった
- 今年夏のアップデートで
- GitHub Actionsとdeployment Webhook event
- 最近リフレッシュされたGitHubに統合されたCI/CDサービス
Slackからデプロイ
では肝心のDeploymentはどうやって作るの、ということだけど、これまでは丁寧にcurlするしかなかったのが最近SlackのGitHub連携から作れるようになった。
/github deploy OWNER/REPOを実行するとこういう画面が出てきて:
n
リビジョンなどを埋めるとAPIが呼ばれる。
上記GitHub Actionsが設定されていれば、ピタゴラスイッチが動き出すという寸法。
Slackにはこういう通知が出る:
なぜDeployments APIなのか
こういうChatOpsの類はずっと前からいくらでもあるし、Deployments APIの何が良いの? という向きもあるかもしれませんが、以下の点でとても魅力的だと思っています:
- チャット (Slack) 側の仕事内容が少ない = 移植性が高くコントローラブルな要素が多い
- チャットを介さない実行が容易
- Commit Statusなど既存のGitHubエコシステムと深く統合されて、今までの暮らしがスポイルされず、むしろ進化させられる
チャット側の仕事が少ないというのは、これまで見てきたように単にHTTP APIを呼び出しているだけなので、なにかうまく動かないということがそもそも起きにくい・起きたとしてもトレースがしやすい・実装の移植がしやすい、という点が嬉しい。
なんでもChatOpsにしたはいいがいざSlackが落ちると何もできないという事態に陥ることなく、いざとなればcurlを叩けば良いというのもポイントが高い。
またWebhookなどイベントベースのピタゴラスイッチはどこがホットスポットなのかわかりづらく全容を把握しづらくなってしまうことも多いけれど、Deployments APIとActionsの組み合わせだとGitHubが中央にあるので、とりあえずリポジトリを見れば概形がわかるというのも差別化ポイントになりうると思う。
さらにCommit Statusなど既に広く使われている機能などと統合されているというのも魅力。たとえばDeploymentにrequired_contextsを指定できるので、prchecklistのチェックが完了しなければデプロイが進められない、という制約も簡単に実現・移行できる。