KubernetesとGaugeを活用したTDD開発事例

XP祭り2018の発表資料です。
発表した時の資料より文字を多くしてます。

Transcript

1. KubernetesとGaugeを活用し たTDD開発事例 〜 E2Eのお話 〜
2. 自己紹介 • 林 尚之（はやし たかゆき） • Agile（XP）、TDD、DDDとかが好き ◦ 最近はDart（Web）、Kotlin（Server Side）を書く事が多い。clojureも勉強始めました • 株式会社ユーザベース ◦ SPEEDA日本事業 CTO • twitter:@t_hyssh
3. E2E（受け入れ）テスト書いてますか？
4. E2Eテストって難しいですよね・・・
5. E2Eテストの実践を難しくする要因 • E2Eテスト環境の整備 • E2Eテストの記述コスト • 実行時間 • 再現性 • CI/CDへの組み込み、統合 • etc...
6. これらの要因といかに戦うか
7. そしてE2Eを書く費用対効果をいかに 上げられるか
8. そのあたりがE2Eも含めたTDDを実践し 続ける上で重要な部分かなと思います
9. 今日は弊社のSPEEDAというプロダク ト開発にてそれらの部分にどう取り組 んでいるのかという事を共有出来たら と思っています
10. アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例、課題
11. アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例、課題
12. 最初に伝えておくと
13. 今から話をする内容で特に目新しい 事は何もないですｗ
14. 偉大な先人達が技術書などで言って いる事をただやってるだけです
15. 守破離の守ですね
16. SPEEDAの開発サイクル 着手するストーリー を決める E2Eテストを書く ユニットテストを書く ユニットテストを通す リファクタリング E2Eテストを通す
17. ストーリーに手をつける際に一番最初 にやる事はE2Eテストを書く事
18. 「フィーチャを実装するときには、受け 入れテストを書くところから始める」 『実践テスト駆動開発』 Steve Freeman・Nat Pryce, P8
19. SPEEDAの開発サイクル（補足） • ストーリーに着手したら最初にやることはE2Eテストを書く事 ◦ E2Eを最初に書くことによって仕様の理解速度の向上、仕様の漏れの把握を迅速に行える • E2Eテストはテストエンジニア、ドメインエキスパート、プログラマーなどがペアプ ロをしながら書く • ストーリーの仕様を満たす記述が重要 ◦ 画面を含むE2Eの場合、xpath等は最初は適当でOK • 最後にE2Eをパスさせる段階で細かい修正は入る ◦ xpathとか文言とか • E2EをパスさせないとストーリーをDoneにはしない • E2Eテストを書く以外の作業も基本的に全てペアプロ
20. E2Eをどういう単位で書いているか Service A Service B Service C BFF Front End サービス毎にE2E作成 他サービスとの連携部分はMock化 サービス単体のE2Eは GETであればJSONを アサーション、POSTの 場合はDB、KVSのア サーション Front EndのE2Eがシステムとして の振る舞い（仕様） ユーザーが直接操作する Front EndのE2Eで関連する全てのサー ビスを連携させる サービス毎にE2E作成 他サービスとの連携部分はMock化
21. 全体E2Eと個別E2Eを分けている理由 • 各サービスはここに挙げたサービス群以外から呼ばれる可能性がある • 他の機能の拡張のために修正する場合にそのサービスの仕様、E2Eがあるの が望ましい • サービスの独立進化を促進させるためにも個別のE2Eは必要
22. 結果的に自然とこうなります Front Endの E2E 各サービスのE2E 単体テスト
23. デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 （バイナリ） の作成 Dockerイメージ の作成 & Push 個別E2E環境に デプロイ サービス単体の E2Eテスト実行 フルE2E環境に デプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ プロダクション環境 （Green）にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック（手動）
24. アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例、課題
25. SPEEDA開発におけるE2Eテストの定義
26. SPEEDA開発におけるE2Eテストの定義 E2Eテストとは 自動テストとして実行可能なドキュメント（仕様）
27. なのでドキュメント（仕様）を書く上での 表現力を重要視してます
28. そういった理由で 「Gauge」 を使ってE2Eを書いてます
29. Gaugeの特徴 • https://getgauge.io/ • ThoughtWorksが開発（OSS GPL3.0） • Markdown形式で記述可能 • Markdownのドキュメント（spec）にはプログラムのソースが一切介在しない • リッチなレポートを出力可能 • 様々な言語でテストを記述することが可能(Java、C#、Ruby、Python) ◦ SPEEDAの開発ではKotlinで記述 • IDE機能が強力 • 並列実行のサポート
30. Markdownでの記述
31. Kotlin側の記述
32. IDEのサポート（サジェスト）
33. IDEのサポート（エラー表示）
34. アウトプット
35. Gaugeをどう使ってるか • WebはSelenideを仕様 • DBのアサーションはDBUnit • KVSに関してはKeyに対するValueをそのまま返すエンドポイントをサービスに 定義してその値を取得してチェック ◦ Production環境ではそのエンドポイントは無効化
36. Gaugeを使ってみた感想
37. Gaugeを使ってみた感想 • やっぱりMarkdown形式で書けるのは大きい • アサーションの方法とかは使う側が決めれるので押し付け感はない • 0.8くらい（？）から使ってたので情報少なくて最初は大変だった
38. 課題
39. GaugeというよりE2Eの課題
40. 「仕様を書く」という意識を高めないと 良いE2Eにはならない
41. 例えば
42. 良い例
43. 悪い例 正しい理由、その仕様が書かれていない。 コメントも無い 「正しく」って？？？
44. こういった点を意識するには結構時間 がかかる
45. HTMLのレポートをあまり活用出来て ない・・・
46. アジェンダ • SPEEDAの開発におけるE2Eテスト実践内容 • Gaugeの導入理由と活用例、課題 • Kubernetesの活用例
47. E2Eテストを継続的に実践していく上 で運用コストは無視出来ない問題
48. Kubernetes
49. Kubernetes • Dockerに代表されるコンテナのオーケストレーションシステム ◦ 現時点ではもはやデファクトスタンダード • ローカル環境に構築したい場合はminikube ◦ それなりにメモリ必要です
50. minikubeを使う理由 • minikubeを使うことでStaging、Production環境と同じ環境（kubernetes）になる ので実行環境の一貫性を保てる • デプロイするアプリケーションが使用するストレージ（RDB、KVS、ES等）も全てコ ンテナ化する事で再現性を向上させる事が可能 • マイクロサービス化しているのでE2Eをローカルで実行させるためには複数の サーバーを起動させる必要がある ◦ Staging、Productionと同じデプロイ方法を使える
51. デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 （バイナリ） の作成 Dockerイメージ の作成 & Push 個別E2E環境に デプロイ サービス単体の E2Eテスト実行 フルE2E環境に デプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ プロダクション環境 （Green）にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック（手動）
52. デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 （バイナリ） の作成 Dockerイメージ の作成 & Push k8s上の個別E2E環境 にデプロイ サービス単体の E2Eテスト実行 k8s上のフルE2E環 境にデプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ k8s上のプロダクション環 境（Green）にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック（手動） ローカルの開発環境で単体テストをパスさせ、現在のストーリーに 対応するE2Eテストをminikubeを活用しつつパスさせる
53. フルk8s化する前は各E2E環境の整 備だったりに結構コストがかかってい ましたが現在はそれに時間を取られ ることはほとんどなくなりました
54. E2Eテストの実践を難しくする要因 • E2Eテスト環境の整備 • E2Eテストの記述コスト • 実行時間 • 再現性 • CI/CDへの組み込み、統合 • etc... k8sで効率化 Gaugeで効率化 k8sで複数namespace切って実行するとかなり時間短縮に なるはず（まだ出来てないです） k8sとminikube、Dockerで再現性Up k8sで効率化
55. k8sとは関係ないですが • CI/CDはJenkinsを仕様 ◦ pipelineを全てgroovyスクリプト化 ◦ 現在はbuildkiteを試している所 • コンパイル、単体テストの実行、jarとかjsの成果物生成は全てDockerコンテナ で行い再現性を高めてます • 「trunkベース開発」で行っているので基本的にブランチは存在しない ◦ https://www.infoq.com/jp/news/2018/05/trunk-based-development • マニュアルテストだと何日もかかるテストが毎日何回も実行されてます ◦ 実行すればするほど費用対効果は上がる
56. 10年前とかに比べてE2Eテストを実施 するコストはかなり下がってきている
57. 今や「ユニットテストは書くのが普通だ よね」となったように
58. 近い将来「E2Eテストは書くのが普通だ よね」となるんじゃないかなと思います （願望）
59. JaSTT’18 TokyoでGoogleのJohn Miccoが言ってました
60. 曰く 「Googleでは全て（UI含む）のテストを 自動化している」
61. かっこいい！
62. そこを目指して日々頑張っていこうと 思います
63. ご清聴ありがとうございました