Code Push 時のビルドとテストの自動実行

[konabuta]

現状、smoke-testing しか無いので、今後何を追加していくかをこの Issue で議論したいです。

Wiki にも書きましたが、次のパイプラインが必要になると考えています。

• コード品質の確認
• Smoke Test
• Unit Test
• コンテナーのスキャン
• 依存関係のスキャン

[konabuta]

これ Discussions に移行した方が良さそうな内容ですかね...

[shohei1029]

どう使い分けます..？
すみませんあまりdiscussionsを使いこなしたことがなく..
特に使い分けの分かりやすい目安・基準がなく、またIssuesの数が多すぎるという課題がなければ、議論の場所をIssuesとDiscussionsに分散させずにもうIssuesに統一させちゃってもいいんじゃないかという気も個人的にはします。

[shohei1029]

Memo:

• Googleが提唱するTestSizeとJava,MavenによるTestSizeの実現方法について - Qiita
• https://ploomber.io/blog/ml-testing-i/

[konabuta]

• Smoke testing

  • 目的 : 実装したコードがちゃんと動くかどうかのテスト
  • ディレクトリ単位もしくはタスク単位で、変更箇所についてちゃんと動くか確認する
  • なるべく早く処理が終わるように工夫する (1分程度)
    • 例
      • Azure ML Job は実行できるかどうかだけを見る
      • 乱数で生成した少量データでモデル学習をする
      • エポック数を減らす

• Code quality

  • 目的 : コードの品質を維持・向上する
  • Linter, Formatter, pre-commit を利用する

• Unit and Integration testing

  • 目的
    • Unit testing : 開発したコードのブロック (関数やコンポーネント) の動作確認
      • Pull request や Push に対して実行
    • Integration testing : Loop 単位もしくは機械学習ライフサイクル全体の動作確認
      • ある程度の処理時間は許容する (5~15分程度)
        • git commit や push ごとではなく、夜間バッチでの実行 etc

• Security scanning

  • 目的 : セキュリティリスクがないかの確認
    • コード、パイプライン、コンテナが対象

[konabuta]

こんな体系を考えているのですが、違和感や改善点あります？

[ShuntaIto]

unit test については常時実行というか CI の一環として GHA で実装して、例えば PR に対して実行してテスト通過をマージ条件にすると良いと思ってます
つまり git commit ごとの実装 (多分ローカルで pre-commit で実行？) は流石にやりすぎと思いますけど、Github 側で push 単位ではありかなと思います

integration test のレベルまで GHA でやるべきかは議論の余地ありそうです
実際に実装したテストの重さを見て決めるのでも良いかもです

[konabuta]

Unit testing の部分を PR か Push をトリガーするような記載にしておきました ↑
Integration test は今回は軽量データなので GHA で実装してしまって、今後の拡張として GHA の外で実行するような仕組みも考えたいと思います。

[konabuta]

Shohei (@shohei1029) さんもコメントあれば是非〜

[shohei1029]

まとめて頂きありがとうございます。伊藤さんの PR に対して実行してテスト通過をマージ条件にするのは私も賛成です。azureml-examplesもそういう形を取っています。

[konabuta]

<メモ>
Unit and Integration testing についてはまだ実装できていない状況です。