パイプライン実行中は、多数の指標が取得され、ビジネスオーナーによって定義された主要業績評価指標(KPI)または Adobe Managed Services で設定された標準と比較されます。
これらは、この節で定義する 3 層ゲートシステムを使用して報告されます。
パイプラインには次の 3 つのゲートがあります。
これらの各ゲートで特定された問題には、3 段階の構造があります。
コード品質専用パイプラインでは、コード品質テストステップがパイプラインの最終ステップであるため、コード品質テストゲートでの重要なエラーは無効にはできません。
この手順では、アプリケーションコードの品質を評価します。これは、コード品質のみのパイプラインの中核となる目的で、非実稼働および実稼働のすべてのパイプラインのビルド手順の直後に実行されます。様々なタイプのパイプラインの詳細については、CI/CD パイプラインの設定を参照してください。
コード品質テストでは、ソースコードが一定の品質基準を満たしていることを確認するためにスキャンされます。現在、これは、SonarQuebe、OakPALを使用したコンテンツパッケージレベルの調査、およびディスパッチャー最適化ツールを使用したディスパッチャー検証の組み合わせによって実装されます。 汎用の Java ルールと AEM 固有のルールを組み合わせた 100 以上のルールがあります。AEM 固有のルールの一部は、AEM エンジニアリングのベストプラクティスに基づいて作成され、カスタムコード品質ルールと呼ばれます。
ここからルールの完全なリストをダウンロードできます。
この手順の結果は、評価として提供されます。次の表に、様々なテスト条件の評価の概要を示します。
名前 | 定義 | カテゴリ | 不合格のしきい値 |
---|---|---|---|
セキュリティ評価 | A = 脆弱性なし B = 軽度の脆弱性が 1 つ以上 C = 重要な脆弱性が 1 つ以上 C = の重大な脆弱性が 1 つ以上 E = 致命的な脆弱性が 1 つ以上 |
重大 | < B |
信頼性評価 | A = バグなし B = 軽度のバグが 1 つ以上 C = 重要なバグが 1 つ以上 D = 重大なバグが 1 つ以上 E = 致命的なバグが 1 つ以上 |
重要 | < C |
保守性評価 | コードスメルに対する未処理の修正コスト:
|
重要 | < A |
カバレッジ | ユニットテストのラインカバレッジと条件カバレッジを次の式で計算した結果:Coverage = (CT + CF + LC)/(2*B + EL) CT = ユニットテスト実行中に 1 回以上「真」と評価された条件の数 CF = ユニットテスト実行中に 1 回以上「偽」と評価された条件の数 LC = 実行された行の数 = lines_to_cover - uncovered_lines B = 条件の合計数 EL = 実効行の合計数(lines_to_cover) |
重要 | < 50% |
スキップした単体テスト | スキップした単体テストの数。 | 情報 | > 1 |
未解決の問題 | 問題の全体的なタイプ - 脆弱性、バグ、コードスメル | 情報 | > 0 |
重複行 | 重複しているブロックに含まれている行の数。 コードブロックが重複していると見なされるための条件:
重複を検出する際は、インデントの違いと文字列リテラルの違いは無視されます。 |
情報 | > 1% |
Cloud Service の互換性 | 識別された Cloud Service の互換性に関する問題の数です。 | 情報 | > 0 |
詳しくは、指標の定義を参照してください。
Cloud Manager で実行されるカスタムコード品質ルールについて詳しくは、カスタムコード品質ルールを参照してください。
品質スキャンプロセスは完璧ではなく、実際には問題がないにもかかわらず問題として誤って特定することもあります。これは「偽陽性」と呼ばれます。
この場合、ルール ID を注釈属性として指定した標準の Java @SuppressWarnings
注釈を使用して、ソースコードに注釈を付けることができます。例えば、よくある問題の 1 つとして、ハードコードされたパスワードを検出する SonarQube ルールにおいて、ハードコードされたパスワードの識別方法が強引な場合があります。
具体的な例を見てみましょう、次のコードは、一部の外部サービスに接続するコードを含んだ AEM プロジェクトではかなり一般的なものです。
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
この場合、SonarQube は致命的脆弱性を報告します。コードを見直した後、これが脆弱性でないことを確認し、適切なルール ID でこれに注釈を付けることができます。
@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";
一方、コードが実際には次のようになっていた場合は、
@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";
ハードコードされたパスワードを削除するのが正しい解決策です。
@SuppressWarnings
注釈をできるだけ具体的にすることをお勧めします。つまり、問題の原因となっている特定のステートメントまたはブロックにのみ注釈を付けます。ただし、クラスレベルで注釈を付けることもできます。
Cloud Manager では、デプロイメント後に既存の AEM セキュリティヘルスチェックを実行し、UI を通じてそのステータスを報告します。結果は、環境内のすべての AEM インスタンスから集計されます。
これらの同じヘルス・チェックは、Webコンソールまたはオペレーション・ダッシュボードを使用して、いつでも実行できます。
いずれかのインスタンスが特定のヘルスチェックに対して不合格を報告した場合、環境全体がそのヘルスチェックに対して不合格となります。コード品質テストやパフォーマンステストと同様に、これらのヘルスチェックもいくつかのカテゴリにまとめられ、3 層ゲートシステムを使用して報告されます。セキュリティテストの場合にはしきい値がない点だけが異なります。すべてのヘルスチェックでは、単純に合格または不合格のみの結果になります。
現在のチェックは次の表のとおりです。
名前 | ヘルスチェックの実装 | カテゴリ |
---|---|---|
デシリアライゼーションファイアウォール添付 API レディネスが、受け入れ可能な状態である | デシリアライゼーションファイアウォール添付 API レディネス | 重大 |
デシリアライゼーションファイアウォールが機能している | デシリアライゼーションファイアウォール機能 | 重大 |
デシリアライゼーションファイアウォールが読み込まれている | デシリアライゼーションファイアウォール読み込み | 重大 |
AuthorizableNodeName 実装において、認証可能な ID がノード名/パスで公開されていない | 認証可能なノード名生成 | 重大 |
デフォルトのパスワードが変更されている | デフォルトのログインアカウント | 重大 |
Sling のデフォルトの GET サーブレットが DOS 攻撃から保護されている | Sling Get Servlet | 重大 |
Sling Java Script Handler が適切に設定されている | Sling Java Script Handler | 重大 |
Sling JSP Script Handler が適切に設定されている | Sling JSP Script Handler | 重大 |
SSL が正しく設定されている | SSL 設定 | 重大 |
安全でないことが明確なユーザープロファイルポリシーが存在しない | ユーザープロファイルへのデフォルトアクセス | 重大 |
Sling Referrer Filter が CSRF 攻撃を防止するように設定されている | Sling Referrer Filter | 重要 |
Adobe Granite HTML Library Manager が適切に設定されている | CQ HTML Library Manager 設定 | 重要 |
CRXDE サポートバンドルが無効である | CRXDE サポート | 重要 |
Sling DavEx のバンドルおよびサーブレットが無効である | DavEx ヘルスチェック | 重要 |
サンプルコンテンツがインストールされていない | サンプルコンテンツパッケージ | 重要 |
WCM Request Filter と WCM Debug Filter が両方とも無効になっている | WCM フィルター設定 | 重要 |
Sling WebDAV のバンドルおよびサーブレットが適切に設定されている | WebDAV ヘルスチェック | 重要 |
Web サーバーが、クリックジャッキングを防止するように設定されている | Web サーバー設定 | 重要 |
レプリケーションが「管理者」ユーザーを使用していない | レプリケーションとトランスポートユーザー | 情報 |
Cloud Managerは、AEM Sitesプログラムのパフォーマンステストを実行します。 このパフォーマンステストは、実際のユーザーがStage環境上のページにアクセスした場合とトラフィックをシミュレートする場合をシミュレートする仮想コンテナ(ユーザー)を回転させて、~ 30分間実行します。 これらのページは、クローラーを使用して検出されます。
仮想ユーザー
Cloud Managerがスパンアップする仮想ユーザーまたはコンテナの数は、プログラムの作成または編集中に、ビジネスオーナーロールでユーザーが定義したKPI(応答時間とページビュー数/分)によって決まります。 定義されたKPIに基づいて、実際のユーザーをシミュレートする最大10個のコンテナがスパンアップされます。 テスト用に選択したページが分割され、各仮想に割り当てられます。
クローラ
30 分のテスト期間が開始される前に、Cloud Manager は、カスタマーサクセスエンジニアが設定した 1 つ以上のシード URL セットを使用してステージング環境をクロールします。これらの URL から、各ページの HTML を調べ、幅優先方式でリンクが探索されます。このクロール処理は、最大 5000 ページに制限されています。クローラーからのリクエストのタイムアウトは 10 秒に固定されています。
テスト用ページセット
ページは3つのページセットで選択されます。 Cloud Managerは、実稼働環境とステージ全体でAEMインスタンスのアクセスログを使用して、次の3つのグループを決定します。
人気のあるライブページ:このオプションは、実際の顧客がアクセスした最頻訪問ページをテストするために選択します。Cloud Managerはアクセスログを読み取り、ライブユーザーが最もアクセスしたページの上位25個を特定し、上位Popular Live Pages
のリストを生成します。 次に、Stage内にも存在するこれらの交差部分が、Stage環境上でクロールされます。
その他のライブページ:このオプションは、人気の高いライブページの上位25ページの外にあるページのうち、人気がない可能性があるが、テストに重要なページをテストするために選択します。人気のあるライブページと同様、ライブページはアクセスログから抽出され、ステージにも存在する必要があります。
新規ページ:このオプションは、ステージにのみデプロイ済みで、まだ実稼働環境にはデプロイされていないが、テストする必要がある新しいページをテストする場合に選択します。
選択したページセット間のトラフィックの分布
パイプライン設定(挿入リンク)の「テスト」タブで、1セットから3セットまでを選択できます。 トラフィックの配分は、選択したセットの数によって決まります。つまり、3 つのセットがすべて選択されている場合、合計ページビューの 33% が各セットに送られます。2 つのセットが選択されている場合は、各セットに 50% ずつ送られます。1 つのセットが選択された場合は、トラフィックの 100% がそのセットに送られます。
例えば、人気のあるライブページと新しいページセット(この例では、他のライブページは使用しません)の間に50 ~ 50%の分割があり、新しいページセットには3000ページが含まれているとします。 「1 分あたりのページビュー数」KPI は 200 に設定されます。30 分間のテストの結果は次のようになります。
「頻度の高いライブページ」セットの 25 ページが各 120 回ヒットします - ((200 * 0.5) / 25) * 30 = 120
「新規ページ」セットの 3000 ページが各 1 回ヒットします - ((200 * 0.5) / 3000) * 30 = 1
Cloud Managerは、ステージ公開サーバー上で30分間のテスト期間(デフォルトでは未認証ユーザー)にページをリクエストし、(仮想)ユーザー生成指標(応答時間、エラー率、1分あたりの表示数など)を測定することで、AEM Sitesプログラムのパフォーマンステストを実行します。 各ページに加え、すべてのインスタンスに関する様々なシステムレベルの指標(CPU、メモリ、ネットワークデータ)。
次の表に、3層ゲーティングシステムを使用した場合のパフォーマンステスト指標の概要を示します。
3 層ゲートシステムを使用したパフォーマンステストマトリックスの概要を次の表に示します。
指標 | カテゴリ | 不合格のしきい値 |
---|---|---|
ページリクエストエラー率 % | 重大 | >= 2% |
CPU 使用率 | 重大 | >= 80% |
ディスク I/O 待機時間 | 重大 | >= 50% |
第 95 百分位応答時間 | 重要 | >= プログラムレベルの KPI |
ピーク応答時間 | 重要 | >= 18 秒 |
1 分あたりのページビュー数 | 重要 | < プログラムレベルの KPI |
ディスク帯域幅使用量 | 重要 | >= 90% |
ネットワーク帯域幅使用量 | 重要 | >= 90% |
1 分あたりのリクエスト数 | 情報 | >= 6000 |
サイトとアセットのパフォーマンステストに基本的な認証を使用する方法の詳細については、次の認証済みのパフォーマンステストの節を参照してください。
各インスタンスは、テスト期間中、発行と作成者の両方で監視されます。 1つのインスタンスの指標が取得されない場合、その指標は不明としてレポートされ、対応する手順は失敗します。
この機能はサイトオプションです。
認証済みサイトを持つ AMS の顧客は、Cloud Manager が Web サイトのパフォーマンステスト中に Web サイトにアクセスするために使用するユーザー名とパスワードを指定できます。ユーザー名とパスワードは、CM_PERF_TEST_BASIC_USERNAME
と CM_PERF_TEST_BASIC_PASSWORD
という名前で、パイプライン変数に指定します。厳密に必須ではありませんが、ユーザー名には string 型変数を、パスワードには secretString 型変数を使用することをお勧めします。これらの両方を指定した場合、パフォーマンステストクローラーとテスト仮想ユーザーからのリクエストすべてに、HTTP 基本認証としての資格情報が含まれます。
Cloud Manager CLI を使用してこれらの変数を設定するには、次のコマンドを実行します。
$ aio cloudmanager:set-pipeline-variables <pipeline id> --variable CM_PERF_TEST_BASIC_USERNAME <username> --secret CM_PERF_TEST_BASIC_PASSWORD <password>
APIの使用方法については、変数を参照してください。
Cloud Managerでは、30分間のテスト期間にわたってアセットを繰り返しアップロードすることで、AEM Assetsプログラムのパフォーマンステストを実行します。
オンボーディング要件
アセットのパフォーマンステストの場合、お客様のサクセスエンジニアは、作成者からステージへの環境のオンボーディング中にcloudmanager
ユーザー(およびパスワード)を作成します。 パフォーマンステストの手順では、cloudmanager
というユーザーと、CSEによって設定された関連するパスワードが必要です。 作成者から削除したり、書き込み先を権限に変更したりしないでください。 これは、アセットのパフォーマンステストに失敗する可能性があります。
テスト用の画像とアセット
お客様は、独自のアセットをアップロードしてテストできます。 この操作は、パイプライン設定または編集画面でおこなうことができます。JPEG、PNG、GIF、BMP などの一般的な画像形式のほか、Photoshop ファイル、Illustrator ファイル、Postscript ファイルがサポートされています。ただし、画像がアップロードされない場合、Cloud Managerでは、デフォルトの画像とPDFドキュメントがテストに使用されます。
試験用資産の分配
1 分ごとにアップロードされる各タイプのアセット数の配分は、パイプライン設定または編集画面で設定します。例えば、次の図のように 70% と 30% に配分した場合は、1 分あたり 10 個のアセットがアップロードされ、うち 7 個が画像、3 個がドキュメントになります。
テストとレポート
Cloud Managerは、前述の手順1(オンボーディングの要件)でCSEが設定したユーザー名とパスワードを使用して作成者インスタンスにフォルダーを作成し、オープンソースのライブラリを使用してフォルダー内のアセットをアップロードします。 アセットのテスト手順で実行されるテストは、このオープンソースライブラリを使用して書き込まれます。 各アセットの処理時間と、様々なシステムレベルの指標の両方が、30分のテスト期間にわたって測定されます。 この機能では、画像と PDF ドキュメントの両方をアップロードできます。
パフォーマンステストの設定について詳しくは、CI/CDパイプラインの設定を参照してください。 プログラムのセットアップ方法とKPIの定義方法については、プログラムのセットアップを参照してください。
パフォーマンステスト結果ダイアログに、新しいグラフおよびダウンロードオプションが追加されました。
パフォーマンステストダイアログを開いた場合、指標パネルを展開して、グラフやダウンロードへのリンクを表示することができます。
Cloud Manager リリース 2018.7.0 の場合、この機能は次の指標で利用できます。
CPU 使用率
ディスク I/O 待機時間
ページエラー率
ディスク帯域幅使用量
ネットワーク帯域幅使用量
ピーク応答時間
第 95 百分位応答時間
パフォーマンステストグラフの表示例を次の図に示します。