このセクションでは、Parasoft Virtualize、Parasoft Data Repository、および Parasoft Continuous Testing Platform (CTP) の運用レベルのデプロイメントに関する推奨事項を説明します。
デプロイメントには以下が含まれると仮定します。
デプロイメントには 2 種類の方法があります。動的インフラストラクチャ (Docker イメージまたはAzure VM) または物理的な静的インフラストラクチャです。
動的インフラストラクチャは、動的な使い捨てのテスト環境を実現することを目的とします。つまり、基準となるテンプレートからただちにテスト環境をセットアップし、環境を使用して変更した後、環境を破棄することができます。複数のチームやテスト フェーズでテスト環境やリソースを共有する必要はありません。いつでも必要なときに、まさに必要な環境をただちにセットアップし、使い終わったら破棄します。動的なインフラストラクチャは、高い水準の自動化を可能にする高度な柔軟性を提供します。さらに、規模を拡大する必要がある場合 (たとえばパフォーマンス テストなど) も、必要に応じて実現できます。
物理的な静的インフラストラクチャでは、恒久的な (専用の) サーバーがあります。この方法は、長期間のスケーリングが予想され、多用される前にハードウェアが指定される場合に役立ちます。この方法は、高い可用性とフォールト トレランスの要求に対応するために選択されます。このような要件があり、ロード バランサーの背後に Parasoft Virtualize サーバーのクラスターを構成する計画である場合、「ロード バランサーの背後での Virtualize サーバー クラスタのセットアップ」も確認してください。
動的インフラストラクチャは、Docker、Microsoft Azure、または Amazon Web Services (AWS) を使用します。
Docker の場合、以下を推奨します。
Azure の場合、以下を推奨します。
AWS では、以下を推奨します。
以下の図は、3 個の Virtualize サーバーと CTP のデプロイメントのために推奨するアーキテクチャを示します。ここでは 3 台の Virtualize サーバーが表示されていますが、必要な数だけ追加できることに注意してください。
デスクトップ ユーザーは、ローカルの Virtualize デスクトップを使用してアセットを開発し、Virtualize Staging Server に接続してステージング環境でアセットをテストする必要があります。ステージング サーバー上のイベントを監視してアセットをデバッグできます。仮想アセットの準備ができたら、ソース管理 (SCM) システムに変更をチェックインできます。
本番サーバーまたはパフォーマンスサーバー上のアセットは、SCM を通じて更新する必要があります。これにより、これらのサーバー上で実行されているアセットの動作とパフォーマンスが仮想アセットの開発によって影響を受けないようにし、本番サーバーとパフォーマンス サーバを安定した状態に保つことができます。パフォーマンス サーバーは、「Virtualize サーバーのパフォーマンス チューニング」で概説されている原則に基づいて構成する必要があります。SCM からのアセットの更新は、現在のニーズに最適なものに基づいて、スケジュールまたはオンデマンドで実行できます。たとえば、Kubernetes でのデプロイでは initContainer を使用して SCM からプルする一方、物理サーバーを使用するデプロイではオートメーション サーバーからオンデマンドで実行されるジョブがあるかもしれません。
ステージングと本番の両方に 1 つのサーバーを使用することには、固有のリスクが伴います。可能ではありますが、いくつかの理由から推奨できません。たとえば、テストがサーバーを使用している間にデスクトップ ユーザーがアセットを再デプロイして障害を引き起こしたり、負荷テスト中にアセットを監視してスループットの低下を引き起こしたりすることがあります。ステージング環境と本番環境を分離しないと、デスクトップ ユーザーによるアセットの開発が自動テストや負荷テストに悪影響を及ぼす可能性があります。
Virtualize サーバーと Data Repository サーバー間のネットワーク待ち時間を、可能な限り最小限に抑えることを推奨します。プロセス間のネットワーク待ち時間は、負荷がかかった状態での Virtualize サーバーのパフォーマンスに悪影響を及ぼす可能性があります。ネットワーク待ち時間を抑えるための最も一般的な方法は、同じマシン、または可能な限り同じ場所にある 2 台のマシン (たとえば、同じデータ センター リージョン) にインストールすることです。Data Repository サーバーは大量のメモリを消費するので、Virtualize サーバーと同じマシンにインストールする場合は、32 GB 以上の RAM を搭載したマシンを推奨します。
Virtualize、Data Repository、および CTP サーバーマシンについて、以下のハードウェアを推奨します。
以下の理由により、Parasoft のデプロイメントには、Windows よりも Linux を推奨します。
CTP は Oracle、HyperSQL、MySQL をサポートしていますが、MySQL ではなく Oracle または HyperSQL を使用することを強く推奨します。推奨する順序は次のとおりです。
Oracle >= HyperSQL > MySQL |
Oracle および HSQLDB は同等ですが、MySQL ではトラブルシューティングが困難です。CTP データベースをクラスタリングする予定がなく、十分なスペースがある場合は、HyperSQL を推奨します。
Microsoft Azure や Amazon AWS などのクラウド サービス プロバイダーの提供するクラウド上に VM をデプロイする場合、VM をシャットダウンし、再起動するたびにマシン ID が変わる可能性があります。Prasoft 製品を起動するとき、次のフラグを使用すると、クラウド プラットフォームで VM を再起動したときもマシン ID が変わらないようにできます。
-Dparasoft.cloudvm=true |