「CI/CD Test Night #7」に参加してきました

• 2024/3/26
• https://testnight.connpass.com/event/311263/

業務で役立つ…かもしれない？！GitHub Actions Tips 集

• @ponkio_oさん
• https://speakerdeck.com/ponkio_o/cd-test-night-number-7

matrix job

• 似てるけど微妙にパラメータが違うジョブ
  • まとめて並列実行したい
• matrix jobでパラメータを差し替えながら並列実行できる
  • バージョンとかOSだけ変えてまとめて動かすとか
  • 複数の条件の組み合わせで動かせる
• inputにjsonを使えるのが便利
  • workflowの外からデータを注入できる
• secretsを出し分けたい場面がある
  • matrixではkeyだけ指定して使うといい

動的job実行

• Branch Protection
  • PR作成時にCIが通らないとマージできないとか
  • 条件にjobを指定できる
• jobをフィルタリングしたくなることがある
  • 実行時間や課金面で毎回全部動かしたいわけではない
• pathsフィルター
  • 特定のファイルが更新された時に実行させることができる
  • 対象外だった時にworkflowが動かずpendingでマージがブロックされてしまう
    • pathsフィルターとBranch Protectionの相性が悪い
• paths-filterを使ってworkflowは実行しつつjobをフィルターできる
• Status Check Job
  • このjobをpass/failさせることでBranch Protectionを機能させる
  • passの条件
    • exit 0で終わる
    • jobをスキップして実行されない

GITHUB_TOKEN

• GitHub Actions上で利用可能なGitHubのtoken
• GITHUB_TOKENによるコミットではworkflowをトリガーできない

CI/CD のセキュリティや Developer Experience を改善するツールやプラクティス

• @szkdashさん

PRコメントでCIの結果通知

• CIがこけたら原因をPRにコメントしたい
  • ログ見に行くよりすぐ見れてわかりやすい
• github comment
  • コメントのテンプレートも用意できるので使うと見通しがよくなる
  • 古いコメントを非表示にして新しくコメントできる

複数リポジトリのメンテナンス

• 同じような変更を複数リポジトリに入れるの大変
• 共通化されたツールをメンテすれば楽になる
• Renovateで各リポジトリに配布

GItHub Actionsのセキュリティベストプラクティス

• ベストプラクティス
  • jobのpermissionsを最小限
  • secretの公開範囲を最小step/job
  • Actionのバージョンをfull commit hashで固定する
• ghalintでチェックできる
  • CIで実行してセキュリティを担保
• ツールのバージョン固定
  • ツールが汚染されてもいきなり反映されない
  • コードを変更してないのにCIが壊れるようなことを防ぐ
  • バージョンやタグもあるが変更されることがある
    • フルコミットハッシュが一番安全
  • コードコメントでバージョンを書けばRenovateも見てくれる
    • バージョンはパッチまでしっかり書くと更新時の差分が見やすい

CIで使うツールの管理

• バージョン固定
  • latestは突然壊れる
• ツールの自動アップデート
• shellでやるのは面倒
• aqua
  • yamlでツールとバージョンを管理できる
  • https://github.com/aquaproj/aqua

一歩先のセキュリティ

• CIを書き換えられないようにする
  • 任意のコード実行を防ぐ
  • 強い権限与えないといけない時特に
  • pull_request_target event
• feature branchのスクリプトを実行するのは危険

古いrevisionでの実行を防ぐ

• defaultブランチの最新のHEADかチェック

CI/CDがあたりまえの今の時代にAPIテスティングツールに求められていること

• @k1LoWさん
• https://speakerdeck.com/k1low/cd-test-night-number-7

runn

• https://github.com/k1LoW/runn
• yamlでシナリオを書いて操作できるツール
  • コマンドラインから実行できる
• APIのシナリオテストができる

runnの機能

• 1バイナリで作られてる
• さまざまなプロトコルに対応
• OpenAPI Specライクなシナリオ
• 複数のシナリオが想定されている
  • 分割実行
  • サンプリング実行
  • ランダム実行
• プロファイルの取得
• ステップ実行できる

APIテストのモチベーション

• アプリケーションの外側からテストしたいというニーズ
  • APIスキーマファーストの開発
  • マイクロサービス
• スモールテストよりコストが高い
  • 実装コスト
    • 環境整備が面倒
  • 実行コスト
• CIでの自動実行が前提になってる
  • コンピューティングリソースは気にならなくなった

APIテスティングツールに求められること

ChainingRequestに対応していること

• 複数リクエストで成り立つテストが求められる
• 個別に作るより実は低コスト
  • 認証トークンが必要なAPIなど面倒

親和性の高いテストダブル環境

• 規模が大きくなりがち
• テストダブルをアプリの外で構築できると望ましいが難しい
• Postmanはstubサーバのサポートがある
• runnはないので自前でstubサーバ動かしてやる
  • https://k1low.hatenablog.com/entry/2023/12/12/083000

テストケースにIDがあること

• テストを一意にできるIDが必要
  • 全てを毎回実行するのはコストが高い
• IDとメトリクスの連携
  • 特定のものだけリトライとか
  • 実行時間を特定するためにとか
  • よく失敗するのを先にとか
  • IDを使うと柔軟にできる
• runnは自動で動的に生成してる

APIスキーマとの連携がある

• テストケース自体がある程度正しいことを確認したい
  • APIスキーマと合致してなければエラーとか
• runnでは各ランナーにAPIスキーマを設定できる

ポータビリティがある

• 開発環境とCI環境で同一の環境にしやすいこと
• 負荷試験としても活用できる
• 本番強への外形監視/計測として使える
• runnではいろんな環境で使えるようにしてる

リリース戦略を支えるCI/CDパイプライン

• @katzchumさん

リリース管理のつらみ

• システムが複雑になり依存が増えると管理が複雑になる
  • リリース判断できる人が固定化されてくる

リリース戦略の事例

• 複数バージョンが並行するプロダクト
  • クライアントによってバージョンが違う
• リリーストレイン
  • リリースの日が決まっていて間に合ったものだけリリースする
• ブランチカットするタイミング
  • リリース日が未定な状態でもタグをつける
  • 開発環境にデプロイするタイミングでタグつける
• タグはOSSの開発スタイルに倣う
  • セマンティックバージョニング
• tagpr
  • リリース用のPRがCIで作られる
    • changelogとかリポジトリ内のバージョンの更新をしてくれる
  • マージするとtagができる
  • https://github.com/Songmu/tagpr