Zenn
レバテック開発部
🌟

AutifyでCI/CD連携できるまでにやったこと

azm
2024/10/01に公開
E2E
Autify
tech

こんにちは！レバテック開発部の小豆畑です。
先日弊社のブログで紹介されていたE2EテストサービスAutifyをCI/CDに連携しました！結論、とても簡単に連携できました！
https://zenn.dev/levtech/articles/28d98632fcfeb2
この記事では連携するまでに考えたこと、連携に使用した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通知
設定するとこんな感じでslack通知が届きます。簡単に設定できます。

おまけ情報
シナリオのURLを設定すると実行結果がAPI excutionというタイトルになるようでした。
Autify_シナリオ紐付け
ymlファイルの中でシナリオのURLを設定すると実行結果のタイトルがAPI excutionになる

まとめ

いかがでしたでしょうかー。連携簡単だなぁと思いませんでしたか。
CI/CD連携が行われ自動で実行される基盤が整ったのでより良いテストシナリオを作成して、運用して、少しでも障害を減らせるよう頑張ります💪

レバテック開発部
レバテック開発部

レバテック開発部の公式テックブログです！ レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech

Discussion