様々な環境へコマンドラインツールを提供する上での苦労とその対策 / YAPC::Kyoto 2023

Transcript

1. 様々な環境へコマンドラインツールを提 供する上での苦労とその対策 YAPC::Kyoto 2023 2023.03.19 Presented by Ryosuke Yabuki a.k.a Konboi
2. 自己紹介 ▶ 矢吹 遼介 (Ryosuke Yabuki) ▶ Senior Software Engineer (Launchable, Inc.) ▶ 福島県在住 ▶ SNS ▶ ブログ: https://blog.konboi.com ▶ Github: Konboi ▶ Twitter: Konboi 2 2
3. 今日話す内容 ▶ Launchableについて ▶ launchableinc/cli (launchable command) ▶ 苦労とその対策 ▶ まとめ ▶ 今後 3 3
4. Launchableについて 4
5. Launchableについて ▶ テスト結果および傾向の可視化/分析 ▶ Test Suite Insights ▶ テスト実行の効率化 ▶ Predictive Test Selection (a.k.a PTS) ▶ ※ここでの”テスト”はUnitTestやE2E Testなどの自動テストを指します 5 5
6. Launchableについて ▶ テスト結果&傾向の可視化/分析 / Test Suite Insights 6 6
7. Launchableについて ▶ テスト実行の効率化 / Predictive Test Selection (a.k.a PTS) 7 7
8. Launchableについて ▶ ユーザーはサービスを利用するために 8 8
9. Launchableについて ▶ ユーザーはサービスを利用するために ▶ テスト結果のレポート ▶ Test Suite Insight, PTS 9 9
10. Launchableについて ▶ ユーザーはサービスを利用するために ▶ テスト結果のレポート ▶ Test Suite Insight, PTS ▶ テスト対象を送る/テストすべきリストを受け取る ▶ PTS 10 10 46 test files 36 test files
11. Launchableについて ▶ ユーザーはサービスを利用するために ▶ テスト結果のレポート ▶ Test Suite Insight, PTS ▶ テスト対象を送る/テストすべきリストを受け取る ▶ PTS ▶ Launchable側はマッピングする必要がある 11 11
12. launchableinc/cli 12
13. launchableinc/cli ▶ Python製 ▶ $ pip install launchable ▶ 17のテストランナー(TR)/テストフレームワーク(TF)をサポート ▶ Linux/Windows/Mac ▶ Python 3.5 ~3.10 をサポート ▶ テスト結果を送る / テスト対象をやりとりする ▶ CI環境で利用されることを想定 13 13
14. launchableinc/cli ▶ テスト結果のレポート / launchable record tests 14 14
15. launchableinc/cli ▶ テスト対象の選定 / launchable subset 15 15 46 test files 36 test files
16. launchableコマンドの 苦労とその対策 16
17. 苦労 17
18. 苦労: 複数TR/TFのサポート 18
19. 複数TR/TFのサポート ▶ TR/TFによって ▶ レポートの出力内容 /フォーマットが異なる ▶ 実行可能な単位が異なる ▶ test case, class, file, etc ▶ テスト対象を取得できるもの /できないものがある ▶ 結果: 17のテストランナー(TR)/テストフレームワーク(TF)をサポート 19 19
20. 複数TR/TFのサポート ▶ Perlの場合 ▶ Test Anything Protocol (TAP) ▶ テスト実行時間はSpecには含まれず ▶ 実行時間はテストの分析やテストを効率よく実行する上では欠かせないデータ ▶ TAP::Formatter::JUnitのレポートに実行時間は含まれないが TAP::Harness::JUnitのレポートには含まれる 20 20
21. 複数TR/TFのサポート ▶ TAP::Harness::JUnit のデフォルトのレポートフォーマット ▶ t/00_compile.t → t_00_compile_t ▶ t/00/compile.t, t_00/compile.t ▶ “t/00_compile.t” で受け取りたい ▶ prove ▶ ファイル名/ディレクトリ単位で個別実行が可能だがテスト対象を返す機能はない ▶ launchable command が指定されたディレクトリからテストファイルを取得 21 21
22. 複数TR/TFのサポート ▶ Goの場合 ▶ 標準のコマンドでテスト一覧が取得可能 ▶ go test -list="Test|Example" ./… ▶ 標準でのテストレポートは ▶ カバレッジレポートは標準でサポート ▶ Launchableでは jstemmer/go-junit-report を利用 22 22
23. 複数TR/TFのサポート ▶ Goの場合 ▶ -run optionに対応したフォーマットでテスト対象を出力する必要が ▶ go test -run “^TestExampl1$|^TestExample2$|^ExampleGreeting$” 23 23
24. (再掲)複数TR/TFのサポート ▶ TR/TFによって ▶ レポートの出力内容 /フォーマットが異なる ▶ 実行可能な単位が異なる ▶ test case, class, file, etc ▶ テスト対象を取得できるもの /できないものがある ▶ 結果: 17のテストランナー(TR)/テストフレームワーク(TF)をサポート 24 24
25. 複数TR/TFのサポート ▶ 利用者の多いTR/TFはLaunchableが公式でサポート ▶ 全てのTR/TFをサポートするは難しい ▶ TR/TFの中には使用している Pluginによってレポートのフォーマットが変わるものも ▶ 他にも 25 25
26. 社内TR/TF 26
27. 複数TR/TFのサポート ▶ 社内TR/TF ▶ スクラッチ ▶ OSSをforkして独自に機能を追加している ▶ etc ▶ 仕様を聞いてサポートすることもあるが... ▶ 社内TR/TFサポート用のコードを メインストリームに入れるのは難しい 27 27
28. 苦労: 複数環境のサポート 28
29. (再掲)launchableinc/cli ▶ Python製 ▶ $ pip install launchable ▶ 17のテストランナー(TR)/テストフレームワーク(TF)をサポート ▶ Linux/Windows/Mac ▶ Python 3.5 ~3.10 をサポート ▶ テストの結果を送る / テスト対象をやりとりする ▶ CI環境で多く利用されることを想定 29 29
30. 複数環境のサポート ▶ OS ▶ Linux/Window/Mac ▶ e.g) pathの扱い ▶ Linux/Mac: foo/bar/hoge.txt ▶ Windows: foo\bar\hoge.txt 30 30
31. Cygwin対応 ▶ 稀にCygwin(ローカルの開発)環境で動かない問い合わせ ▶ 担当チケットをCTOにアサインするとシュッと解決 ▶ 31 31
32. 複数環境のサポート ▶ Python3.5~3.10 ▶ EOL ▶ Python 3.5: 2020/09/13 ▶ Python 3.6: 2021/12/23 ▶ Python 3.7: 2023/06/27 ▶ なぜ古いバージョンを切らないのか？ 32 32
33. 複数環境のサポート ▶ 開発者向けツールの宿命 ▶ e.g) ▶ 我々のユーザーのユーザーが 3.5をサポートして欲しい ▶ 我々のユーザーはユーザーのために 3.5をサポート ▶ 我々はユーザーのために 3.5をサポート ▶ CTO曰く ▶ 我々はマラソンで一番後ろを走る人の伴走者 33 33
34. 複数環境のサポート ▶ OS × Python バージョンの組み合わせでサポートが必要 ▶ 古いバージョンをサポートするために新しい機能を使えないことも ... ▶ 更にCI環境による違いも ▶ GitHub Actions, CircleCI, GitLab CI/CD, Jenkins ▶ ビルド番号やビルドURLを取得するための環境変数の違いなど 34 34
35. 閑話休題: なぜPythonなのか 35
36. なぜPythonなのか ▶ 最初に担当したエンジニアが最も得意だったのがPython ▶ Perlも選択肢にあったが Windows対応を考えるとPythonに軍配 ▶ Go/Rustならよかったのか？ ▶ 配布方法/アップデートの仕組みを考える必要がある ▶ plugin 機構をどう提供するのか悩ましい 36 36
37. 苦労: エラーハンドリング 37
38. エラーハンドリング ▶ CIに組み込む都合上サービス側(Launchable)の都合で止めてはいけない ▶ テストはPASSしているのにLaunchableへのリクエストがエラーで FAILに...はNG ▶ Launchableがシステム障害で落ちていても動作させる必要があります ▶ エラーにすべきものもある ▶ 設定ミス ▶ 不正なパラメーターの組み合わせ ▶ etc 38 38
39. 苦労 ▶ 複数TR/TFのサポート ▶ 複数環境へのサポート ▶ エラーハンドリング 39 39
40. 対策 40
41. 対策 ▶ plugin 機構 ▶ raw profile ▶ テスト & ドッグフーディング ▶ エラーメッセージ 41 41
42. plugin 機構 ▶ plugin機構をサポート ▶ plugin ファイル (Pythonファイル)を任意のディレクトリに設置 ▶ 実行時にディレクトリを指定 ▶ launchable –plugin plugin-dr/ ▶ 社内TR/TFなどに対応 ▶ plugin作成方法のドキュメントは不十分 ▶ Launchable Advent Calendar 23日目 - custom plugin 42 42
43. raw profile ▶ 個別にpluginを提供するのはコストが高い ▶ 入出力フォーマットを定義しユーザー側で対応してもらう ▶ サポートコストは減る ▶ 複雑なフォーマットではないがユーザー側の対応コストが増える ▶ plugin 機構/ raw profile よりも良いアイディアがあれば採用したい 43 43
44. テスト & ドッグフーディング ▶ 実装中に気を付ける には限界がある ▶ Matrix test ▶ Windows/Linux ▶ Python version 3.5 ~ 3.10 ▶ E2Eテスト ▶ launchable コマンドのリリース前に複数の主要プロファイルでベースシナリオを実行 ▶ 定期実行を行いAPI側が互換性を崩してないかもチェック 44 44
45. テスト & ドッグフーディング ▶ Launchableの開発環境では最新版(main branch)を使用 ▶ API側の開発ブランチがmainにマージされる度に開発環境へE2Eを実施 ▶ launchable commandの大きい機能をリリースする際はマージ後 開発環境で数日様子をみてからリリースすることも ▶ ミスを100%防ぐことは不可能なので早く気付ける仕組みを厚くしている 45 45
46. エラーメッセージ ▶ エラーメッセージを分かりやすく ▶ なぜエラーになっているのか ▶ どうやったら解決するのか ▶ ユーザー側で解決できるのが理想 ▶ 地味。だが効果大 46 46
47. まとめ ▶ 様々な環境へ提供する上での苦労について紹介 ▶ TR/TFの差、OSの差、エラーハンドリング ▶ 残念ながら解決方法に銀の弾丸は無い ▶ 問い合わせや起こしてしまったエラーに対して一つ一つ対策していく ▶ 抽象度のレベルをあげて解決できるように気をつけている 47 47
48. 今後 ▶ 中期的 ▶ EOLバージョンのサポートコストと plugin機構の提供方法を踏まえて脱 Python ▶ 長期的(野望) ▶ テストレポートフォーマットの標準化 ▶ 各テストランナーへの機能提案 48 48
49. Thank you! 49
50. Questions 50
51. 51 We’re hiring
52. Thank you! 52