こんにちは！
先日最終話が放映された Dr.STONE 2 期が始まった頃、先が気になりすぎて漫画版を大人買いした CTO室 鹿児島オフィスチームのよしこ @yoshikouki です。これぞ社会人の嗜みだなと感慨深くなった30歳の春。
今回は私が運用・開発に携わっているホスティング事業部で Slack ワークフローと GitHub Actions を組み合わせて業務を改善しましたので紹介したいと思います。本改善は、サービスの本番環境に近いステージング環境へのデプロイ作業を Slack 上で行えるようにして、デプロイのための環境構築を不要にしたことに加えて必要なステップを 1 つだけにすることができました。
これまでステージングデプロイの問題点
日々の開発・運用において、本番環境に近い環境での動作確認・検証作業はリリースフローで必須の工程です。私が携わっているロリポップ・ヘテムル・ムームードメインの 3 サービスでは、その工程をステージング環境で行っています。
そのためにローカルで変更したコードをステージング環境へデプロイする必要があるのですが、普段はデプロイツールの Capistrano を手元のPCで使用してデプロイしていました。
しかし、この工程になかなかクセがあり、次のような問題点がありました。
- Capistrano を使用するので Ruby のローカル環境構築が必要だった (リポジトリ毎にバージョン管理が必要)
- デプロイのためだけに ssh 権限が必要なので、ステージングデプロイする人 × 各ホストの数だけ ssh 鍵を設置するタスクが必要だった
- ローカルのデプロイ環境が何かの拍子に壊れることが結構あり、そのたびに復旧作業や再構築のタイムロスが発生していた
- 複数人が同時に同じリポジトリの作業を行うこともあるため、作業を宣言するフローや先約の作業状況を確認するフローが発生していた
そこでこれらの解決を図り、ステージングデプロイをローカルからではなく Slack 上から行えるように変更しました。
実際にどのように改善されたのか、改善前後の工程で比較してみます。
環境構築についての比較
改善前
- リポジトリをクローンする
- Ruby の環境を整える
- bundle install する
- ssh 鍵をステージングホストへ登録して ssh できるか確認する
- cap コマンドの動作を確認する
改善後
- 不要 (※ コーディングにクローンは必要ですがステージングデプロイの環境構築としては不要)
まずデプロイ環境構築のタスクについての比較です。なんと不要になりました。
呼び出しは Slack から行い、コマンド実行は GitHub Actions 上で行われますので、作業 PC の事前準備は Slack さえ入っていれば不要になりました。
以前は、パートナー入社に伴うセットアップや作業 PC のリース契約更新による定期的な置き換えの度にデプロイ環境の構築が必要でしたが、本改善によってその作業がなくなって効率化されています。
デプロイフローについての比較
改善前
- Slack で使いたいリポジトリのステージング環境が使われていないかチェックする
- 近い時間で使っている人がいたら「まだステージング環境を使っていますか？」と確認・調整する
- Slack で「〇〇〇〇のステージング環境使います」と宣言する
- ローカルでデプロイコマンド
cap 〇〇〇〇 deployを実行する
改善後
- Slack ワークフローでリポジトリ・ブランチ名・使用時間を入力してステージングデプロイする
- もし誰かが使用中ならエラーが通知されてデプロイが中止される (設定した使用時間を過ぎたら自動的に解除)
以前のデプロイフローに慣れてしまっていたのでシュッとデプロイできていたように感じていましたが、1 ステップになってから改めてふりかえると、思ってたよりも時間がかかっていたことに気が付きました。
特に「1. 先に使っている人に確認・調整」に時間をとられがちでした。「そんなに急ぎではないからメンションを飛ばすほどではないけど、何時頃終わるのか知りたいからとりあえず聞いておこう」とメッセージを送ったものの相手が気付かず (逆にこちらが気付かない場合も)、実はステージング検証終わっていたのに数十分のタイムロスをしてたということも日常的に起きていました。
仕組みで解決できる時間なのでもったいなかったです。
どのようにして改善したのか
さて、ここからはどのようにデプロイ環境を改善したのかという話をします。
実際の操作画面と流れ
-
特定チャンネルのチャット左下にある「ショートカット (雷マーク)」をクリックし、登録してあるワークフローを選択します (実際はリストメニュー上部に表示されるので検索は不要)
-
表示されたモーダルに必要事項を記入して Submit ボタンをクリックします
-
Slack に宣言メッセージと actions-bot というアプリへのコマンドが送信されて、アプリが作動します
-
actions-bot から GitHub Actions のワークフロータスクが呼び出されてステージングデプロイが始まります
以上が改善後の流れになります。ユーザーが操作するのは 1 と 2 のステップだけです。
実装方法
必要なものは 3 つです
- Slack に actions-bot を導入
- GitHub Actions にステージングデプロイのワークフロー (repository_dispatch) を作成
- Slack に actions-bot を呼び出すワークフローを作成
Slack に actions-bot を導入
まず 弊社シニア・プリンシパルエンジニアの @pyama86 が作成した github-actions-trigger-bot (以下 actions-bot) を Slack に導入します。導入手順は紹介記事やリポジトリをご参照ください。
GitHub Actions にステージングデプロイのワークフローを作成
次にステージングデプロイを導入したいリポジトリの GitHub Actions にステージングデプロイのワークフローを作成します。actions-bot では GitHub Actions の repository_dispatch という仕組みを利用していますので、on 句に repository_dispatch を設定します (types は任意。Slack からの呼び出しに使用)。
on:
repository_dispatch:
types: [staging-deploy]
公式ドキュメント: Repositories
Slack に actions-bot を呼び出すワークフローを作成
最後に Slack ワークフローを作成します。参考までに今回作成した設定をお見せします。このワークフローはユーザーからの入力情報を actions-bot を作動させるコマンドへ変換するだけですので、比較的シンプルです。
今回のデプロイ先はステージング環境だけでしたので、 stage:task と固定値を指定しています。もし integration や development などの環境へもデプロイさせたい場合は、stage に入力値を持たせることで actions-bot 経由で GitHub Actions へ入力値を渡すことができます。
まとめ
今回は Slack ワークフローと GitHub Actions を組み合わせることで、日常のタスクを効率化したケースを紹介しました。実装後、ホスティング事業部のパートナーから便利だという声をいただき、積極的に活用してもらっています。
GitHub Actions と Slack ワークフローとを組み合わせることによって、デプロイ作業以外にも様々なタスクを省ステップ化・自動化できるようになります。とても便利な上に運用面でも利があります。
「あ、この作業自動化出来るかも」と閃いたときが吉日です。みなさんも是非試してみてください！