その他の管理者のベストプラクティス
このセクションでは、ラボのメンテナンス操作、監視、アップグレード、およびパッケージ化サービスのベストプラクティスについて概説します。
モバイルラボ検査
セットアップの性質上、モバイルラボの物理検査を定期的に実行する必要があります。検査の目的は、現在の設定を確認し、システムに影響を与える可能性のある損傷がないか確認することです。
以下を検査する必要があります。
-
すべてのデバイスがWi-Fiに接続されていることを確認する
-
各物理デバイスでバッテリーが膨張していないか確認する (リチウムイオンバッテリーが過熱、過充電、または単に古くなった場合、バッテリーの内部セルから可燃性の電解質混合物が放出され、バッテリーが膨張する可能性があります。)
-
すべてのデバイスが充電されていること、およびバッテリー残量が100%であることを確認する。
-
デバイスの明るさが最小に設定されていることを確認する。
-
デバイスがロックされていないことを確認する。
データベースのメンテナンス
PostgreSQLは、他のデータベースソフトウェアと同様に、最適なパフォーマンスを達成するために特定のタスクを定期的に実行する必要があります。
次の手順が最も一般的です。
-
定期的なスケジュールでのデータのバックアップコピーの作成
-
データベースの定期的な「バキューム」
データベースのメンテナンスの詳細については、PostgreSQLのドキュメントを参照してください。
ログとTMPのクリーンアップ
ログは古いデータを削除しますが、条件によっては特定のログファイルが大幅に増大することがあります。たとえば、アプリケーションパッケージャーログ、ラボのaudit.log、データベース監査ログなどです。
これらのログのサイズを監視し、定期的にクリーンアップを実行する必要があります。
監視
他の運用環境システムと同様に、デプロイメントにはパフォーマンスと可用性を監視する必要があります。
次の種類の監視が必要です。
項目 | 詳細 |
---|---|
ハードウェア |
メモリ CPU ディスク領域 ネットワーク消費量 |
サービス | プロセス/サービスの可用性 |
ネットワークの可用性 | URL監視 |
デバイス | デバイスの可用性 |
コネクター | コネクターの可用性 |
データベースのパフォーマンス | PostgreSQL: https://bucardo.org/check_postgres/ |
ログファイル |
ログファイルの例外とエラーの監視 |
効果的なモニタリングのためのさまざまな方法が提供されています。
-
REST APIリファレンス: ラボに関連するアクションはすべてREST APIを使用して実行できます。REST API呼び出しは、監視目的でスクリプト内で使用できます。
-
組み込み統計レポートエンジン。サーバーはコネクターから統計を集約し、Prometheusレポーターを使用して公開します。
-
ラボのログファイルは /logフォルダーに保存されます。
アップグレードプロセス
システムには極めて重要なビジネス価値があるため、アップグレードプロセスは組織的かつ堅牢な方法で展開する必要があります。
必ず次のベストプラクティスに従ってください。
-
決してその場でアップグレードしない。現在のシステムと、並行して実行する別の新しいインストールの2つの環境を使用します。サーバーの移行の手順に従ってください。
-
バックアップ。アップグレード前だけでなく、定期的にバックアップしてください。トランザクションデータはデータベースに保存されませんが、それでもデータを安全に保つことをお勧めします。
-
互換性チェック。エンドユーザーが新しいシステムでテストとアクションを再実行し、運用開始前に新しいバージョンとのアセットの互換性を確保できるようにします。
-
ベンダーが提供するツールを活用する。システムを手動で変更しないでください。たとえば、モバイルアプリケーションには移行ツールを使用します。
-
移行と実行を計画する。アップグレード前、アップグレード中、アップグレード後のアクションを計画します。
詳細については、Windowsインストールを参照してください。
パッケージングサービス
パッケージ化されたモバイルアプリとパッケージ化されていないモバイルアプリの両方がサポートされています。パッケージ化は、OpenText Functional Testing Labインターセプトライブラリをアプリケーションバンドルに挿入し、適切な資格情報でアプリに再署名するインストルメンテーション方法です。パッケージアプリを使用する利点は、記録/再生のためのオブジェクト認識が向上するだけでなく、追加のセンサーシミュレーション (写真や指紋など) が提供されることです。
ラボにアプリをアップロードすると、サーバーは自動的にアプリのパッケージ化を試みます。これにより、テストの実行時に、パッケージアプリまたは元のバージョンのいずれかを選択するオプションが提供されます。アプリの自動パッケージ化と署名の機能を有効にするには、管理者はパッケージ化と署名のサービスを設定する必要があります。
パッケージ化サービスは、現在のアプリがインストルメンテーションライブラリの最新バージョンでアップグレードされるときのアップグレードプロセス中にも使用されます。
アプリをパッケージ化するための手動手順など、パッケージ化サービスに関する一般的な情報については、アプリのパッケージングおよび署名サービスを参照してください。
Androidパッケージ
デフォルトでは、Androidパッケージングサービスはラボサーバーとともにインストールされます。特別な構成は必要ありませんが、パッケージングサービスはサーバー上で実行されるJavaプロセスであるため、サーバーマシンの全体的なパフォーマンスに影響を与える可能性があります。
iOSパッケージ
iOSアプリのパッケージ化手順は少し異なります。
iOSアプリケーションとエージェントは、組み込みパッケージサービスまたはリモートパッケージングサービスを使用して署名/パッケージ化できます。個々のApple Developerアカウントでサポートされるデバイスタイプの最大数は、iPhone 100台とiPad 100台です。さらに多くのデバイスに署名する必要がある場合は、追加のApple Developerアカウントが必要です。パッケージ化に複数のApple Developerアカウントを使用するには、リモートパッケージングサービスが必要です。詳細については、iOS署名サービスを参照してください。