Autify でCI/CD

Autify はエンドツーエンドテスト（E2Eテスト）を自動化し、人手を介さずに安定して実行する機能を提供しています。それによって、CI/CD パイプラインをより安全にすることもできます。このドキュメントでは「CI/CD とは何か」から、どの様にAutify がCI/CD プロセスを改善できるのかを解説していきます。

CI/CD とは？

CI (Continuous Integration) とCD (Continous Delivery/Deployment) は現代のソフトウェアリリースサイクルの中で人気がでてきています。CI/CD の定義はいくつかありますが、CI/CD の重要な概念は「継続的(Continuous)」ということです。CI/CD がなければ、ソフトウェアリリースプロセスは多くの手動ステップを必要とするため流れる様に動作せず、「継続的」にはなりません。CI/CD がないと遭遇する問題としては例えば、コードをマージした後にDocker イメージやJAR ファイルといったアーティファクト（成果物）を手動でビルドする必要があったり、デプロイ手順に従ってステージングやプロダクションサーバに手でデプロイする必要があったりします。こうした場合には、人の介入と人による運用、例えばシェルスクリプトを実行したり、手動でテストしたりする必要があります。これらのプロセスを自動化することで、コードをマージしてから本番環境へリリースするまでの時間を削減することができ、顧客に対して機能の価値をより早く届けることができます。これが、人々がリリースサイクルを速めるためにCI/CD に関心を持つ理由です。

CI/CD を十分に活用できない理由は？

手動のプロセスは広く使われています。なぜでしょう？それは、人々は人手によるテストやQAに頼っているからです。たとえ、ビルドやデプロイのプロセスを自動化できても、リリースの段階毎に全体的にテストする手段を持っていないことが多いです。そのため、ビルドとデプロイの間にはギャップがあって、CI/CD プロセスを完全に「継続的」なものにするのを阻んでいます。それは、十分なテストやQA なしにデプロイするのは安全ではないと考えられるからです。

本番リリース前に十分な確信を得るために、典型的にはステージング環境と呼ばれる固定で本番環境と類似した環境を持っていることが多いです。本番環境との唯一の違いはステージングにはお客さんはいないということです。コードマージ後にアーティファクトがビルドされたら、そのアーティファクトをステージング環境に自動または手動でデプロイします。そして、変更が問題なく動作するかを本番とほぼ同じ環境で検証することで、本番環境にもデプロイするかを決定します。人/組織によっては、同じテストシナリオを本番環境へのデプロイ後にも実行して、もし本番で何か悪い事態が起こっていたら前のリビジョンにロールバックしたりしています。

ここで出てきたテストやQA プロセスは、今日では手動で行われることが多く、そのためCI/CD による自動化をしても十分に継続的にできないと感じてしまいます。

Autify はまさにこの課題に対して安定した解決策を提供できます。テストシナリオを作成して、ウェブサイトの機能（例: ログイン、リソース作成、ジョブの実行）をリアルなブラウザからエンドツーエンドで実行し、たくさんのアサーション（例: テキスト、有効/無効）をすることができます。これは、QA プロセスの多くの部分をカバーでき、人的リソースを使うことなく繰り返し可能な方法でステージングや本番環境へのデプロイを自動的に検証することが可能になります。

Autify でCI/CD と連携するとはどういうこと？

Autify の主なCI/CD 連携箇所は、ステージングや本番環境といった固定環境へのデプロイ後です。それにより、デプロイ直後にエンドツーエンドのユーザ体験を検証でき、新しいデプロイがリグレッション問題を抱えていた場合、次のステップに進む前にすぐに自動で気づくことができます。

例えば、Autify による検証ステップをお手持ちのCI/CD パイプライン内のステージングデプロイ直後に挿入することが考えられます。この場合、コードのマージはおそらくステージングに自動的にデプロイされていて、その後すぐにAutify が、ステージングのエンドポイントに対してレコーディングしたテストシナリオを実行し、新しいデプロイがそのテストシナリオを壊していないことを確認します。また、本番環境へのデプロイステップをこのステージングへのAutify による検証ステップのすぐ後に繋げることもできて、ステージングでAutify のテストが通ったら自動的に本番環境へのデプロイを開始させられます。本番リリースの前には追加の手動検証が必要だったとしても、Autify が基礎的な確認の大部分をカバーできるので、手動検証の量を劇的に減らすこともできます。

さらに、Autify による検証ステップを本番環境へのデプロイ後に追加することもできて、それによって本番環境がリグレッションテストを通過していることを確認できます。これはさらに進んだ解決策 - Autify による検証を本番環境で毎時実行する - にも拡張できます。合成テストにも似た、このスケジュールされたエンドツーエンドテストによって、本番環境を先回りして検証し、お客さんが気づく前に何かしらの問題を発見することができます。これらの問題は、依存先の問題だったり内部的なパフォーマンス問題だったりしますが、いずれもデプロイが無くても起こり得ます。そのため、プロダクション環境を定期的に先回りして検証するのは、よい習慣です。

もう一つの進んだCI/CD 連携は、pull request 毎のプレビューエンドポイントの様な、一時的な環境（短い期間しか存在しない環境）に対してAutify を実行することで、同じ検証をコードマージ前に行うこともできます。詳しくはこちらのドキュメントをご覧下さい。

Autify とCI/CD をどうやって連携する？

おそらく皆様は、既に何らかのCI/CD ソリューションを使って、リリースパイプラインを自動化していることと思います。Autify はいくつかのプラットフォーム、例えばGitHub Actions、CircleCI、Jenkins、GitLab CI/CD などについて公式の連携ドキュメントを提供しています。もしお使いのソリューションがその中に無くても、Autify Command Line Interface (CLI) を使うことでそれと簡単に連携させることもできます。いずれにせよ、数行の設定を足す（もしくはプラグインを設定する）だけで、Autify のテストシナリオやテストプランを自動的に実行して、必要であれば結果が出るまで待つことができます。

以下のリストから公式のCI/CD ドキュメントをご覧下さい！

• GitHub Actions
• CircleCI
• Jenkins
• GitLab CI/CD
• Azure Pipelines
• AWS CodeBuild