※アイキャッチ画像は公式から引用
2017/12/12に行われた、SRE-SET Automation Nightに行ってきました。
[さらに増枠!] SRE-SET Automation Night – connpass
今回わたしは主にテスト自動化のあたりの話を聞きたくて行ったのですが、イベント自体はもっと広いスコープのもの。
公式のイベント概要では
- CI/CDを用いたプロダクトリリースの自動化に関する経験
- Ansibleなどを用いたDevOpsの自動化
- AppiumやSeleniumなどのUIオートメーションツールを使った第一印象
- テストの自動化ハックとアドバイス
- CircleCI, Travis, BitriseなどのクラウドCIサービスの経験
- SeleniumやSlackbotを用いた日次タスクの自動化
などが挙げられていました。
以下、各セッションの内容と感想・メモです。
「Data processing, workflow and us ~How to manage automated jobs~」@syu_cream
概要・感想
メルカリのSREチームの方の発表。データ処理におけるジョブ管理をどうしているか、どう悩んでいるかなど。
自分が詳しくない分野の内容だったのですが、
- ログの処理コマンドなどを手で毎日打っているようだと辛い→自動化しよう
という流れで取組んだ、というお話でした。
データが大量にあって手動でゴニョゴニョするの辛いよね、というのはテスト・QAエンジニアでも経験がある人は多いと思うので、こういったアプリケーションのログやアクセス数などの大量のデータをいかに自動で処理して楽に見るかという内容は、勉強しとくとあとで役に立ちそうですね。（コメントが浅い
実際自動テストのログなどの処理って結構厄介なので。勉強します。
「レビューのコストを削減するための施策」 @tarappo
概要・感想
コードやドキュメントのレビューを行う際、レビューアもレビューイもお互いに疲弊してしまうことがあります。
特に、タイポとかフォーマットのミスなどの些細な（でも見逃してはおけない）ものをいちいちレビューで指摘する／されると辛いし、あとはWIPのものがレビューに混ざってしまっている場合もあったそうです。
なので、ここをDangerやTextlintなどを使って自動でチェックするシステムを構築。
おかげで、
- タイポが減った
- プルリクの内容やラベルが統一され見やすくなった
- 結果、レビューがしやすくなった
というメリットがあったそうです。
人間がやるべきところに集中できるようにする、という自動化のいい面を取り出せたよい例だと思って聞いてました。
現状は自動でチェックさせるための辞書を最初に用意しなければならず、ここにコストがかかっているそうなので、辞書の自動生成やレビューコストの自動見積などに広げていきたいそうです。
個人的にはコレを参考にして、テストのドキュメントレビューなんかできると嬉しいなとか妄想しました。。あいまいなテスト手順書しかなくてテストを切り出せないとかあるあるなので。。
「Reliable Mobile Test Automation」@vbanthia
概要・感想
メルカリのSETのビシャルさんによる発表。『Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)』の著者のお一人でもあります。
内容は、
- モバイルのテスト自動化は、チャレンジングではあるが無理ではないよ
- よいアプローチなら実現出来るよ
という話でした。
私も「Appiumとか使っても、モバイルの自動テストはまだまだ厳しいでしょ・・・」と思っていたのですが、実際にLTの最中にSlackからテスト実行させて、クラウド経由で端末の自動テストを動かしてレポート（スクショ・ビデオ付き）が出てくるところまで見せてもらったら・・・
メルカリさんの本気を見た気がしました。あそこまでできるのすごい。
自動テストの結果を見て、失敗原因がわからないときにすぐ「不安定だから、フレイキーだから」と言ってしまうのではなく、実行中のスクショやビデオ、ログなどをすべて記録しておきましょう、というのも、すごい。
Magic Podの活用を具体的に考えてみた」戸田 広
概要・感想
戸田さんのLT。
MagicPodの活用方法や、戸田さんとしての見解を聞けました。
戸田さんがおっしゃるには、MagicPodはSeleniumIDEを使っているような層に向けたテストツールである、と。そもそもガンガン自分で書きたい人はAppiumを直接使うので、メリットは別のところ＝テスト項目表がそのまま自動テストコードを兼ねているツールであるというところにある、そうです。
あとはMagicPodがTravisCIから使えるのを確認済で、CircleCIは大丈夫だろうけどまだ確認はしていない、そうです。
確かにUIの中から要素を自動で空気読んで特定してくれるのはありがたい反面、それを実現するための縛りや制約が生まれる以上はきっと「自分で書きたい」ってなってくるんだろうなぁとは思います。が、使ったことないのでわからないです。。
でもこうやって「実際どうなの？」を聴けるのはありがたいですね。
Prometheusを導入した話」株式会社Nagisa 榎戸
概要・感想
- 榎戸さんが入社したとき、CloudWatchのみで監視していた→つらい
- Prometheus＆Andible導入→はっぴー
というお話でした。
門外漢過ぎて深いとこまではわからなかった＞＜
インフラのひとすごい（小並感
「セキュリティ強化のための自動化」 @manabusakai
概要・感想
freeeの坂井さんのLT。
お金と人のサービスを扱っている異常、情報漏えいが起きると会社としては一撃で致命傷を負うことになる。
そのため、セキュリティには気を遣っている。が・・
開発に対してSREがとても少ない(1割いない）そうで、自動化には積極的に取り組んでいるそうです。
セキュリティと自動化とが、今回のLT聞く前は自分のなかであまりつながっていませんでした。でも
- いままでは攻撃を受けてから気づいていた→ロードバランサのWAFで一時遮断して時間を稼ぎ、その間にSREが調査
- 何らかの脆弱性が発表されセキュリティパッチが出たとき、手元でコマンドをポチポチしていた→作業を自動化し、ワンコマンド＆並列に
といった工夫をしてセキュリティ強化を実現している、という話をうかがって、なるほどなーとただ感心。
1人インフラ運用チームで、自動化の作業時間を確保するためにやっていること」北野勝久（ @katsuhisa__ ）
概要・感想
ふだん、ひとりインフラチームをやっているそうです。自動化はしたいものの、自動化をするにも時間がそれなりに必要ですし、とはいえ自分しか知らない状態になるとヤバいよね、ということで取り組みをされたそうです。
たとえば
- 定常的な運用業務の標準化
- マニュアルを沢山つくる→業務移管が簡単になり、自分が抱える作業が減った→自動化の余裕がでてきた
- ゼロコーディングでできることをした
- 機器の性能アップ＝札束で殴る
- 自分の時給を知っておくと、偉い人を説得しやすい。実際人件費のほうが高いし。
- 機器の性能アップ＝札束で殴る
など、汎用的に参考になる知見で個人的にすごく好きな話でした。
また、自動化について語るときに、
- 全自動と全手動の２値で考えがちだけど、間に半自動がある。
- ハイレベルな人はこの半自動部分を脳内でスキップしがちだけど、全自動を目指す過程でどこかに知見を残すことは大事
ああ分かる・・・！そのとおりだ・・・！
Automation基盤提供のしかた」@tnir
概要・感想
- Automationに必要なこと
- 実行履歴がとれる（だれが、いつ、なんのために）
- 実行タイミングを制御できる
- 定期実行
- マニュアル実行
- イベントドリブン
- 自動再実行
- マニュアル再実行
- 実行命令系とｎ連携
- SCM
- IaaS
- The twelve factors
まとめ
SeleniumでのE2Eテスト自動化、みたいなことを普段やっているので、SRE側のおはなしは新鮮でした。なるほどーそういうこともやってるのねー、などなど。
客先常駐QAエンジニアだとそういったインフラ周りの方とがっつり話すことも少なかったりして、でも「自動化」という視点から見るとテストやQAでも通じるような考え方もあり。参考になりました。
会の最初に「第二回もやります！」的なことをおっしゃっていたので、次も参加したいです。