Kesinの知見置き場

知見を共有していきたいじゃないですか

SRE-SET Automation Night #2にお邪魔してきました

カンファレンス・勉強会

2018/03/06に開催されたSRE-SET Automation Night #2へブログ枠として参加させて頂きました。

SRE-SET Automation NightはCIやテスト、Seleniumなどを使った自動化についてが主なテーマの勉強会です。
第1回目のときにも参加させて頂いたので、今回は2回目の参加でした。

会場に着いたのが早めだったので、まだ皆さんが集まっていないうちにケータリングの写真を撮らせて頂きました。 定番のお寿司もいいですが、たまにはこういう違ったおしゃれメニューもいいですね！

f:id:Kesin:20180306191120j:plain

今回の発表の中で特に自分が興味持った2つを紹介します。

AWS Lambdaで作る GitHub bot @siroken3

GitHubでもイベントに反応するbotをAWS Lambdaに構築するという発表でした。
おそらく公式ドキュメントだとこのあたりのことなのではないかと思います
https://developer.github.com/apps/getting-started-with-building-apps/

GitHub botができることの例として紹介されていたもの。

  • PRへのコメント
  • Issueの自動ラベリング
  • PRの内容チェック

Issueの自動ラベリングとか、自動クローズとかはOSSで最近見かけることがありますね。

botをLambda上に構築する仕組みは、GitHubのwebhookでAWS Lambdaを起動してLambdaに置いたスクリプトからGitHubのAPIを叩いて実現しているようです。 つまりこういう流れ。

Github(webhook) -> Amazon SNS(Topicsを設定) -> Lambda -> Github API

帰宅してからちょっと調べたら、似たような構成でGitHub -> Lambda -> Slackの連携を構築している方がいました。
https://qiita.com/ooharabucyou/items/2a3dca643f6b7783d665

注意点としては、GitHubと連携するためのpersonal access tokenはAWS KMSを使って暗号化しておき、Lambdaから使うときに復号化する必要があるようです。

今回の発表では、サンプルとしてissueにコメントすると単純に同じコメントをbotが返すecho botの作り方を紹介していました。
リポジトリはこちらのようです https://github.com/siroken3/SreSetAutomationNightVol2

echo botはissueにコメントされたタイミングでwebhookを受け取る必要があるのですが、webhookのデフォルトの設定だとpushしたタイミングでしか発火してくれないとのことです。
発表では、コメントされたタイミングでもwebhookが発火するようにcurlでリクエストを投げて設定を変更されていました。 調べてみたところ、リポジトリのsettingsからwebhookを設定するUIにもそれっぽいものがあったので、おそらくこれでもいけるのではないかと思います。

2018/03/08 追記
webhookの設定ではなく、Integration & servicesからAmazon SNSの設定をされているとのことでした。たしかにこちらだとUIから発火するイベントの選択はできないようでした。
訂正いたします

自動回帰テストフローとGitHub Apps @Quramy

こちらもGitHubと連携するbot(Apps)を使って、回帰テストフローを自動化したという内容でした。 少しややこしいのですが、@siroken3さんの発表とは異なるGitHub Appsという仕組みを使っています。
GitHubと連携するbot(Apps)には@siroken3さんのpersonal access tokenを使う方法とは別のGitHub AppsとOAuth Appsという2つの仕組みがあり、 この2つの違いはこのようになっているとのことです。

GitHub Appsの場合は個人のアカウントに紐付かないためチーム開発においてはOAuthより便利だということです。
公式のドキュメントだと多分このあたり
https://developer.github.com/apps/getting-started-with-building-apps/

@Quramyさんのチームではフロントエンド用の自動回帰テスト環境として、修正前の環境でのスクリーンショットと、コードに修正を加えた後の環境でのスクリーンショットを比較して問題がないかの確認を行うツールを作成して運用しているとのことでした。
今回の発表では触れられていませんでしたが、2017年のNode学園祭で発表されていたREG-SUITというツールだと思われます。 https://speakerdeck.com/quramy/introduction-to-visual-regression-testing

スクリーンショットを比較するテストの場合、画像を比較して差分が出ていたとしてもデザイン変更を伴う正しい修正かもしれないため、機械的にOKかNGかを判断することはできず人間がチェックします。
そして差分が意図したものである場合は、修正後のスクリーンショットを次回テストの正として画像を保存しておく必要があります。

今回作成されたGitHub Appsは以下の作業を自動的にしてくれるようでした。

  • CIで実行してスクリーンショットの差分が存在した際に画像チェック用のページのurlをプルリクにコメントする
  • レビューがApproveされたらそれを検知してマージOKのステータスに変更する
  • 今回のスクリーンショットを次回テストの正とするために画像を保存

実装の詳しい説明までは残念ながらおそらく時間の都合上発表されていませんでしたが、AWS Lambda上で構築されているとのことでした。

感想

他の方の発表も非常におもしろかったのですが、最近自分がDangerというプルリクに対するアクションを簡単に書けるライブラリのプラグインを作っていたので、似たようなことができるGitHub連携ツールの発表が非常に興味深かったです。

プルリクへのコメントや、Issueの自動ラベリングはDangerでも実現できるのですが、DangerはCIサービス上で動くことをウリにしているので手軽に導入できる反面、pushされたタイミングでしか処理が行えないという不便さを感じていました。

botなりGitHub Appsは実装とAWS Lambdaにデプロイする手間はかかるはずですが、GitHub上のあらゆるイベントに対して処理を走らせることができるという点が強みだと思います。 特にApproveされたり、LGTMされたタイミングで何かのアクションをするというのは色々なことに使えそうですね。

便利そうだなーと感じる一方で、残念ながら今のところ自分はまだ便利に使えそうなアイディアが浮かんでいないです。ただGitHub Apps自体が発表されたのは去年のようですので、これからどんどん活用事例が増えていくのではないかなという予感がしています。

ちなみに、自分はまだ触っていないのですがGitHubのbotを簡単に作るためのライブラリとしてhttps://probot.github.io/というのもあるようです。
今回の発表やprobotを見ていると、元々便利なGitHubをさらに便利にしていくという流れを何となく感じますね。