こんにちは！レバテック開発部の小豆畑です。
先日弊社のブログで紹介されていたE2EテストサービスAutifyをCI/CDに連携しました！結論、とても簡単に連携できました！
この記事では連携するまでに考えたこと、連携に使用したymlファイルをご紹介します。
Autifyの導入状況
- 今年の6月ごろから導入された
- 消費できるstep数に上限があり手動実行や定期実行のみ許可されていた
- 8月にCI/CD連携の許可が降りた
導入前に考えたこと
私のチームでもAutifyを6月から使っていて、画面遷移や重要な登録処理など一通りのテストシナリをは作成済みでした。
連携解禁されるということで私のチームも早速連携することにしたのですが、実際に連携する前に、効率の良いテストが実行できるよう、重要な実行タイミング、テストケースの優先度、実行頻度について連携を開始する前に検討しました。
実行タイミング
実装からリリースまでどのタイミングでどのくらいのテストを流すのが良いかを考えました。
私のチームではgit flowのreleaseブランチが無い版で機能のリリースを行なっています。実装からリリースまではおおまかに以下のような流れ。
① developから作業用ブランチを作成して実装
② 作業用ブランチからdevelopにPullRequestを作成
③ 承認後developにマージ（検証環境でdeployが走る）
リリースできないものはマージしない
or フラグを持たせて機能しないようにする
④ 必要な処理がdevelopに揃ったらdevelopからmainにマージするためのPullRequestを作成
⑤ 承認後mainにマージ
⑥ タグを作成する（本番環境でdeployが走る）
テスト実行タイミングとして考えられたのは③、④の検証環境でのテスト、⑥の本番環境でのテストでした。
優先度
実行タイミングとして考えたテストの優先順位を考えました。
1. ④の検証環境でのテスト
2. ⑥の本番環境でのテスト
3. ③の検証環境でのテスト
リリース直前、機能が出揃った④の検証環境でのテストを最重要のテストタイミングとし、そのタイミングですでにチームで作成していたすべてのシナリオを実施することを最初の目標と設定しました。
実行頻度
1週間でだいたいこのくらいまでならOKという基準になる消費step数があったので、④⑥③がそれぞれどのくらいの頻度で発生するのか、過去の情報から大体の回数を確認しました。
1. ④の検証環境でのテスト → 3回/week
2. ⑥の本番環境でのテスト → 4回/week
3. ③の検証環境でのテスト → 20回/week
シナリオは既に作成していたシナリオを使用するので、一回あたりの消費step数も数字としては用意できていたので、これで一週間での消費step数が概算できました。
AutifyではChrome、Safariなどブラウザの指定もできるので、許可されているstep数に対して余裕があればクロスブラウザチェックも行うことができます。
あまり余裕がなければ、重要な機能だけ複数のブラウザで確認するのもありですね。
step数的には問題なさそうということで、1. ④の検証環境でのテストで作成していたすべてのシナリオを連携することにしました。
導入時にしたこと
冒頭でも書きましたが、導入自体は本当に簡単でした！PATの用意とテストプランの作成、workflowの作成の簡単3stepです！
AutifyのPATを作成する
詳しくはAutifyで用意されたGitHub Actions 連携にすべて書いてあります。
パーソナルアクセストークンの発行して、GitHubのシークレットに作成したPAT情報を保存します
AutifyでCI用のテストプランを作成する
連携はテストプランのurlを使用します。紐づけるシナリオを好きに変更できるように手動実行や定期実行用のテストプランとは別に連携用のテストプランを用意しました。
連携確認のために適当なテストシナリオを最初に紐付けました。連携確認が出来次第、すでにあるシナリオをすべて連携し、すべての実行環境を対象に設定しました。この時テストが失敗した時の挙動も確認しておくと安心です。
こんな感じで連携用のテストプランを作成しました。
連携のテスト用に2stepだけのシナリオを用意。
導入するリポジトリでGitHub Actionsのworkflowを作成する
1. ④の検証環境でのテストが自動で実行されるようにymlファイルを作成しました。
name: e2e-stg
on:
pull_request:
branches:
- main
jobs:
e2e-test:
if: github.head_ref != 'hotfix/*'
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- name: RUN AUTIFY TEST => 【LTF】【STG】CI/CD連携用
uses: autifyhq/actions-web-test-run@v2
with:
access-token: ${{ secrets.AUTIFY_WEB_ACCESS_TOKEN }} //登録したシークレット情報を参照
autify-test-url: https://app.autify.com/projects/00/test_plans/000 //連携するテストプランのURL
wait: true
timeout: 600
if: github.head_ref == 'develop'
障害対応など緊急時にhotfixブランチから迅速にリリースするために、developからmainに向けられたPullRequestのみ実行されるようにしました。
wait: true
テスト実行終了をGitHub Actions側で待つことが出来ます。設定しない場合は非同期実行となり、Autify側でテストが成功したかどうかを確認せず、jobは終了になります。tureを設定した場合は、Autifyのテストで失敗するとjobもfailedになります。
timeout: 600
wait: trueを設定した場合timeoutがデフォルトの300sで実行されます。wait: trueでかつ5分以上かかるテストを連携する場合は必ず設定する必要があります。GitHub Actionsのコストの観点からあまり大きな値を設定せず、適切な値を設定しましょう。
どの段階でjobを終了させるのかはコストとも関わると思いますので、状況に応じてslack通知を使うのも良いと思います。テストの結果をslackチャンネルに通知することもできるので投げるだけ投げさせて、結果は別で確認としても良いかなと思います。
設定するとこんな感じでslack通知が届きます。簡単に設定できます。
おまけ情報
シナリオのURLを設定すると実行結果がAPI excutionというタイトルになるようでした。
ymlファイルの中でシナリオのURLを設定すると実行結果のタイトルがAPI excutionになる
まとめ
いかがでしたでしょうかー。連携簡単だなぁと思いませんでしたか。
CI/CD連携が行われ自動で実行される基盤が整ったのでより良いテストシナリオを作成して、運用して、少しでも障害を減らせるよう頑張ります💪
Discussion