実稼動パイプラインの追加 configuring-production-pipelines
Cloud Manager を使用して、コードをデプロイする実稼動パイプラインを作成および設定する方法について説明します。 Cloud Managerでのパイプラインの仕組みについて詳しくは、CI/CD パイプライン を参照してください。
概要 overview
パイプライン設定タイルを Cloud Manager で使用すると、2 つの異なるタイプのパイプラインを作成できます。
- 実稼動パイプライン – 実稼動パイプラインは、Git リポジトリから実稼動にソースコードを取り込むための一連のオーケストレーションされた手順で構成される、専用に構築されたパイプラインです。
- 実稼動以外のパイプライン - 実稼動以外のパイプラインは、コード品質スキャンの実行または開発環境へのソースコードのデプロイを目的としています。
このドキュメントでは、実稼動パイプラインに焦点を当てます。 実稼動以外のパイプラインの設定方法について詳しくは、実稼動以外のパイプラインの設定のドキュメントを参照してください。
デプロイメントマネージャーの役割は、パイプラインを設定することです。 パイプライン設定は以下で構成されます。
- パイプラインを開始するトリガーの定義。
- 実稼動デプロイメントを制御するパラメーターの定義。
- パフォーマンステストパラメーターの設定。
実稼動パイプラインの追加 add-a-production-pipeline
Cloud Manager UI を使用してプログラムを設定し、少なくとも 1 つの環境を用意したら、実稼動パイプラインを追加する準備が整います。
-
my.cloudmanager.adobe.com で Cloud Manager にログインし、適切な組織とプログラムを選択します。
-
プログラムの概要ページから パイプライン カードに移動します。
-
「+ 追加」をクリックして、「実稼動パイプラインを追加」を選択します。
-
実稼動パイプラインを追加ダイアログボックスが開き、「設定」タブが開きます。このタブでは、パイプラインに対する複数のオプションを定義する必要があります。 これらのオプションは折りたたみ可能なセクションにグループ化されています。次の手順で説明します。
-
「パイプライン名」フィールドに、パイプラインのわかりやすい名前を指定します。
-
「環境」セクションでは、デプロイメントをトリガーするものと、環境ごとのロールアウト方法を定義します。
-
「ステージ」セクションでは、パイプラインをステージング環境にロールアウトする方法を定義できます。
-
デプロイメントトリガー - 次のオプションで、パイプラインを開始するデプロイメントトリガーを定義できます。
- 手動 - Cloud Manager UI を使用して、パイプラインを手動で開始します。
- Git の変更時 - 設定された Git 分岐にコミットが追加されるたびに CI/CD パイプラインを開始します。 このオプションを使用すると、必要に応じてパイプラインを手動で開始できます。
-
重要な指標のエラー動作 - パイプラインの設定または編集中に、デプロイメントマネージャーには、品質ゲートのいずれかで重要なエラーが発生した場合のパイプラインの動作を定義するオプションがあります。 使用できるオプションは以下のとおりです。
- 毎回確認する - デフォルトの設定。重要なエラーが検出されたときに手動で介入する必要があります。
- 直ちに失敗 - 重要なエラーが検出されると、パイプラインはキャンセルされます。 各エラーをユーザーが手動で拒否する状況をエミュレートします。
- 直ちに続行 - 重要なエラーが発生しても、パイプラインは自動的に続行されます。 各エラーをユーザーが手動で承認する状況をエミュレートします。
-
デプロイメントオプション - 特定のデプロイメントタスクを高速化できます。
-
ステージデプロイメント後に承認 - この承認は、テストが行われる前にステージング環境へのデプロイメント後に発生します。 それ以外の場合は、すべてのテストが完了した後、実稼動のデプロイメントの前に承認が行われます。
-
ロードバランサーの変更をスキップ - ロードバランサーの変更は行われません。
-
-
Dispatcher 設定 - デプロイメントマネージャーの役割は、パイプラインの実行時に AEM Dispatcher キャッシュから無効化またはフラッシュされる一連のコンテンツパスを設定できます。 これらのキャッシュアクションは、コンテンツパッケージがデプロイされた後、デプロイメントパイプラインステップの一部として実行されます。 これらの設定では、AEM Dispatcher の標準的な動作を使用します。 設定するには、次の手順を実行します。
-
「パス」で、コンテンツパスを指定します。
-
「種類」で、そのパスに対して実行するアクションを選択します。
- フラッシュ - キャッシュの削除を実行します。
- 無効化 - コンテンツがオーサーインスタンスからパブリッシュインスタンスに対してアクティベートされる場合と同様に、キャッシュの無効化を実行します。
-
「パスを追加」をクリックして、指定したパスを追加します。 環境につき最大 100 個のパスを追加できます。
-
note tip TIP 一般に、無効化アクションを使用する方が望ましいですが、フラッシュが必要な場合もあります（特に、AEM HTML クライアントライブラリを使用する場合など）。 -
-
「本番」セクションでは、パイプラインが本番環境にどのようにロールアウトされるかを定義できます。
-
デプロイメントオプション - 実稼動デプロイメントを制御するパラメーターを定義できます。
-
GoLive の承認を使用 - Cloud Manager UI を使用して、ビジネスオーナー、プロジェクトマネージャー、デプロイメントマネージャーのいずれかの役割を持つユーザーがデプロイメントを手動で承認する必要があります。
-
スケジュール設定 - 実稼動デプロイメントの前にパイプラインを停止し、スケジュールできるようにします。 このオプションを選択した場合、パイプラインはステージング環境へのデプロイメント後に停止し、実行するアクションをユーザーに促します。
Now- 実稼動環境に即座にデプロイされ、パイプラインを効果的に完了します。- 日付 - ユーザーはデプロイメントを完了する時刻をスケジュールできます。
- 実行を停止 - 実稼動環境へのデプロイメントを中止します。
note tip TIP デプロイメントスケジュールを設定する方法やパイプラインをすぐに実行する方法について詳しくは、コードのデプロイメントを参照してください。 -
CSE Oversight を使用 - このオプションを選択すると、CSE（カスタマーサクセスエンジニア）が実際にデプロイメントを開始します。 このオプションが有効な場合、パイプラインの作成または編集時に、デプロイメントマネージャーの役割には次のオプションがあります。
- 任意の CSE - 対応可能な任意の CSE がデプロイメントを開始できます。
- 担当の CSE - 顧客に割り当てられた特定の CSE のみがデプロイメントを開始できます。 このオプションは、割り当てられた CSE が対応できない場合に、CSE の指定されたバックアップにも当てはまります。
-
-
Dispatcher 設定 - 本番環境の Dispatcher 設定を定義します。 オプションは、ステージング環境のオプションと同じです。
-
-
-
-
「続行」をクリックして、Source コード タブに進み、デプロイするコードの種類を選択してソースリポジトリを設定します。
-
デプロイするコードを選択で、デプロイメントタイプを選択します。
これらのデプロイメントタイプについて詳しくは、CI/CD パイプライン を参照してください。 パイプライン設定を完了するための残りの手順は、選択したタイプによって異なります。 上記のリンクに従って、このドキュメントの関連セクションに移動します。
-
-
「続行」をクリックして「ステージテスト」タブに進み、ライセンスを取得した製品に応じて、AEM Sites と AEM Assets のパフォーマンステストを設定できます。
note tip TIP 「ステージテスト」タブで使用できるオプションについて詳しくは、コード品質テストを参照してください。 -
「サイトコンテンツ配信 / 負荷分散」セクションでは、3 つのページセット間でのページリクエストの重み付けに基づいて、サイトのパフォーマンステストを設定します。 必要に応じて、ページセットを有効または無効にできます。
- 頻度の高いライブページ
- その他のライブページ
- 新規ページ
-
「アセットパフォーマンステスト配布」セクションでは、画像と PDF のテスト配布を定義し、独自のテストアセットを定義します。
-
画像 - スライダーを調整して、画像と PDF 間のテスト分割を調整します。
-
PDF - スライダーを調整して、画像と PDF の間でテストの分割を調整します。
-
独自のカスタムアセットをアップロードして定義します。
- FORMAT - カスタムアセットがPDFか画像かを選択します。
- ファイル名 - ファイルブラウザーボタンを使用して、ローカルマシンから画像を選択します。
- テストファイルを追加 - クリックして、選択したアセットをアップロードします。
-
-
-
「保存」をクリックして、実稼動パイプラインの追加を完了します。
フルスタックコード full-stack-code
フルスタックコードパイプラインは、HTTPD/Dispatcher設定とともに、バックエンドおよびフロントエンドのコードビルドをデプロイします。
フルスタックコードの実稼動パイプラインを設定するには：
-
「ソースコード」タブで、次のオプションを定義します。
- リポジトリ - パイプラインがコードを取得するGit リポジトリを定義します。
note tip TIP Cloud Manager でリポジトリを追加および管理する方法について詳しくは、プログラムの設定のドキュメントを参照してください。 - Git Branch - パイプラインがコードを取得するブランチを定義します。
- web 階層設定を無視 - オンにすると、パイプラインは web 階層設定をデプロイしなくなります。 同じ環境にweb階層設定パイプラインが既に存在する場合、このチェックボックスは自動的に選択され、無効になります。これは、そのパイプラインが代わりにweb階層設定を管理するためです。 Web階層設定パイプラインが存在しない場合は、このオプションを選択またはクリアして、フルスタックパイプラインがDispatcher設定をデプロイするかどうかを制御できます。
-
「続行」をクリックして、ステージテスト タブに進みます。 詳しくは、 ステージテスト を参照してください。
Web 階層設定 web-tier-config
Web階層設定パイプラインは、HTTPD/Dispatcher設定のみをデプロイします。 このパイプラインタイプについて詳しくは、CI/CD パイプライン を参照してください。
既存のフルスタックパイプラインがある環境に対して web 階層設定パイプラインを作成すると、フルスタックパイプライン内の web 階層設定は無視されます。 この変更は、その環境の web 階層設定にのみ影響します。
Web階層設定の実稼動パイプラインを設定するには：
-
「ソースコード」タブで、次のオプションを定義します。
- リポジトリ - ドロップダウンリストから、Web階層設定を含むGit リポジトリを選択します。
- Git Branch - Cloud Managerがデプロイメントに使用するリポジトリ内のブランチを選択します。
- コードの場所 - デプロイするweb階層設定を含む、選択したリポジトリ内のパスを入力します。 デフォルトの場所は、リポジトリのルート （
/）です。
note NOTE コードの場所がDispatcher コードの場所を指していない場合、追加のアプリケーションコードをアーティファクトパッケージに取り込んでDispatcherにデプロイすると、Apacheが再起動で失敗し、パイプラインが失敗する可能性があります。 リポジトリ内のDispatcher ファイルへの正しいパスを設定してください。 
-
「続行」をクリックして、ステージテスト タブに進みます。 詳しくは、 ステージテスト を参照してください。
実稼動パイプラインでのスマートビルドの使用 about-smart-build
Cloud Managerの スマートビルド は、実稼動パイプライン用に最適化されたビルド戦略です。 スマートビルド モジュールをキャッシュし、前回の正常な実行以降に変更されたモジュールのみを再構築することで、ビルド時間を短縮します。 変更されていないモジュールはキャッシュから再利用されますが、変更されたモジュールとその依存関係のみが再構築され、反復的な開発ワークフローの効率が向上します。
スマートビルドは現在、次の目的で使用できます。
- コード品質パイプライン。
- 開発、ステージ、実稼動のフルスタックデプロイメントパイプライン。
次のような場合は、スマートビルドをお勧めします。
- 段階的な変更を頻繁に行っています。
- プロジェクトに複数のMaven モジュールが含まれています。
- 完全なビルドには膨大な時間がかかります。
スマートビルドは、次のような場合には必ずしも理想的ではありません。
- ビルドは、Mavenの依存グラフ外で操作を実行するプラグインに大きく依存しています。
- すべての実行に対して完全な再構築の検証が必要です。
ビルドパフォーマンスについて smart-build-performance
スマートビルドの使用によるパフォーマンスの向上は、次のような要因によって異なります。
- プロジェクト内のモジュール数。
- コード変更の頻度と範囲。
- モジュール間の依存関係の分布：
多くの独立したモジュールを使用したプロジェクトは、大きな改善をもたらします。
モジュールごとのキャッシュオプトアウト smart-build-cache-optout
スマートビルドでは、特定のモジュールのキャッシュを無効にできるきめ細かい制御が提供されます。 この機能は、特定のモジュールで次のような場合に便利です。
exec-maven-pluginやmaven-antrun-pluginなどのプラグインを使用します。- Mavenの依存関係によって追跡されないファイル操作を実行します。
- キャッシュすると一貫性のない結果が生成される。
モジュールのキャッシュを無効にする smart-build-disable-caching
影響を受けるモジュールのpom.xmlに次のプロパティを追加できます。
<properties>
<maven.build.cache.enabled>false</maven.build.cache.enabled>
</properties>
この構文により、モジュールはパイプラインの実行ごとに再構築され、他のモジュールはキャッシュから引き続きメリットを得ることができます。
スマートビルドを使用する際の制限事項と考慮事項 smart-build-limitations
スマートビルドを使用する場合は、次の点に注意してください。
- スマートビルドはMaven依存関係分析に依存しています。
- 依存関係グラフ以外の変更は、トリガーの再構築を行いません。
- 一部のプラグインはキャッシュと完全に互換性がありません。
- 実稼動パイプラインを編集することで、いつでも フルビルド に切り替えることができます。
予期しないビルド動作が発生した場合は、特定のモジュールのキャッシュを無効にするか、ビルド戦略を フルビルド に一時的に切り替えることを検討してください。
スマートビルドの問題を解決する smart-build-troubleshoot
・ プラグインの動作を確認します（特に
exec/antrun プラグイン）。・ほとんどのモジュールが頻繁に変更されているかどうかを確認します。
・ 完全ビルドを使用して検証します。
スマートビルドを有効にするには、実稼動パイプラインの追加を参照してください。
次の手順 the-next-steps
パイプラインを設定したら、コードをデプロイします。 詳しくは、コードのデプロイメントを参照してください。
ビデオチュートリアル video-tutorial-one
このビデオでは、パイプライン作成プロセスの概要を説明します。詳しくは、このドキュメントで説明します。