LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログです。

ChatWork Webhookを利用したデプロイフロー

Webエンジニアの森脇です。

LCLでは、ChatWork + Hubotを利用してデプロイをしていましたが、ChatWorkがWebhookに対応したため、Hubotを廃止しました。ChatWork Webhookを利用して、どのようなデプロイフローとなっているかを紹介します。

なお、Hubotを利用した構成は過去のブログに記載しています。

techblog.lclco.com

変更理由

Hubotを利用した構成でも、そこまで困ってはいなかったのですが、強いて言えば以下の理由があります。

  • Webhookではないため、特定のルームをChatwork APIでポーリングして発言のを検知する必要がある
  • API呼び出し回数に制限があるため、ポーリング間隔を長くする必要があり、発言してからBotが反応するまでタイムラグがある
  • 今後の拡張のため、慣れているRubyを使いたかった

構成

EC2上に、Webhookを受け付けるRailsプログラムを用意し、そこで一連のデプロイフローを実現しています。

f:id:lcl-engineer:20180329154406p:plain

EC2は、ChatWork Webhook送信元のIPのみを通すようにしています。公式には送信元のIPは公表されていない(はず)なので、アクセスログがから抽出したものをホワイトリストに入れています。

実装

ChatWork Webhookの実装は、下記の記事で記載しています。

techblog.lclco.com

署名検証は少し面倒なので、自作するのではなく、chatwork_webhook_verify gemを利用させて頂いたほうが良かったなと感じてます。

github.com

デプロイフロー

デプロイは以下のようなフローで行っています。

  • ChatWorkでデプロイ依頼コマンドを打つ
  • デプロイ対象の確認
  • Dangerの警告確認
  • ChatWorkでデプロイ実行コマンドを打つ

ポイントを紹介します。

デプロイ対象の確認

プルリクエストのマージ漏れ、意図しない他人のマージが入っていないかを確認するため、今からデプロイされるプルリクエストをチャットへ流しています。

f:id:lcl-engineer:20180329155744p:plain

Danger警告の最終確認

過去の記事でも紹介しましたが、Dangerを使ってプルリクエストの検証をしています。

techblog.lclco.com

Dangerはプルリクエストにコメントをしてくれますが、コメントが埋もれてしまい見逃すケースがありました。そのため、デプロイ前にチャットへ流して最終確認しています。

f:id:lcl-engineer:20180329155029p:plain

デプロイブロック

デプロイ中には、他のデプロイを防ぐ仕組みも用意しています。デプロイ中の状態管理は、Redisを利用しています。

f:id:lcl-engineer:20180329160119p:plain

まとめ

ChatWorkもWebhookが用意され、ようやく色々なことがやりやすくなってきました。LCLでは、サービス開発はもちろん、業務効率化にも継続的に取り込んで行っています。少しでもご興味のあるインターン・エンジニアの方は採用ページからご連絡頂けると幸いです。