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

Slide 1

Slide 1 text

KubernetesとGaugeを活用したTDD開発事例〜 E2Eのお話〜

Slide 2

Slide 2 text

自己紹介 ● 林尚之（はやしたかゆき） ● Agile（XP）、TDD、DDDとかが好き ○ 最近はDart（Web）、Kotlin（Server Side）を書く事が多い。clojureも勉強始めました ● 株式会社ユーザベース ○ SPEEDA日本事業 CTO ● twitter:@t_hyssh

Slide 3

Slide 3 text

E2E（受け入れ）テスト書いてますか？

Slide 4

Slide 4 text

E2Eテストって難しいですよね・・・

Slide 5

Slide 5 text

E2Eテストの実践を難しくする要因 ● E2Eテスト環境の整備 ● E2Eテストの記述コスト ● 実行時間 ● 再現性 ● CI/CDへの組み込み、統合 ● etc...

Slide 6

Slide 6 text

これらの要因といかに戦うか

Slide 7

Slide 7 text

そしてE2Eを書く費用対効果をいかに上げられるか

Slide 8

Slide 8 text

そのあたりがE2Eも含めたTDDを実践し続ける上で重要な部分かなと思います

Slide 9

Slide 9 text

今日は弊社のSPEEDAというプロダクト開発にてそれらの部分にどう取り組んでいるのかという事を共有出来たらと思っています

Slide 10

Slide 10 text

アジェンダ ● SPEEDAの開発におけるE2Eテスト実践内容 ● Gaugeの導入理由と活用例、課題 ● Kubernetesの活用例、課題

Slide 11

Slide 11 text

アジェンダ ● SPEEDAの開発におけるE2Eテスト実践内容 ● Gaugeの導入理由と活用例、課題 ● Kubernetesの活用例、課題

Slide 12

Slide 12 text

最初に伝えておくと

Slide 13

Slide 13 text

今から話をする内容で特に目新しい事は何もないですｗ

Slide 14

Slide 14 text

偉大な先人達が技術書などで言っている事をただやってるだけです

Slide 15

Slide 15 text

守破離の守ですね

Slide 16

Slide 16 text

SPEEDAの開発サイクル着手するストーリーを決める E2Eテストを書くユニットテストを書くユニットテストを通すリファクタリング E2Eテストを通す

Slide 17

Slide 17 text

ストーリーに手をつける際に一番最初にやる事はE2Eテストを書く事

Slide 18

Slide 18 text

「フィーチャを実装するときには、受け入れテストを書くところから始める」『実践テスト駆動開発』 Steve Freeman・Nat Pryce, P8

Slide 19

Slide 19 text

SPEEDAの開発サイクル（補足） ● ストーリーに着手したら最初にやることはE2Eテストを書く事 ○ E2Eを最初に書くことによって仕様の理解速度の向上、仕様の漏れの把握を迅速に行える ● E2Eテストはテストエンジニア、ドメインエキスパート、プログラマーなどがペアプロをしながら書く ● ストーリーの仕様を満たす記述が重要 ○ 画面を含むE2Eの場合、xpath等は最初は適当でOK ● 最後にE2Eをパスさせる段階で細かい修正は入る ○ xpathとか文言とか ● E2EをパスさせないとストーリーをDoneにはしない ● E2Eテストを書く以外の作業も基本的に全てペアプロ

Slide 20

Slide 20 text

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化

Slide 21

Slide 21 text

全体E2Eと個別E2Eを分けている理由 ● 各サービスはここに挙げたサービス群以外から呼ばれる可能性がある ● 他の機能の拡張のために修正する場合にそのサービスの仕様、E2Eがあるのが望ましい ● サービスの独立進化を促進させるためにも個別のE2Eは必要

Slide 22

Slide 22 text

結果的に自然とこうなります Front Endの E2E 各サービスのE2E 単体テスト

Slide 23

Slide 23 text

デプロイメント・パイプラインソースコードの Push 単体テスト実行成果物（バイナリ）の作成 Dockerイメージの作成 & Push 個別E2E環境にデプロイサービス単体の E2Eテスト実行フルE2E環境にデプロイ画面のE2Eを実行 k8s上のStaging環境にデプロイプロダクション環境（Green）にデプロイプロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザのチェック（手動）

Slide 24

Slide 24 text

アジェンダ ● SPEEDAの開発におけるE2Eテスト実践内容 ● Gaugeの導入理由と活用例、課題 ● Kubernetesの活用例、課題

Slide 25

Slide 25 text

SPEEDA開発におけるE2Eテストの定義

Slide 26

Slide 26 text

SPEEDA開発におけるE2Eテストの定義 E2Eテストとは自動テストとして実行可能なドキュメント（仕様）

Slide 27

Slide 27 text

なのでドキュメント（仕様）を書く上での表現力を重要視してます

Slide 28

Slide 28 text

そういった理由で「Gauge」を使ってE2Eを書いてます

Slide 29

Slide 29 text

Gaugeの特徴 ● https://getgauge.io/ ● ThoughtWorksが開発（OSS GPL3.0） ● Markdown形式で記述可能 ● Markdownのドキュメント（spec）にはプログラムのソースが一切介在しない ● リッチなレポートを出力可能 ● 様々な言語でテストを記述することが可能(Java、C#、Ruby、Python) ○ SPEEDAの開発ではKotlinで記述 ● IDE機能が強力 ● 並列実行のサポート

