Testable Infra: Cloud-native技術をフル活用した、「テスト」の諸問題の刷新的解決案
•Als PPTX, PDF herunterladen•
0 gefällt mir•188 views
「XP祭り2021」（2021/09/18・土）での発表資料です。 http://xpjug.com/xp2021/ テストにまつわる以下の問題を解決すべく、Cloud-native技術を駆使して構築した「Testable Infra」について、コンセプト、設計と技術の詳細、導入事例の観点から紹介します。 - テスト環境の準備の工数がバカにならない - テストデータを複数人・チームで共有していて、気軽にテストできない - 外部サービスと接続できず、必要なテストができない 皆さんのイノベーションのヒントになれば幸いです。
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Testable Infra: Cloud-native技術をフル活用した、「テスト」の諸問題の刷新的解決案
Ähnlich wie Testable Infra: Cloud-native技術をフル活用した、「テスト」の諸問題の刷新的解決案 (20)
Mehr von Hiroyuki Ito
Mehr von Hiroyuki Ito (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Testable Infra: Cloud-native技術をフル活用した、「テスト」の諸問題の刷新的解決案
- 3. (1) テスト環境 3 • 初期構築・維持・管理が大変 • 環境ごとの差分が大きく、 テストの信頼性に疑問符がつく • 複数人・チームで共用することで 業務のボトルネックになりがち
- 4. (2) テストデータ 4 • 一貫性のあるテストデータの 事前準備・維持・管理が大変 • 複数人・チームで共用することで データや処理が衝突しがち • 気軽にテストできない
- 5. (3) 外部システム接続 5 • 事前準備が大変 • モック・スタブと実サービスとの 切り替えが大変 • 接続先のバージョン管理が大変
- 7. 「三悪人」がもたらす悪夢 7 • テストを十分にできないまま 本番リリース • 本番障害の多発 • 緊急修正・リリースしても 別の障害が発生 😢
- 10. Agenda 10 1. コンセプト 2. 設計・技術詳細 3. 導入事例 4. システム開発の未来像 5. まとめ
- 11. 11 1. コンセプト 2. 設計・技術詳細 3. 導入事例 4. システム開発の未来像 5. まとめ
- 13. Immutable Infrastructure 13 サーバのベースラインを作り、 • 必要時のサーバ生成 • 不要時のサーバ破棄 を繰り返し実行できる 仕組み・考え方
- 15. 解決イメージ 15 • テスト環境・データを 個人単位に提供 • テスト環境・データを 壊しても復旧が容易 • ベースライン管理重点 共用不要 気軽に テストできる 環境差分最小化 ＋ 外部システムも 管理可能
- 19. (1) テスト環境 19 • サーバのベースラインを Dockerで「容易に」構築可能 • ベースラインを用意することで 環境ごとの差分を極小化 • 個人単位で提供することで 業務のボトルネック化を回避
- 20. (2) テストデータ 20 • Dockerのベースラインだけを 構築・管理すれば良い • 個人単位で提供することで データ・処理の衝突を回避 • 気軽にテスト可能（失敗OK）
- 21. (3) 外部システム接続 21 • Dockerのベースラインで 構築・設定・管理可能 • 接続先を任意に切り替え可能 （後述） • サービス間通信の確認および 障害の検知が容易（後述）
- 22. 22 1. コンセプト 2. 設計・技術詳細 3. 導入事例 4. システム開発の未来像 5. まとめ
- 23. この章で紹介するもの 23 1. 処理概要のシーケンス図 2. ファイル・コンポーネント 3. コンテナへの移行イメージ
- 24. 処理概要の シーケンス図
- 25. 処理概要のシーケンス図 25
- 31. ファイル・ コンポーネント
- 32. 必要なファイル 32 ファイル名 説明 Dockerfile 下記を対象 • テスト対象サービス • テストデータ • 外部システム Helmチャート • Kubernetesの設定はここ • 接続先の切り替えもここで定義 Jenkinsfile（Jenkins） or config.yml（CircleCI） 全体の処理シーケンスをここで定義 シェルスクリプト Jenkinsfile/config.ymlの 個別の処理を定義 E2Eテストスクリプト KarateによるAPIテスト これ以外は ユーザが用意
- 33. 必要なコンポーネント 33 コンポーネント名 説明 Kubernetesクラスタ 社内のmanagedな Kubernetesを利用（詳細） CIサーバ Jenkins・ CircleCIのどちらも可 Testable Infra CLI Helmチャートの設定簡易化などを 目的に作成した独自CLI testable-infra-bot GitHub App テスト結果の通知や、 不要になったnamespaceの削除 などを担当
- 34. ユーザが用意 Helmチャートのベースライン （Testable Infraが提供） Helmチャート 34 Testable Infra上で動作させ たい サービスのリスト values.yaml Service EnvoyFilter Pod Deployment 実行時に Helmチャートを 左記内容で設定 Testable Infra CLI
- 35. Jenkinsfile 35 pipeline { stages { stage (‘サービスのビルド’) { } stage (‘Dockerイメージのビルド’) { } stage (‘DockerイメージのKubernetesへのdeploy’) { } stage (’E2Eテストの実行・レポート作成’) { } } } 各ステージ内で 当該のシェルスクリプトを 呼び出す
- 37. コンテナへの 移行イメージ
- 42. 物理サーバ／VM コンテナ コンテナへの移行イメージ 42 Front Middle Back Middle Back 徐々に コンテナへ 移行可能 Front
- 43. 43 1. コンセプト 2. 設計・技術詳細 3. 導入事例 4. システム開発の未来像 5. まとめ
- 45. これまで多くの改善を実践 45 • 特殊部隊SETチームの日常 （RSGT2020） • Failure Detection of Microservices with Test and Zipkin （LINE DEVELOPER DAY 2019） • Build Self-Organized Team through Test Automation with Karate （DevOpsDays Taipei 2019）
- 46. 今回の仮説設定 46 • そもそも仕組みとして機能するか？ • テストをしやすくなるか？ • チームに受け容れてもらえるか？
- 50. 仮説検証結果 50 • 開発者を、実装の度にテスト環境を設 定する手間から解放 • 既存のE2Eテストスクリプトは コンテナ上でも正常に動作 • チームが自発的改善を実施 テストを しやすくなった 仕組みとして 機能している チームに 受け容れて もらえた！
- 51. CGWチームの自発的改善 51 • PRコメントで任意のタイミングでテスト を実行できるよう修正 • テストを並列実行できるよう修正（7分 →3分半へ実行時間を短縮） • 全てのPull Request および本番リリースへ適用
- 52. 今後改善が必要な点 52 • インフラのリソース不足を 引き起こすことがある • Jenkinsfileの修正・テストが しづらい（都度deploy要） • ユーザにKubernetesの知識を 要求してしまう箇所がまだ多い
- 53. 53 1. コンセプト 2. 設計・技術詳細 3. 導入事例 4. システム開発の未来像 5. まとめ
- 55. 未来像：社外・コミュニティ 55 • 「コンテナによるテスト改善」の アイデアの更なる発信 • Testable InfraのOSS化 • CNCFへのコントリビュート
- 56. 未来への不安（と期待） 56 • 技術・プロセスなど、 カバーが必要な範囲が広すぎる • 上記の実現が難しいことも理解 • 一緒に実現してくれる仲間を 探しています探していました
- 57. 57 1. コンセプト 2. 設計・技術詳細 3. 導入事例 4. システム開発の未来像 5. まとめ
- 61. 「三悪人」のその先へ 61 • そろそろ不平を言い続けるだけから 卒業しよう • クラウド技術に限らず、 「三悪人」の克服に使える アイデアは増えてきている • 今こそ「三悪人」を斬りましょう
- 63. 輝かしい未来を つかみ取ろう！
Hinweis der Redaktion
- 皆さん、こんにちは。伊藤宏幸です。 このセッションでは、テストに関する様々な問題を解決するためのアイデアの一つとして、前職で研究・導入していた「Testable Infra」についてお話しさせていただきます。
- まずはじめに
- テスト環境：開発・ステージング・本番環境
- 開発者・QAなどのシステム関係者にとって、テストに対する非常に大きな技術的・心理的障壁となります。
- 私たちの会社でも、過去に何度も起きましたし、現在でもたまに起きています。
- [5:30]
- ChefやAnsibleのような「Infrastructure as Code」の考え方の背景にある思想
- 気軽にテストできる→「テストが怖いからしたくない」という状況を改善できる
- 例）AWS CloudFormation、Terraform
- これらを使って、先ほどお話ししたイメージを実現するに至りました。
- テストに対する心理的障壁を一気に下げられる。
- Immutable InfrastructureをDocker/Kubernetesを活用して実現し、「三悪人」の問題の解決を図ろうというのが、Testable Infraのコンセプトです。
- [12:00]
- 物理サーバ/VMをコンテナに移行していくイメージ
- [15:00]
- [22:00]
- 一度にコンテナへ移行する必要はない。 加えて、徐々にコンテナへ移行する作業を、テスト面から支援できる。 テストスクリプトを用意して、プログラムをリファクタリングするのに近いイメージ。
- [25:00]
- 1-2: Problem Solution Fit 3: Product Market Fit
- 一番コンテナ化するのが大変な、リスクの高いコンポーネントから移行した。
- こちらが想定していた以上に、CGWチームのイノベーションのきっかけとなってくれた。
- Jenkinsfile: Pipeline as Codeの弱点
- [33:00]
- フルスタック
- [38:30]
- 例：AI/ML
- 知識のスケールに有益でした。
- [42:00]