- 印刷
- ダークライト
Autify のエンドツーエンドテストをコードレビュープロセスの間に実行することで、ステージングや本番環境と同様のやりかたで、提案された変更を検証することができます。このドキュメントではこの連携の利点とどの様に実現するかを解説していきます。
Autify でCI/CD ではCI/CD の一般的な概要とコードレビュープロセスを含めた、CI/CD 連携の可能性について説明しています。
もしまだ読んでいなければ、そちらを最初に読むことを強くお勧めします!
なぜコードレビュープロセス中にAutify を実行するのでしょうか?
コードレビューはソフトウェアリリースプロセスにおける最初のステップです。ある人がコードベースにいくつかの変更を提案し、それを他の人が、正しい変更なのか、期待通りに動作しているか、不必要に機能を壊していないか、等をレビューします。世の中には、コードレビューをより簡単で信頼でき広い視野から見られる様にする自動化のテクニック、例えばユニットテスト等がたくさん存在します。ユニットテストではソフトウェアの多くの機能性をカバーすることができますが、加えていくつかのエンドツーエンドの体験、例えば本物のブラウザによるログイン操作もテストしたくなります。歴史的に、このようなエンドツーエンドのテストシナリオをコードで実装するのは簡単な仕事ではないのですが、Autify はここに解決策を提供できます。Autify の直感的なレコーダーとシナリオエディタを使うことで、エンドツーエンドのテストシナリオを5分で作ることができ、Autify がCSS class の変更の様な大概のUI の変更を解決し学習してくれるので、シナリオのメンテナンスに悩む必要もありません。これによって、Autify は本番環境で記録した同じエンドツーエンドシナリオが提案されたコードの変更でも通るかを確認でき、レビューする人により安心を与えてくれます。
どうやればコードレビュープロセス中にAutify を実行できますか?
Autify がテストシナリオを実行するために、クラウドにあるテスト実行エンジンからアクセス可能なエンドポイント、つまりURL を必要とします。そのため、例えばGitHub で言えばPull request 毎に一時的なエンドポイントをセットアップして、Autify に記録時に使ったURL、例えば本番のURL を作成した一時的なURL に置き換える様に指示する必要があります。
この様な一時的なエンドポイントをどうやってセットアップするかは、皆さんの基盤に依存します。例えば、Vercel の様ないくつかのデプロイプロバイダーはプレビュー機能を持っていて、何もセットアップしなくてもpull request 毎に自動的にプレビューエンドポイントが作られます。もしくは、Infrastructure as a Code を利用してご自身のデプロイワークフローを設定してpull request のための一時的な環境を立ち上げることもできます。
まとめると、タスクの依存を制御するためのワークフローエンジンと、変更後のコードで動いているアプリケーションのための一時的なエンドポイントを生成する機構を持っている必要があります。以下の表が理解の助けになると思います:
何が必要か | なぜ必要なのか? | 例 |
---|---|---|
ワークフローエンジン | 一時的なエンドポイントをセットアップするジョブを開始するため | GitHub Actions, GitHub App, CircleCI, 等 |
(デプロイ)基盤 | 一時的なエンドポイントをセットアップし動かすため | Vercel, Netlify, Amazon EC2, 等 |
なぜなら、データベース、マイクロサービス、Auth0 やStripe などのサードパーティ連携、といった全ての他のリソースについても注意深く考える必要があるからです。いくつかのものは隔離されたリソースを作れるでしょうが、そうできないものもあります。
ただ、もしこういったワークフローを既にお持ちであれば、その一時的なエンドポイントに対してAutify のテストシナリオを実行するように設定することは簡単にできます。要約すると、以下の様なステップになります:
- コードレビューが作成/更新された時に、その一時的なエンドポイントをCI/CD ソリューションから取得
- Autify のテストをその一時的なエンドポイントに実行
- コードレビューにフィードバック
以下の例では、GitHub Actions とVercel を使ってこの仕組みを実装してみます。
セットアップ例: GitHub とVercel
この例では、GitHub をソースコードレポジトリ、Vercel を一時的なデプロイ環境として利用していきますが、もし違うソリューションをご利用中でも何かしらのアイデアを得られると思います。
Vercel のプレビューURL が一時的なエンドポイント
GitHub レポジトリをVercel と接続すると、Vercel はどのpull request に対してもプレビューデプロイを実行し、ユニークなプレビューURL を何もしなくても作成してくれます。これが上で説明した一時的なエンドポイントの良い例で、Vercel bot はそのプレビューURL をGit Hub issue (pull request) のコメント経由で教えてくれます。詳しくはVercel のドキュメントをご覧下さい。
GitHub Actions をワークフローエンジンとして利用
GitHub Actions はコードプッシュといった様々なGitHub 上のイベントによって起動されるワークフローで、事前に定義したジョブをランナー上で実行してくれます。GitHub issue にコメントが作成/編集などされた時のイベントというものがあるので、GitHub Actions を使うとVercel bot がpull request にコメントを書き込む度に(例えばプレビューデプロイが終わった時)、Autify のテストを開始して結果が見れるURL をコメントとして同じpull request にフィードバックするといった、任意のジョブを実行することができます。
どうやればpull request とGitHub Actions の連携をセットアップできますか?
Vercel のプレビューURL は何もしなくても生成されるので、上の方で注意書きされている一時的なエンドポイントのセットアップについて心配する必要がありません。上記のステップ1-3 を実装するだけで良いです。こちらがVercel にデプロイしているレポジトリにおけるGitHub Actions のセットアップ例です。
以下の様なファイルをレポジトリの .github/workflows/issue_comment.yml
に配置します:
これはコードレビュープロセスとの連携のアイデアをお見せするための、あくまでも例になります。
on:
issue_comment:
types: [created, edited]
jobs:
vercel_commented:
runs-on: ubuntu-latest
if: ${{ github.event.issue.pull_request && github.event.comment.user.login == 'vercel[bot]' }}
steps:
- name: Get preview URL
id: get-url
run: |
body=$(cat <<EOS
${{ github.event.comment.body }}
EOS
)
url=$(echo -e "$body" | grep -Eo 'https://[^\/]+\.vercel\.app') || true
echo ::set-output name=result::"$url"
- name: Run test on Autify NoCode Web
id: run
if: ${{ startsWith(steps.get-url.outputs.result, 'http') }}
uses: autifyhq/actions-web-test-run@v2
with:
access-token: ${{ secrets.AUTIFY_WEB_ACCESS_TOKEN }}
autify-test-url: https://app.autify.com/projects/00/scenarios/000
url-replacements: YOUR_RECORDED_VERCEL_URL=${{ steps.get-url.outputs.result }}
continue-on-error: true
- name: Comment Autify test result URL on the pull request
if: ${{ steps.run.conclusion == 'success' }}
uses: marocchino/sticky-pull-request-comment@v2
with:
number: ${{ github.event.issue.number }}
message: |
Autify test was started. Check ${{ steps.run.outputs.result-url }}
```
${{ steps.run.outputs.log }}
```
- name: Comment failed to start Autify test on the pull request
if: ${{ steps.run.conclusion == 'failure' }}
uses: marocchino/sticky-pull-request-comment@v2
with:
number: ${{ github.event.issue.number }}
message: |
Autify test was failed to start.
```
${{ steps.run.outputs.log }}
```
"Run test on Autify NoCode Web" 内のYOUR_RECORDED_VERCEL_URL
は、Autify で対象のテストシナリオを記録した時に使ったhttps://***.vercel.app
の様なご自身のVercel アプリケーションURL に置き換える必要があります。このurl-replacements
というオプションはAutify にテストシナリオ実行時に対象のURL 置換を行う様に指示するものです。
もしこのGitHub Actions 連携の様なCI/CD 連携についてもっと知りたければ、CI/CD with Autify をご覧下さい。
何かpull request を作成すると、Vercel bot は以下の様なコメントをプレビューデプロイが終わった時に書き込みます:
すると、上で作成しておいたGitHub Actions ワークフローが起動され、指定したAutify テストシナリオを開始してAutify テストシナリオ結果URL とログを以下の様にコメントしてくれます:
これで、レビューする人(ともちろんリクエストした人)はそのリンクをクリックするだけで簡単にテスト結果を確認できます!
シナリオの長さにもよりますが、Autify のテスト実行が1時間以上かかる様な場合もあります。もしテスト結果を待って成功したかどうかをコメントやGitHub Checks でフィードバックしようとすると、"Run test on Autify NoCode Web" ステップをもっと長く実行し続ける必要があり、もしレポジトリがプライベートならGitHub Actions がホストするランナーの実行時間を1時間消費してしまいます。言い換えると、ずっとお金が掛かってしまうかも知れません。もしこういたことをやりたい時には、コストに十分にご注意下さい。
まとめ
このドキュメントではコードレビュープロセスとAutify の連携をする利点と概念について解説し、GitHub Actions を使ってVercel のプレビューURL に対してAutify テストを実行する例をお見せしました。これらが、ご自身でコードレビュープロセスとAutify の連携を実装する際の手助けになれば幸いです。