Webエンジニアの森脇です。
LCLでは、ChatWork + Hubotを利用してデプロイをしていましたが、ChatWorkがWebhookに対応したため、Hubotを廃止しました。ChatWork Webhookを利用して、どのようなデプロイフローとなっているかを紹介します。
なお、Hubotを利用した構成は過去のブログに記載しています。
変更理由
Hubotを利用した構成でも、そこまで困ってはいなかったのですが、強いて言えば以下の理由があります。
- Webhookではないため、特定のルームをChatwork APIでポーリングして発言のを検知する必要がある
- API呼び出し回数に制限があるため、ポーリング間隔を長くする必要があり、発言してからBotが反応するまでタイムラグがある
- 今後の拡張のため、慣れているRubyを使いたかった
構成
EC2上に、Webhookを受け付けるRailsプログラムを用意し、そこで一連のデプロイフローを実現しています。
EC2は、ChatWork Webhook送信元のIPのみを通すようにしています。公式には送信元のIPは公表されていない（はず）なので、アクセスログがから抽出したものをホワイトリストに入れています。
実装
ChatWork Webhookの実装は、下記の記事で記載しています。
署名検証は少し面倒なので、自作するのではなく、chatwork_webhook_verify gemを利用させて頂いたほうが良かったなと感じてます。
デプロイフロー
デプロイは以下のようなフローで行っています。
- ChatWorkでデプロイ依頼コマンドを打つ
- デプロイ対象の確認
- Dangerの警告確認
- ChatWorkでデプロイ実行コマンドを打つ
ポイントを紹介します。
デプロイ対象の確認
プルリクエストのマージ漏れ、意図しない他人のマージが入っていないかを確認するため、今からデプロイされるプルリクエストをチャットへ流しています。
Danger警告の最終確認
過去の記事でも紹介しましたが、Dangerを使ってプルリクエストの検証をしています。
Dangerはプルリクエストにコメントをしてくれますが、コメントが埋もれてしまい見逃すケースがありました。そのため、デプロイ前にチャットへ流して最終確認しています。
デプロイブロック
デプロイ中には、他のデプロイを防ぐ仕組みも用意しています。デプロイ中の状態管理は、Redisを利用しています。
まとめ
ChatWorkもWebhookが用意され、ようやく色々なことがやりやすくなってきました。LCLでは、サービス開発はもちろん、業務効率化にも継続的に取り込んで行っています。少しでもご興味のあるインターン・エンジニアの方は採用ページからご連絡頂けると幸いです。