LINE DEVELOPER DAY参加記録

「LINE DEVELOPER DAY 2020」２日目に参加しました。
聞いたセッションのメモ書き程度の投稿です。
知識不足や聞き落としで間違ったことを書いているかもしれないので悪しからず。

Kubernetesを用いたPull Request駆動E2Eテスト

同時に同じ機能に修正が入ると、E2Eテストがコケる。
サーバにデプロイしないとE2Eテストを実行できないので開発者へのフィードバックが遅い。

k8sを使ってE2Eのテストをユニットテストと同レベルで実行できるようにした話。

SETとは

Software Engineer in Test
自動テストに関わるフレームワークやパッケージを組み立てるのがメイン業務。
E2Eだけではない
DX（Developer eXperience）を高めて、その結果として製品の品質を高めることが目的。

Test Automation Engineerが製品品質をメイン目的にするため、役割として住み分けされている。

k8s活用

E2Eテスト実行にはアプリのサーバデプロイまで必要。
ならばプルリクを起点にk8s上にサーバを構築してしまう。
プルリクごとに独立したNameSpaceが立ち上がるため、他の変更やテスト実行に影響されない。

実施した結果、元々の課題改善だけでなく、レビューにも効果が！
ローカルで立ち上げて実行していると、ローカル環境でしか再現しない問題が出た時、フィードバックしずらい。
k8s環境に移したら、そこで再現して見せられるのが良い。

感想

自分がk8s初心者なのとスピーカーのテンポが早めだったので、付いていけない部分が多かった。
かなり凄いことを実現しているので、資料が公開されたら改めて確認したい。
以前は色んな構築や課題が発生していた試験環境準備が、DevOpsとコンテナ技術の発展でどんどん進化しているなーと思いました。

LINEのテスト自動化システムがどのように動いているのか

ドキュメンテーション

テスト自動化においてもドキュメンテーションは重要。

Page Objec Patternを採用しているので、スクリーンごとにページを作成し、
スクリーンショット、プロパティ（ページの要素）、アクション（イベント）をまとめている。

このページはMarkdownで書いて簡単にデプロイできる。

モニタリング

LINEには世界中に開発のためのハードウェアがある。
サーバの故障や不具合で試験が失敗した時、監視できるよう、
ElasticserchにFilebeatとMetricbeatでデータを収集して、Grafanaでダッシュボード表示している。

レポーティング

様々なLINEサービスのテスト結果をどうまとめるか。
eggplantやappiumのデータをElasticsearchに収集し、Pythonでデータを成型、Veu.jsでWebに表示している。

Bot

LINEとSlackを利用している。
コミュニケーションツールだけでなく自動ツールの通知にも活用している。

感想

ドキュメンテーションはアジャイル開発だといかに手軽に必要十分な情報をまとめていくかが重要になるので、
フレームワークを作って更新していっているのは魅力的だなーと感じました。

The CI/CD Automation make happiness from small pieces

リリース自動化

リリースと言えば、デプロイを行い、問題なければリリースステータスが更新され、Gitタグが切られ、リソースを収集、マーケットにアーティファクトがアップロードされればリリース…と多くのタスクがあり、抜けが発生しやすく、また各フローが終了するまでチームが緊張状態になっていた。

そこで自動化を進めた。

ネットワークが遮断されている環境でもリリースステータスを取得できる仕組みを作り、リリース結果がフィードバックされるようになった。
これによって、CIタスクを増やしても実施が漏れない・負担が増えない環境になった。

感想

扱っている内容自体はCI/CDを地道にやったよ！という話なので、もう少し突っ込んで実現時に直面した課題とその対処策を聞きたかったなと。

How to quickly develop static pages in LINE

静的コンテンツを1日で開発・デプロイできるようになった話。

動的コンテンツはキャッシュ利用やサーバ間通信など考えることが多く、重くなりがちなため、静的ページへのニーズが増えている。
そこで、多くのページを作るためのリソース不足が課題となった。
静的コンテンツ作成には具体的に以下のようなタスクが発生する。
- デザイン
- JavaScriptコーディング
- Minify（難読化）
- 多言語化
- Webサーバへのデプロイ
- ドメイン設定

→多くは繰り返し作業なので、自動化できるのでは？と考えた。

共通作業の自動化

Node.jsでCLIツールを作成し、init, dev, build, deployといったコマンドで実行できるようにした。
が、ビルド時に開発者のローカル環境の影響を受けることが問題になったので、
Web画面（Dashboard）からGitHubのレポジトリを参照できるように変更した。

コンテンツ作成

コンテンツ作成はサービスごとに異なり、共通化が難しい。
→JAMStackを利用することにした。
- JavaScript
- APIs
- Markup

Headless CMSをDockerコンテナ上に立て、Dashboard画面からGUI画面を呼び出せるようにした。
これにより、コンテンツ作成・更新時にエンジニアがソースコードを操作する必要がなくなった。
さらに画面コンポーネントを定義しておき、コンテンツ作成を素早く行えるようにした。

感想

色んなサービスを扱っているLINEだからこそ独自フレームワーク化・自動化が生きるのかなと思った。
MkDocsなど、単純なページを生成するフレームワークは既にあるので、それをパイプラインに乗せるだけで手軽に静的コンテンツの自動更新はできる。
が、サービスごとに凝ったコンテンツを作りたければ、このようなビルドが必要になるのだなと。

総括

LINE DEVELOPER DAY初参加でしたが、予め登録していたセッションが近づくとLINEに通知されたり、ライブ画面の横でLINEスタンプ風のリアクションが送れたり、LINEさんならではの意匠がこらされていて面白かったです。
セッション内容としては、10～20分の短いセッションも多く、ちょっと駆け足な印象も否めず。
もう少しじっくり聞きたかったなーと思います。
次回予告が出ているセッションもあるので、続報を待ちます。

本日は参加させていただき、ありがとうございました！