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サービス
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 Statusをin_progressに更新し
- Firebase Cloud Functionsへデプロイ
- ここはアプリケーションによって変わる
- デプロイ作業の成否をDeployment Statusとして報告して完了
- if: always()を指定し、失敗した場合もこのstepが実行する
……となっている。
この例では活用していないが、Deployment APIのパラメータにはtaskやenvironmentがあるのでステージング環境か、アプリケーションのデプロイの他にDBのスキーマ更新などの付随するタスクも表現できたりなど、いろいろ使い出はありそうに見える。
Slackからデプロイ
では肝心のDeploymentはどうやって作るの、ということだけど、これまでは丁寧にcurlするしかなかったのが最近SlackのGitHub連携から作れるようになった。
/github deploy OWNER/REPO
を実行するとこういう画面が出てきて:
n
リビジョンなどを埋めるとAPIが呼ばれる。
上記GitHub Actionsが設定されていれば、ピタゴラスイッチが動き出すという寸法。
Slackにはこういう通知が出る:
Deployment viewに期待
最近ひっそりとdeployment viewというものがベータリリースされている。これまで紹介してきたactions-playgroundの画面だとこういうかんじ: https://github.com/aereal/actions-playground/deployments
今は本当にログしか出てきていなくて味気が無いけれども、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がdeployment(APIだけあったやつ)のダッシュボードをベータリリースしているので、それがリッチになると近そうですね https://help.github.com/en/github/administering-a-repository/viewing-deployment-activity-for-your-repository …
実際、いま新しくやっているプロジェクトでもGitHub Flowに近いワークフローになっている。
コンテナワークロードになると同じリビジョンから作られる成果物を複数環境にデプロイが容易になるはずなので、アプリケーションの内容は同じなのに複数リビジョンが付くGit Flowは困ることが増えるなあ、という印象を抱いていた。
とはいえ上記Togetterまとめにあるとおりgit-pr-releaseは様々な点で便利なのは間違いない。が、本質は差分の可視化といったところなどにあるはずでPull RequestやGit Flow的なブランチ運用が根幹にあるものではないと思っていた。
そんなモヤモヤを抱く中でDeployments APIが進化してきたので注目しているというかんじ。