2020.12.03

Autify で作成した E2E テストを Gitlab の CI/CD パイプラインで動かしてみた

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

はじめに

前回の記事では、Azure DevOps の CI/CD パイプラインに、Autify で作成した E2E 自動テストの実行と、結果の成否判定を行う PowerShell スクリプトを組み込み、ビルドから単体テスト、デプロイから E2E テストまでの一連の流れの自動化しました。今回は Gitlab の CI/CD パイプラインを使用した方法をご紹介したいと思います。

検証

前回と同じアプリと Autify で作成したテストプランを使用します。

テスト対象のアプリケーション

アカウントロック機能があるフォーム認証ページ
5 回認証失敗するとアカウントロックがかかり、30 分間そのアカウントでログインできなくなる

実行するテストプラン

登録済みのアカウントで、パスワード認証を 5 回失敗したときに、アカウントロックがかかることを確認する。

テストプランのステップ一覧

アカウントロック時の表示

シェルスクリプト

今回は以下の二つを実行するシェルスクリプトを作成しました。方針としては、前回作成した Powershell スクリプトと同じです。

Autify で作成した任意のテストプランを実行する
テストの成否を判定する

Autify API

シェルスクリプトから Autify を使用するために、Autify API（https://autifyhq.github.io/autify-api/#/）を使用しています。テストプランの実行・結果の確認のために必要な情報は以下の 4 つです。

API を使用するためのパーソナルアクセストークン
テストプランを作成しているプロジェクト ID
使用するテストプラン ID
実行されたテストごとの固有 ID

必要な情報の取得方法については、前回の記事をご覧下さい。

作成したシェルスクリプトが以下になります。作成にあたって、こちらのページを参考にしました。

# ${AUTIFY_PERSONAL_ACCESS_TOKEN}: パーソナルアクセストークン
# ${AUTIFY_PROJECT_ID}:            プロジェクト ID
# ${AUTIFY_TEST_PLAN_ID}:          テストプラン ID

# jq のインストール
apt-get update && apt-get -y install jq

# テストのスケジュール
response=$(curl -XPOST -H  "Authorization: Bearer ${AUTIFY_PERSONAL_ACCESS_TOKEN}" \
https://app.autify.com/api/v1/schedules/${AUTIFY_TEST_PLAN_ID})

# レスポンスから、実行されたテストの固有 ID を取得
test_plan_result_id=$(echo ${response} | jq -r .data.id) 

# テストの実行状況を取得
result=$(curl -X GET "https://app.autify.com/api/v1/projects/${AUTIFY_PROJECT_ID}/results/${test_plan_result_id}" \
-H "accept: application/json" -H "Authorization: Bearer ${AUTIFY_PERSONAL_ACCESS_TOKEN}")
status=$(echo ${result} | jq -r '.status')

# ステータスを表示
echo "${status}"

# ステータスが 'passed' か 'failed' になるまで、20秒毎にポーリングを続ける
while [ "${status}" != "passed" ]
  do
    if [ "${status}" = "failed" ]; then
      echo "${status}"
      exit 2
    else
      sleep 20
      result=$(curl -X GET "https://app.autify.com/api/v1/projects/${AUTIFY_PROJECT_ID}/results/${test_plan_result_id}" \
      -H "accept: application/json" -H "Authorization: Bearer ${AUTIFY_PERSONAL_ACCESS_TOKEN}")
      status=$(echo ${result} | jq -r '.status')
      echo "${status}"
    fi
  done

前回と同様に ${AUTIFY_PERSONAL_ACCESS_TOKEN} などの値は、以下のように Gitlab の管理画面から環境変数としてを追加しており、アクセス権のないユーザーは値を見ることができないように設定しています。

以下はスクリプト実行時のログです。

CI/CD パイプライン

上記のシェルスクリプトを組み込んだ CI/CD パイプラインを作成しました。今回は CI（継続的インテグレーション）部分と、CD（継続的デプロイ）部分は分けておらず、アプリのデプロイ時に、データベースのテストユーザーを毎回リセットすることで、連続した E2Eテストに対応するように設定しています。

Azure App Service へのデプロイ

今回作成した認証フォームアプリの運用には、Azure App Service を使用しています。前回の記事では Azure DevOps を使用していたため、比較的容易に連携することができたのですが、Gitlab の CI/CD からデプロイするためには、リソースへの認証設定の必要があります。

そこで今回は、Azure のリソースに接続するための Azure Active Directory (Azure AD) のアプリケーションとサービスプリンシパルを作成しました。詳細についてはこちらをご参照いただきたいのですが、サービスプリンシパルを使用することで、どのリソースに、どのレベルでアクセスするか制御することができるので、ユーザーID でログインするよりもセキュアな方法であり、推奨されています。

Azure CLI を使用して、リソースにアクセスするために必要な情報は以下の5つです。

アプリケーション（クライアント）ID
ディレクトリ（テナント）ID
シークレット
Azure App Service のリソース名
リソースグループ名

今回のデモ用に app-autify-demo という名前のアプリケーションを作成して Azure AD に登録しました。アプリケーション（クライアント）ID とディレクトリ（テナント）ID は、アプリケーションの「概要」に表示されています。

シークレットは「証明書とシークレット」で作成して、使用してください。

Azure App Service のリソース名とリソースグループ名は、App Service の画面から取得してください。

シェルスクリプト

以上の情報をもとに、ビルド成果物を Azure App Service にデプロイするためのスクリプトが以下になります。

# ${AZ_SERVICE_PRINCIPAL_APPLICATION_ID}: アプリケーション（クライアント）ID
# ${AZ_SERVICE_PRINCIPAL_DIRECTORY_ID}:   ディレクトリ（テナント）ID
# ${AZ_SERVICE_PRINCIPAL_SECRET}:         シークレット
# ${AZ_APP_NAME}:                         Azure App Service のリソース名
# ${AZ_APP_RESOURCE_GROUP}:               リソースグループ名

apt-get update && apt-get -y install zip
curl -sL https://aka.ms/InstallAzureCLIDeb | bash
az login --service-principal -u ${AZ_SERVICE_PRINCIPAL_APPLICATION_ID} -p ${AZ_SERVICE_PRINCIPAL_SECRET} --tenant ${AZ_SERVICE_PRINCIPAL_DIRECTORY_ID}
dotnet restore ./${AZ_APP_NAME}/${AZ_APP_NAME}.csproj
dotnet publish -c release -o out
cd out && zip -r app.zip .
az webapp deployment source config-zip -n ${AZ_APP_NAME} -g ${AZ_APP_RESOURCE_GROUP} --src app.zip

上記で使用している値についても、Gitlab の管理画面から環境変数として設定しています。

上記を盛り込んだ gitlab-ci.yml を作成し、E2E テストまでの一連の流れを自動化することができました。