Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
自動E2Eテストを活用した デプロイフロー改善
Search
Yosuke Obata
April 26, 2023
Programming
6
1.6k
自動E2Eテストを活用した デプロイフロー改善
MagicPodミートアップの発表スライドです。
https://trident-qa.connpass.com/event/278843/
Yosuke Obata
April 26, 2023
Tweet
Share
More Decks by Yosuke Obata
See All by Yosuke Obata
Kotlin + DGS で始めるスキーマファーストな GraphQL サーバー開発
sukechannnn
0
260
結婚式の席札を手書きしたくなかったので技術で解決した話
sukechannnn
1
4.1k
統計学に入門したので確率変数/期待値/分散をなるべく分かりやすく説明してみる
sukechannnn
1
510
Other Decks in Programming
See All in Programming
StarlingMonkeyを触ってみた話 - 2024冬
syumai
3
290
歴史と現在から考えるスケーラブルなソフトウェア開発のプラクティス
i10416
0
150
Recoilを剥がしている話
kirik
5
7.4k
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
200
ドメインイベント増えすぎ問題
h0r15h0
2
460
nekko cloudにおけるProxmox VE利用事例
irumaru
3
470
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
9
2.1k
선언형 UI에서의 상태관리
l2hyunwoo
0
220
menu基盤チームによるGoogle Cloudの活用事例~Application Integration, Cloud Tasks編~
yoshifumi_ishikura
0
110
return文におけるstd::moveについて
onihusube
1
1.3k
LLM Supervised Fine-tuningの理論と実践
datanalyticslabo
7
1.6k
Асинхронность неизбежна: как мы проектировали сервис уведомлений
lamodatech
0
1.1k
Featured
See All Featured
A designer walks into a library…
pauljervisheath
205
24k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Making the Leap to Tech Lead
cromwellryan
133
9k
Embracing the Ebb and Flow
colly
84
4.5k
Become a Pro
speakerdeck
PRO
26
5k
A Tale of Four Properties
chriscoyier
157
23k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Building Adaptive Systems
keathley
38
2.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Transcript
自動E2Eテストを活用した デプロイフロー改善 2023/04/26 @sukechannnn
⾃⼰紹介 ⼩幡 洋介 (@sukechannnn) テックリード 2021年12⽉アルダグラムにジョイン • 昨年: 多⾔語対応(英語/タイ語/スペイン語) •
現在: SREチームでデプロイ基盤の改善 • ⾃動E2Eテストの整備をリード 趣味︓⾳楽 (ドラム)、焚き⽕ ⼦育て奮闘中
会社・プロダクトの紹介
None
COMPANY 会社概要 5 会社名 設⽴ 代表者 所在地 従業員数 累計 調達⾦額
株主 株式会社アルダグラム 2019年5⽉8⽇ ⻑濱 光 (東京本社) 東京都港区芝浦⼀丁⽬ 1 番 1 号 浜松町ビルディング11階 (マドリードオフィス) Monasterio de Urdax, 49, 31011 Pamplona, Navarra, Spain 68名 (2023年4⽉1⽇時点) 21.4億円 ジャフコ / インキュベイトファンド 株式会社MonotaRO /株式会社LIFULL サンネクスタグループ/経営陣 ほか
HISTORY 会社沿⾰ 3⼈ 12⼈ 13⼈ 20⼈ 25⼈ 2019.05 2019.12 2020.07
2021.10 2022.03 2022.05 会社設⽴ プロジェクト管理アプリ 「KANNA」をリリース 神楽坂へ本社移転 ⽇本橋へ本社移転 「KANNA] 導⼊5,000社突 破 シリーズAで 約20億円の調 達 48⼈ 2022.11 52⼈ 2022.12 浜松町へ 本社移転 「KANNA] 導⼊10,000社突 破 30⼈
KANNA(カンナ) は、 建設業、不動産業、製造業など、 世界中のノンデスクワーク業界における 現場の⽣産性アップを実現する「プロジェクト管理アプリ」です。 事務作業や移動、コミュニケーションの⼿間を カンナのように削り、作業の⽣産性を最⼤化します。 スマホでの使いやすさが⽀持され、 業界・国境を越えて⾼い評価をいただいております。 PRODUCT
KANNA で解決できる課題 8 現場にいながら、スマホ・タブレットで業務効率化︕ 現場情報を ミスなく共有 最新の資料へ ワンクリック 移動コスト ⼤幅削減
チャットで 即やりとり 写真だけで 1分で報告書 PC。スマホ。タブレット。 最新情報をどこでも確認でき るから、メールや電話による ミスや⼿間がなくなります。 間違って古い資料を⾒てしま うなんてミスも解消。 迷うことなく最新資料にアク セスできます。 リアルタイムで現場状況をシ ェアできるため、確認のため に何度も現場と往来していた ⼿間が省けます。 これまでのメールや電話での やり取りをチャットでスピー ディーに︕ チャットの活⽤で連絡漏れも 防げます。 ExcelやWordでの報告書がす べて写真を選ぶだけのやりと りに。事務作業の負担が⼀気 に減ります。
開発チームの現状と 今までのデプロイフロー
プロダクト開発本部 企画・デザイン 開発 KANNA プロジェクト管理 KANNA SRE KANNA アプリ 開発チーム構成
デザイナー 2名 PdM 2名 エンジニア 6名 エンジニア 7名 エンジニア 3名 KANNA グロース エンジニア 6名 KANN 新規プロダ エンジ エンジニアの⼈数は1年で倍以上に チームの数もすごく増えてきている
課題 • どこか1つでもリリースできないバグが⾒つかると、別の機能の開発物もリ リースが遅れる • 2週間に1回しかデプロイしないので、バグ修正などの急いで出したいもの もなかなか本番反映できない • 1回のリリース時の影響範囲が広く、テスト範囲が「全部」みたいになる ◦
⇢ これは MagicPod である程度は解消した✨ 元々のデプロイフロー(Web) 今までは2週間に1回デプロイしか デプロイしていなかった
今取り組んでること シン・デプロイフロー
リリーストレインの考え⽅を採⽤ 毎⽇決まった時間にデプロイ・その時点で出荷可能なものをリリース(乗り遅れたら置いていく)
シン・デプロイフロー • 開発した個別機能のチェックはqa環境で ⼿動テスト • 全体リグレッションテストは MagicPod で⾃動テスト 開発⇢テスト⇢デプロイ を⾼頻度に⾏うこと
で価値を素早く届けバグを減らす QA 3名 デプロイ頻度を 2週間に1回⇢週1回⇢週2回⇢毎⽇ に増やす︕
qa環境 / pre-prod 環境の構築 • qa環境: 開発した機能毎に動作確認できる環境をたくさん作れる基盤を整備 • pre-prod環境: 本番環境に限りなく近い環境でテストできる基盤を整備
MagicPod によるE2Eテストの⾃動化 • 増え続ける機能のテストを全て⼿動で網羅するのは不可能なので、⾃動化して網 羅テストはMagicPod に置き換えていった • 昨年から継続して取り組んできていて、MagicPod のおかげでシン・デプロイフ ローが実現した シン・デプロイフロー実現のために取り組んできたこと
MagicPod の整備について
テスト整備の運⽤⽅法 ⼿動テストのシナリオをベースに MagicPod でテスト実装 • 元々は⼿動で全ての機能をテストしていて、そのシナリオがスプレッドシートにまとまっ ていたので活⽤ • ⾃動化できているものを判別できるようにして、テストの網羅率を判定 •
◯: ⾃動化済み ◆: ⾃動化可能だが未対応 - : ⾃動化できない(ダウンロード系な ど) • 機能追加されたら「テストシナリオ追加⇢⼿動テスト実施⇢問題なければ⾃動化」という 流れで継続的に整備
MagicPod が安定化するために data-testid の整備 • ロケータを特定するための情報がフロントエンドになく、E2Eを実装しても不安定だった • テスト⽤に data-testid を全ページに追加することで、テストが安定するようになった
• data-testid は単体テストや Visual Regression Testing でも活⽤してる 毎⽇テストを回して落ちたテストを修正 • 毎⽇決まった時間に開発環境と本番環境の両⽅でテストを回して、落ちている箇所を確認 している • テストの結果は Slack 通知してQAエンジニアがチェック • テスト結果を⾒て、改修によるエラーであればテスト修正、そうでなければバグ報告 • 継続的にチェックし続けることがだいじ
デプロイOK/NGの判断 E2Eの結果は⼈が解釈する • E2Eテストが全てOKでなくてもリリースして良い場合はある • そのため「E2Eがオールグリーンになったらリリース」のような運⽤にはしていない E2Eをオールグリーンにすることが⽬的ではない • むしろ定期的にエラーになった⽅が、差分を検知できているという意味で安⼼感がある •
シナリオ100個に対して5個くらいのエラーくらいがちょうど良い割合という肌感 • 同じところで継続的にエラーになっているのを放置すると割れ窓になる • そこはエンジニア側で改修する
ユニットテストとE2E (MagicPod) E2Eテストで全てのパターンを網羅することはできない • 権限周りや機能の組み合わせなどを全て網羅しようとすると組合せ爆発になる • そのため、ユニットテストの整備も継続して⾏っている ユニットテストでコードの振る舞いを、E2Eでユーザーの振る舞いをテスト • ユニットテストが書かれたロジックが積み上がることで、予期せぬ挙動を防ぐことができる
• そのため、新規実装では基本的に全てテストを書いているし、過去のコードにテストを追加する 活動も⾏っている • フロントエンドも︕
まとめ
まとめ E2Eは⾃動化しないと増えていくテストに対応し続けられない • 機能が増え続けるとテスト⼯数は機能以上に増えていくことになる • ⼈がチェックするのは「機能が受け⼊れ条件を満たしているか」にフォーカスすべき • リグレッションテストは⾃動E2Eツールに任せよう MagicPod はエンジニアじゃなくてもテスト実装&運⽤できる強い味⽅
• 使えるコマンドが豊富なため、ノーコードで様々なシナリオに対応可能 • ⾃動修復が優秀なので、細かいUI変更には簡単に追従できて運⽤が回る • エンジニアの協⼒は不可⽋...E2Eしやすい実装にしよう MagicPodでリグレッションを検知できるから、デプロイ頻度を増やせる • 全てを⼿動でチェックしていたら不可能だが、ユニットテストだけではテストとして不完全 • ユニットテストでコードの振る舞いを、MagicPod でユーザーの振る舞いをカバー
今後取り組みたいこと モバイルの E2E を MagicPod で安定してテストする • Android / iOS
両⽅あり、React Native + Native Module (Kotlin, Swift) という構成なのもあ り、現状 MagicPod がなかなか安定しない • Webに⽐べると data-testid に相当するものの整備もできておらず、なかなか安定しないので、 まずは id の整備からやっていきたい 機能のマージをトリガーに MagicPod でテストする • 最近、何もしてないのにテスト時間が 4時間 ⇢ 2時間ちょっとに短縮されたので、開発した機能 ごとに MagicPod を実⾏して結果を通知する、という運⽤の実現可能性が⾼くなってきた • 将来的には、差分のある機能のテストだけ MagicPod でテストするようにできれば、⾼頻度な E2E テストが実現できそうなので、やっていきたい