SlackとGitHub Deployments APIで疎結合なChatOpsを実現する


下記で紹介している /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.

integrations/slack: Bring your code to the conversations you care about with the GitHub and Slack integration

this.aereal.org

Deployments APIが出た頃に上記記事を書いてもう5年が経とうしている中、最近いろいろなグッズが進化してタイトルにあるような良い塩梅のChatOpsが実現できそうなのでそれのメモ。

登場人物

Deployments APIとGitHub Actions

このAPIだけではなんらかの仕事は行われず、ただWebhookのイベントが通知されるだけのAPIになっている。
この説明だけ聞くと「ふーん」というかんじだけれども、各種Webhookイベントに応じてなんらかのタスクが実行でき、しかもCI用に払い出されたAPIキーが振ってくるというGitHub Actionsの存在でできることの幅や手軽さが変わってくる。

実際のWorkflow YAMLを見るのが早いと思う: https://github.com/aereal/actions-playground/blob/master/.github/workflows/deploy.yml
on: deployment を書いておけば、Deploymentが作られた時にこのYAMLの内容が実行される。

内容の詳細は:

……となっている。

この例では活用していないが、Deployment APIのパラメータにはtaskやenvironmentがあるのでステージング環境か、アプリケーションのデプロイの他にDBのスキーマ更新などの付随するタスクも表現できたりなど、いろいろ使い出はありそうに見える。

Slackからデプロイ

では肝心のDeploymentはどうやって作るの、ということだけど、これまでは丁寧にcurlするしかなかったのが最近SlackのGitHub連携から作れるようになった。

/github deploy OWNER/REPOを実行するとこういう画面が出てきて:

n

リビジョンなどを埋めるとAPIが呼ばれる。

上記GitHub Actionsが設定されていれば、ピタゴラスイッチが動き出すという寸法。

Slackにはこういう通知が出る:

f:id:aereal:20191029121824p:plain

Deployment viewに期待

最近ひっそりとdeployment viewというものがベータリリースされている。これまで紹介してきたactions-playgroundの画面だとこういうかんじ: https://github.com/aereal/actions-playground/deployments

f:id:aereal:20191029121952p:plain

今は本当にログしか出てきていなくて味気が無いけれども、GitHub公式でこういうビューを作ろうとしているのはちょっと期待。

まあ仮にお蔵入りになってしまうとしてもDeployments APIを使ってちょっとしたビューを作るのはわりと楽だろう。

なぜ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のチェックが完了しなければデプロイが進められない、という制約も簡単に実現・移行できる。

そもそもなぜDeployments APIの話をしているのか

git の develop ブランチは必要なのか、またはリリースtagについて - Togetter

ここらへんでGit FlowなのかGitHub Flowなのかみたいな話が盛り上がり、そういえば最近Deployments APIが盛り上がっとるなということを思い出したのがきっかけ。

id:Songmuさんにこういうリプライもした:

実際、いま新しくやっているプロジェクトでもGitHub Flowに近いワークフローになっている。
コンテナワークロードになると同じリビジョンから作られる成果物を複数環境にデプロイが容易になるはずなので、アプリケーションの内容は同じなのに複数リビジョンが付くGit Flowは困ることが増えるなあ、という印象を抱いていた。

とはいえ上記Togetterまとめにあるとおりgit-pr-releaseは様々な点で便利なのは間違いない。が、本質は差分の可視化といったところなどにあるはずでPull RequestやGit Flow的なブランチ運用が根幹にあるものではないと思っていた。

そんなモヤモヤを抱く中でDeployments APIが進化してきたので注目しているというかんじ。