Slide 30

Slide 30 text

Markdownでの記述

Slide 31

Slide 31 text

Kotlin側の記述

Slide 32

Slide 32 text

IDEのサポート（サジェスト）

Slide 33

Slide 33 text

IDEのサポート（エラー表示）

Slide 34

Slide 34 text

アウトプット

Slide 35

Slide 35 text

Gaugeをどう使ってるか ● WebはSelenideを仕様 ● DBのアサーションはDBUnit ● KVSに関してはKeyに対するValueをそのまま返すエンドポイントをサービスに定義してその値を取得してチェック ○ Production環境ではそのエンドポイントは無効化

Slide 36

Slide 36 text

Gaugeを使ってみた感想

Slide 37

Slide 37 text

Gaugeを使ってみた感想 ● やっぱりMarkdown形式で書けるのは大きい ● アサーションの方法とかは使う側が決めれるので押し付け感はない ● 0.8くらい（？）から使ってたので情報少なくて最初は大変だった

Slide 38

Slide 38 text

課題

Slide 39

Slide 39 text

GaugeというよりE2Eの課題

Slide 40

Slide 40 text

「仕様を書く」という意識を高めないと良いE2Eにはならない

Slide 41

Slide 41 text

例えば

Slide 42

Slide 42 text

良い例

Slide 43

Slide 43 text

悪い例正しい理由、その仕様が書かれていない。コメントも無い「正しく」って？？？

Slide 44

Slide 44 text

こういった点を意識するには結構時間がかかる

Slide 45

Slide 45 text

HTMLのレポートをあまり活用出来てない・・・

Slide 46

Slide 46 text

アジェンダ ● SPEEDAの開発におけるE2Eテスト実践内容 ● Gaugeの導入理由と活用例、課題 ● Kubernetesの活用例

Slide 47

Slide 47 text

E2Eテストを継続的に実践していく上で運用コストは無視出来ない問題

Slide 48

Slide 48 text

Kubernetes

Slide 49

Slide 49 text

Kubernetes ● Dockerに代表されるコンテナのオーケストレーションシステム ○ 現時点ではもはやデファクトスタンダード ● ローカル環境に構築したい場合はminikube ○ それなりにメモリ必要です

Slide 50

Slide 50 text

minikubeを使う理由 ● minikubeを使うことでStaging、Production環境と同じ環境（kubernetes）になるので実行環境の一貫性を保てる ● デプロイするアプリケーションが使用するストレージ（RDB、KVS、ES等）も全てコンテナ化する事で再現性を向上させる事が可能 ● マイクロサービス化しているのでE2Eをローカルで実行させるためには複数のサーバーを起動させる必要がある ○ Staging、Productionと同じデプロイ方法を使える

Slide 51

Slide 51 text

Slide 52

Slide 52 text

デプロイメント・パイプラインソースコードの Push 単体テスト実行成果物（バイナリ）の作成 Dockerイメージの作成 & Push k8s上の個別E2E環境にデプロイサービス単体の E2Eテスト実行 k8s上のフルE2E環境にデプロイ画面のE2Eを実行 k8s上のStaging環境にデプロイ k8s上のプロダクション環境（Green）にデプロイプロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザのチェック（手動）ローカルの開発環境で単体テストをパスさせ、現在のストーリーに対応するE2Eテストをminikubeを活用しつつパスさせる

Slide 53

Slide 53 text

フルk8s化する前は各E2E環境の整備だったりに結構コストがかかっていましたが現在はそれに時間を取られることはほとんどなくなりました

Slide 54

Slide 54 text

E2Eテストの実践を難しくする要因 ● E2Eテスト環境の整備 ● E2Eテストの記述コスト ● 実行時間 ● 再現性 ● CI/CDへの組み込み、統合 ● etc... k8sで効率化 Gaugeで効率化 k8sで複数namespace切って実行するとかなり時間短縮になるはず（まだ出来てないです） k8sとminikube、Dockerで再現性Up k8sで効率化

Slide 55

Slide 55 text

k8sとは関係ないですが ● CI/CDはJenkinsを仕様 ○ pipelineを全てgroovyスクリプト化 ○ 現在はbuildkiteを試している所 ● コンパイル、単体テストの実行、jarとかjsの成果物生成は全てDockerコンテナで行い再現性を高めてます ● 「trunkベース開発」で行っているので基本的にブランチは存在しない ○ https://www.infoq.com/jp/news/2018/05/trunk-based-development ● マニュアルテストだと何日もかかるテストが毎日何回も実行されてます ○ 実行すればするほど費用対効果は上がる

Slide 56

Slide 56 text

10年前とかに比べてE2Eテストを実施するコストはかなり下がってきている

Slide 57

Slide 57 text

今や「ユニットテストは書くのが普通だよね」となったように

Slide 58

Slide 58 text

近い将来「E2Eテストは書くのが普通だよね」となるんじゃないかなと思います（願望）

Slide 59

Slide 59 text

JaSTT’18 TokyoでGoogleのJohn Miccoが言ってました

Slide 60

Slide 60 text

曰く「Googleでは全て（UI含む）のテストを自動化している」