Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

takayuki-hayashi
September 08, 2018
840

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

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

takayuki-hayashi

September 08, 2018
Tweet

Transcript

  1. SPEEDAの開発サイクル(補足) • ストーリーに着手したら最初にやることはE2Eテストを書く事 ◦ E2Eを最初に書くことによって仕様の理解速度の向上、仕様の漏れの把握を迅速に行える • E2Eテストはテストエンジニア、ドメインエキスパート、プログラマーなどがペアプ ロをしながら書く • ストーリーの仕様を満たす記述が重要

    ◦ 画面を含むE2Eの場合、xpath等は最初は適当でOK • 最後にE2Eをパスさせる段階で細かい修正は入る ◦ xpathとか文言とか • E2EをパスさせないとストーリーをDoneにはしない • E2Eテストを書く以外の作業も基本的に全てペアプロ
  2. 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化
  3. デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 (バイナリ) の作成 Dockerイメージ の作成

    & Push 個別E2E環境に デプロイ サービス単体の E2Eテスト実行 フルE2E環境に デプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ プロダクション環境 (Green)にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック(手動)
  4. Gaugeの特徴 • https://getgauge.io/ • ThoughtWorksが開発(OSS GPL3.0) • Markdown形式で記述可能 • Markdownのドキュメント(spec)にはプログラムのソースが一切介在しない

    • リッチなレポートを出力可能 • 様々な言語でテストを記述することが可能(Java、C#、Ruby、Python) ◦ SPEEDAの開発ではKotlinで記述 • IDE機能が強力 • 並列実行のサポート
  5. デプロイメント・パイプライン ソースコードの Push 単体 テスト実行 成果物 (バイナリ) の作成 Dockerイメージ の作成

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

    & Push k8s上の個別E2E環境 にデプロイ サービス単体の E2Eテスト実行 k8s上のフルE2E環 境にデプロイ 画面のE2Eを実行 k8s上のStaging環境 にデプロイ k8s上のプロダクション環 境(Green)にデプロイ プロダクション環境を BlueからGreenへ変更 Stagingにてクロスブラウザ のチェック(手動) ローカルの開発環境で単体テストをパスさせ、現在のストーリーに 対応するE2Eテストをminikubeを活用しつつパスさせる
  7. E2Eテストの実践を難しくする要因 • E2Eテスト環境の整備 • E2Eテストの記述コスト • 実行時間 • 再現性 •

    CI/CDへの組み込み、統合 • etc... k8sで効率化 Gaugeで効率化 k8sで複数namespace切って実行するとかなり時間短縮に なるはず(まだ出来てないです) k8sとminikube、Dockerで再現性Up k8sで効率化
  8. k8sとは関係ないですが • CI/CDはJenkinsを仕様 ◦ pipelineを全てgroovyスクリプト化 ◦ 現在はbuildkiteを試している所 • コンパイル、単体テストの実行、jarとかjsの成果物生成は全てDockerコンテナ で行い再現性を高めてます

    • 「trunkベース開発」で行っているので基本的にブランチは存在しない ◦ https://www.infoq.com/jp/news/2018/05/trunk-based-development • マニュアルテストだと何日もかかるテストが毎日何回も実行されてます ◦ 実行すればするほど費用対効果は上がる