E2E テストワークフローの高速化のためにやったこと

E2E テストワークフローの 高速化のためにやったこと 2024.10.02 サイボウズ株式会社 福田航生 1

自己とチームの紹介 福田 航生 • X (Twitter): @man_2_fork • Garoon という大規模向けグループウェア製品 の開発をやっています 右側が本人です（嘘） 2

背景 • Garoon 開発チームでは、Four Keys に基づいてリリースを改善してきた • Four Keys とは DORA が提唱しているソフトウェアデリバリーのパフォーマンスを示すメトリクス • デプロイ頻度、変更のリードタイム、変更障害率、障害からの復旧時間 • 改善が功を奏し、リリースプロセスは軽量になった • デプロイ頻度が 8 倍に増加 • 変更のリードタイムが 1/10 に短縮 • 障害変更率が 1/8 に低下 • サービス復元時間が 1/8 に短縮 詳細はこちら: Four Keysに基づくリリースプロセス改善とその成果 https://speakerdeck.com/ak1210/release-process-improvement-based-on-the-four-keys-and-itsresults 3

• https://speakerdeck.com/ak1210/release-process-improvement-based-on-the-four-keys-and-its-results

リリースプロセスは軽量になったけれど…… E2E テストが通らなくて 一生リリースできないよ…… E2E テストワークフローの改善を進めていくことに…… 4

E2E テストが通らない理由 • CI で実行している E2E テストワークフローが不安定 • 不具合が検出されているわけではない • 不安定要因は以下の 2 つに集約される • テスト実行環境が不安定 • テスト自体が不安定（flaky test） • これまでにも、いろんな対策を行ってきた • レートリミット回避 • キャッシュの改善 • ワークフローのタイムアウト設定 • 何度か失敗するのは許容することにし、ジョブを自動で再実行 詳細はこちら: E2Eテストワークフローを高速化・安定化させる取り組み https://www.docswell.com/s/r4mimu/ZXYR73-2024-05-16-184345 5

• https://www.docswell.com/s/r4mimu/ZXYR73-2024-05-16-184345

テスト実行環境が不安定 • Amazon ECS に構築した環境でテストを走らせている • Garoon が systemd を使用しているため、privileged: true なコンテナで立ち上げる必要があった • ECS on EC2 を使用する必要がある • EC2 インスタンスの不調が不安定要因になっていた • ECS に service を立てて、GitHub Actions から見えるようになるのを待っていた • テストの並列実行のためにたくさん環境を立てる必要があり、都度サービスや ALB を立てていていた • AWS 上に複数のリソースを作っていて、複雑 • 消すのも大変 6

テスト実行環境が不安定問題の対処 1: privileged コンテナをやめる • 本物の systemd のかわりに docker-systemctl-replacement という OSS を使うようにした • systemd っぽい振る舞いをする Python スクリプト • systemd の辛みが消えるかわりにこのスクリプトの辛みが生える 懸念もあったが、小さいスクリプトのためデバッグも比較的容易と 判断 • 本家では動かない機能を使っていたため、フォークを使用 • systemd を使わなくなったため、特権コンテナが必要なくなった https://github.com/pakutoma/docker-systemctlreplacement • もともとは CI ではなく、開発用の Docker イメージのために導入したもの • ローカルの開発環境もシンプルになり、みんなハッピーに 7

• https://github.com/pakutoma/docker-systemctl-replacement

テスト実行環境が不安定問題の対処 2: ECS の service をやめる • mirage-ecs という OSS でデプロイを行うようにした • ECS でコンテナを立ち上げて、それにリバースプロキシしてくれる • API が生えていて、HTTP でリクエストを送ればタスクの 起動や停止ができる • 一定期間使ってないインスタンスは勝手に落としてくれる • まるで蜃気楼のようだ……（？） • CI でケアするリソースが ECS のタスク定義だけになった https://github.com/acidlemon/mirage-ecs • ALB が 1 個で済むので、コスト的にも嬉しい！ • （特定の条件で panic するバグがあったので PR 送ったんですが、ちゃんと対応してもらえて助かりまし た） 8

• https://github.com/acidlemon/mirage-ecs

テストが不安定 • 不安定なケースを特定して修正する活動は行っている • でもけっこう大変 • ある程度は失敗を許容しつつ、再実行を素早く行えるようにする 9

テストが不安定な問題の対処 1: ワークフローの自動リトライ • E2E テストのワークフローが失敗した場合も、3 回までは再実行を許容する • 環境要因の失敗があるので、デプロイからやり直してもらうのが手っ取り早い 10

テストが不安定な問題の対処 2: 失敗したケースのみを再実行 • ワークフローを再実行する際、既に成功したテストケースを実行しない • 通ったケースも再実行すると遅くなるし、不安定なテストが複数含まれている場合に無限リトライ編になる • 通ったテストケースのリストを S3 に保存しておき、再実行の際は失敗したケースだけを実行する 11

まとめ & これから • テスト実行環境の改善と、テスト自体の不安定性の影響を小さくする活動をした • でも、E2E テストが不安定な問題はまだまだ残っているのが現実…… • 快適な開発環境の維持には継続的な活動が必要 • テスト自体も良くして、開発の高速化と開発者体験向上していきたいですね！ ま、前よりはだいぶ楽になったかな～ 12

©️ Cybozu, Inc. 13