Leaner 開発チームの黒曜(@kokuyouwind)です。
Leaner ではチャットボットの Ruboty を Heroku 上の無料 Dyno で動かしていたため対応が必要だったのですが、いろいろ検討した結果 Ruboty 自体を停止することにしました。
今回はこの辺の経緯や対応をまとめます。
社内 Ruboty のお仕事
Leaner では GitHub 上のブランチとデプロイ先環境を以下のように紐付けて管理しています。
- develop ブランチ: 開発環境
- main もしくは staging ブランチ: ステージング環境 [1]
- release ブランチ: 本番環境
各環境へのデプロイは自動化されているため、 develop から main や main から release への Pull Reqeust を作成してマージすることで変更をリリースしていくことができます。
しかしながら、自分が入社したときにはデプロイ用 Pull Request の作成が手作業であり、サーバとフロントでリポジトリが分かれていたのもあってかなり面倒な作業になっていました。
そこでこの作業を自動化するために Ruboty を導入し、Slack 上でボットに話しかけるだけで Pull Request を作れるようにしました。
その名も rengokusan です。深い意味はありません。
rengokusan に「リリース準備」と話しかけることで、各リポジトリに一括でデプロイ用 Pull Requst を作ってくれます。
プラグインとしては ruboty-github と ruboty-alias の組み合わせで実装しています。[2]
なお一時期は Slack RTM 周りの変更で動かなくなったため GitHub Actions に載せ替えたりしたのですが、手動での GitHub Actions 起動が面倒だったため問題解消後は Ruboty に戻りました。
とはいえ Ruboty は他の目的で全く使っておらずデプロイ専用になっており、このためだけに Heroku からの移行作業をしたり Heroku の有料契約をするかというと、かなり微妙な状態になっていました。
デプロイ Pull Request の自動作成
いい方法がないかとネットの海をさまよっていたところ、以下の記事を見つけました。
git-pr-release 自体は前述の GitHub Actions 載せ替え時に使っていたのですが、既存のデプロイ Pull Request がある場合にうまく動かないと思いこんでおり手動実行にしていました。
ところがこちらの記事によると、既にデプロイ Pull Request がある場合はそれの説明文を更新してくれるので on: push で自動実行しても問題ないようです。
試してみました。
なるほど完璧じゃねーの。
開発ブランチに新しい差分が入るたびに詳細文が更新されており、デプロイしたいときには既にできている Pull Request をマージするだけで良くなりました。
これで Ruboty のお仕事は不要になりそうです。 rengokusan には安らかに眠ってもらいましょう
デプロイ Pull Request の横断表示
デプロイについては大体解決したのですが、サーバサイドとフロントエンドのリポジトリが分かれているため「横断でデプロイ内容を確認したい」ときに少々不便です。
Ruboty では「リリース前」と話しかけることでリポジトリごとのリリース対象を教えてくれるようにしていました。
Notion の GitHub コネクト を使ったり色々試してみたのですが、実は GitHub にリポジトリ横断で Pull Request を見れる画面がありました。
全然意識してませんでしたが、確かにトップの一番上にでかでかと「Pull requests」ってタブがありますね。
標準だと「全リポジトリの自分が assign されている Pull Request」が表示されますが、検索条件は自由に設定可能です。ここで repo:[organization]/[repository] を指定すれば特定リポジトリの Pull Request を検索できました。 repo を複数指定するといずれかのリポジトリのものが OR 条件で出てくるようです。
ステージ環境へのデプロイ Pull Request を「ステージング反映」というタイトルで作っている場合は ステージング反映 is:open is:pr repo:[repoA] repo:[repoB] のようなフィルタを設定することで以下のように一覧を作ることができます。
ここから各リポジトリの Pull Request を開けばリリース内容を簡単に確認できますね。
検索条件は URL のパラメタに含まれているため、そのままコピーして Slack のブックマークに追加しておくとワンクリックで飛べて最高体験になります。
今度こそ rengokusan にゆっくり休んでもらえそうです。
置き換えた感想
Heroku からの移行先選定や移行作業を見込んでいたのですが、結果的には管理しやすい GitHub Actions に置き換えたうえでデプロイ作業の手間も更に減らせたため、良い形で対応できました。
Slack からの作業でも十分便利だったのですが、デプロイしようと思った時点でデプロイ用の Pull Request が既にあるというのは別次元の便利さでした。またリポジトリ横断で Pull Request を見られる画面も非常に便利で、フィルタを工夫することでいろいろなユースケースに使えそうです。
宣伝
Leaner ではデプロイプロセスを継続的に改善していきたいエンジニアを募集しています！
-
古いリポジトリでは歴史的経緯で main ブランチになっており、新しいリポジトリでは staging ブランチにしています。 ↩︎
-
大本の ruboty-github だとリリース用 Pull Request の詳細文がいい感じに出せないため、 fork して機能を拡張したものを利用しています。 ↩︎
Discussion