アプリケーション用の一連のSelenium UIテストがあります。 QA環境のテストマシンにアプリケーションを配備しています。継続的な統合と展開にはTFS 2015を使用しています。
Mavenを使用してSeleniumテストスクリプトをビルドし、ビルド定義でJARファイルを作成しています。次に、このJARファイルをQA環境にコピーし、そこからテストを実行します。または、URLをQAアプリケーションにポイントするだけのビルドサーバーからテストを実行する必要があります。
通常、ビルドマシンはビルド、コンパイル+ユニットテスト用です。外部依存関係があってはなりません。
通常、UIの自動化は、パッケージがビルドされて環境にデプロイされた後のデプロイメント後のステップとして発生します。したがって、コードパッケージが展開された後にSeleniumスクリプトを実行する必要があります。
ビルドサーバーでそれらを実行することもできますが、ビルドサーバーは環境に似ている必要があります。同じマシンでビルドとデプロイを行うと問題が発生する場合があるため、ベストプラクティスはそれらを分離することです。
私は、アプリケーションを、実稼働と同様の別のテスト環境にデプロイします(Dockerまたは他の同様のテクノロジーを見てください)。すべてが問題なく完了したら、Guiテストを実行し、QAサーバーにデプロイして実際のテスターが確認できるようにします。
私たちの製品について数週間前に同じ質問がありました。
従来、ビルドマシンは、多数のツールがインストールされているため、非常に特殊な獣です。ツールを追加すると、競合やメンテナンスの問題が発生するため、タスクごとに異なるマシンを使用することをお勧めします。しかし、現在、すべてのビルドマシンはtfsビルドエージェントとDockerを実行しているだけです。ハードウェアには多少の違いがありますが、ビルド時間の違い以外は影響はありません。各環境(たとえば、pythonビルド、asp.netコアビルド、またはテスト)には、他のすべての環境の環境から完全に分離された独自のコンテナがあります。「特別な獣」が含まれていますコンテナ内。つまり、テストがターゲットWebサイトに接続できる必要があることを除いて、テストを実行する場所はまったく関係ありません。したがって、ビルドマシンをまったく区別しません。神聖な「BUILD_01_CAn_BUILD_OLD_CRAP」と「TEST_CAN_EXECUTE_Selenium_TESTS」マシンはなくなり、ペットであるのをやめ、本来あるべき状態の牛になります。( https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets )
私たちのテストもDockerコンテナーです(コンテナー内のpytest-Seleniumおよび別のコンテナーとしてのSelenium/standalone-chrome)。ターゲットURLを環境パラメーターとして挿入し、それですべてです。 pytest-Seleniumコンテナー内にはいくつかの構成がありますが、多くはありません。
私たちは同じ問題を解決しなければなりませんでした。私たちはかなりうまく機能する緩やかな解決策を見つけました。
マスターへのすべてのコードは、プルリクエストを経由する必要があります。プルリクエストを完了するには、必要なレビュアーが作成して承認する必要があります。ブランチとマスターから一時的なマージコミットを構築するようにシステムを設定することが重要です(PRが完了した場合のコミットと同様)。
ビルドが完了すると、ビルドのアーティファクトを含むリリースが作成されます。このリリースは開発サーバーにデプロイされます。各デプロイは、この特定のバージョンのwebappに到達できるポート番号を取得します。
次のような環境があるとします。 DEV、RUNTESTS、UAT、PROD。 devにデプロイした後、この特定のリリースに対してRUNTESTS envが実行されます。すべてが良ければ、必要なレビュー担当者がPRに承認を与え、それを完了することができます。
これにより、壊れたコードをマスターに配置することが非常に困難になります。別の利点は、デモ目的で使用できる特定のリリースのポート番号を取得できることです(PO、利害関係者、アナリスト...)
毎朝、マスターからのビルドがスケジュールされ、DEVとRUNTESTSにデプロイされます。必要に応じて、UATとPRODにビルドすることを選択できます。コードがマスターに到達する前に一時的なリリースがあるため、コミットごとにビルドをトリガーする必要はありません。