実稼動パイプラインの追加 configure-production-pipeline
本番パイプラインを設定し、コードをビルドして本番環境にデプロイする方法について説明します。本番パイプラインは、最初にコードをステージング環境にデプロイします。承認時に、同じコードが本番環境にデプロイされます。
本番パイプラインを設定するには、ユーザーに デプロイメントマネージャー の役割が必要です。
- プログラムが作成されます。
- Git リポジトリには 1 つ以上の分岐があります。
- 本番環境とステージング環境が作成されます。
コードのデプロイを開始する前に、Cloud Manager からパイプライン設定を行う必要があります。
新しい実稼動パイプラインの追加 adding-production-pipeline
プログラムを設定し、Cloud Manager UIを使用して少なくとも1つの環境を設定したら、次の手順に従って実稼動パイプラインを追加する準備が整います。
-
experience.adobe.comでCloud Managerにログインします。
-
クイックアクセス セクションで、Experience Managerをクリックします。
-
左側のサイドパネルで、「Cloud Manager」をクリックします。
-
必要な組織を選択します。
-
マイプログラム コンソールで、プログラムをクリックします。
-
マイプログラムコンソールで、プログラムを選択します。
-
プログラムの概要ページから パイプライン カードに移動し、「追加」をクリックして「実稼動パイプラインを追加」を選択します。
-
実稼動パイプラインを追加ダイアログボックスが表示されます。パイプラインを識別するための「パイプライン名」のほか、以下のオプションを指定します。「続行」をクリックします。
デプロイメントトリガー - パイプラインを開始するデプロイメントトリガーを定義する際には、次のオプションがあります。
- 手動 - パイプラインを手動で開始します。
- Git の変更時 - 設定された Git 分岐にコミットが追加されるたびに CI/CD パイプラインを開始します。このオプションを使用すると、必要に応じてパイプラインを手動で開始できます。
重要な指標のエラー動作 - パイプラインの設定または編集中に、デプロイメントマネージャーには、品質ゲートのいずれかで重要なエラーが発生した場合のパイプラインの動作を定義するオプションがあります。使用できるオプションは以下のとおりです。
- 毎回確認する - デフォルトの設定。重要なエラーが検出された場合は手動で介入する必要があります。
- 直ちに失敗 - 重要なエラーが検出されると、パイプラインがキャンセルされます。このプロセスでは、基本的に、ユーザーが各エラーを手動で拒否する状況をエミュレートします。
- 直ちに続行 - 重要なエラーが検出されても、パイプラインが自動的に続行されます。このプロセスでは、基本的に、ユーザーが各エラーを手動で承認する状況をエミュレートします。
-
「ソースコード」タブでは、パイプラインで処理するコードのタイプを選択します。
このタイプのパイプラインについて詳しくは、CI／CD パイプラインを参照してください。
実稼動パイプラインを作成する手順は、選択したソースコードのタイプによって異なります。上記のリンクをたどって、このドキュメントの次の節に移動し、パイプラインの設定を完了します。
フルスタックコードを使用している full-stack-code
フルスタックコードパイプラインは、1 つ以上の AEM サーバーアプリケーションを含んだバックエンドおよびフロンエンドコードビルドと HTTPD／Dispatcher 設定を同時にデプロイします。
フルスタックコードパイプラインを設定するには：
-
「ソースコード」タブで、次のオプションを定義します。
- リポジトリ - パイプラインがコードを取得する Git リポジトリを定義します。
note tip TIP Cloud Manager でリポジトリを追加および管理する方法については、リポジトリの追加と管理を参照してください。 -
Git ブランチ - ドロップダウンリストから、選択したリポジトリ内のどのブランチからパイプラインを構築するかを選択します。 デフォルトは、
mainです。 パイプラインは、選択したブランチをビルドとデプロイメントのソースとして使用します。 必要に応じて、更新をクリックして、選択したリポジトリで使用可能なブランチのリストを更新します。 最近作成したブランチがリストに表示されない場合は、このオプションを使用します。 -
戦略の構築
-
完全ビルド - リポジトリ内のすべてのモジュールを毎回作成します
-
BETA スマートビルド – 前回のコミット以降に変更されたモジュールのみをビルドします。
実稼動以外のパイプラインで スマートビルドを使用する方法について詳しく見る。note important IMPORTANT スマートビルドは、コード品質パイプラインとDev フルスタックコードのデプロイメントパイプラインでのみ使用できます。 * **Web 階層設定を無視** - オンにすると、パイプラインは web 階層設定をデプロイしなくなります。
-
-
実稼動へのデプロイ前に一時停止 - 実稼動環境にデプロイする前にパイプラインを一時停止します。
-
スケジュール設定 - ユーザーはスケジュールされた実稼動デプロイメントを有効にできます。
-
「続行」をクリックして「エクスペリエンス監査」タブに進みます。ここでは、エクスペリエンス監査に常に含めるパスを定義できます。
-
エクスペリエンス監査に含めるパスを指定します。
- 詳しくは、エクスペリエンス監査テストを参照してください。
-
「保存」をクリックしてパイプラインを保存します。
パイプラインの実行時に、エクスペリエンス監査の対象として設定したパスが送信され、パフォーマンス、アクセシビリティ、SEO、ベストプラクティス、PWA テストに基づいて評価されます。詳しくは、エクスペリエンス監査結果についてを参照してください。
パイプラインが保存され、プログラムの概要ページの パイプライン カードでパイプラインを管理できるようになりました。
ターゲットデプロイメントを使用しています targeted-deployment
ターゲットデプロイメントは、AEM アプリケーションの選択した部分のコードのみをデプロイします。このようなデプロイメントでは、次のいずれかのタイプのコードを 含める よう選択できます。
-
設定 - AEM 環境の様々な機能の設定を行います。
- ログ転送、パージ関連のメンテナンスタスク、および様々なCDN設定を含む、サポートされている設定のリストと、それらが適切にデプロイされるようにリポジトリで管理する方法については、設定パイプラインの使用を参照してください。
- ターゲットデプロイメントパイプラインを実行する場合、設定は、パイプラインで定義された環境、リポジトリ、およびブランチに保存される場合にデプロイされます。
- 設定パイプラインは、常に 1 つの環境に 1 つしか存在できません。
-
Edge Delivery Services設定パイプライン - Edge Delivery設定パイプラインには、個別の開発環境、ステージング環境、実稼動環境がありません。 AEM as a Cloud Serviceでは、変化が開発層、ステージ層、実稼動層を通過します。 対照的に、Edge Delivery設定パイプラインは、その設定をCloud Managerに登録されているすべてのEdge Delivery Sites ドメインに直接適用します。 詳しくは、Edge Delivery パイプラインの追加を参照してください。
-
フロントエンドコード - AEM アプリケーションのフロントエンド用に JavaScript と CSS を設定します。
- フロントエンドパイプラインを使用すると、フロントエンド開発者の作業の独立性が高まるほか、開発プロセスを速めることができます。
- このプロセスの可能性を最大限に引き出すために知っておくべきいくつかの考慮事項と、このプロセスがどのように機能するかについては、フロントエンドパイプラインを使用したサイトの開発のドキュメントを参照してください。
-
Web 階層の設定 - Web ページをクライアントに保存、処理、配信するための Dispatcher プロパティを設定します。
- 詳しくは、CI/CD パイプラインのドキュメントを参照してください。
- 選択した環境に web 階層コードパイプラインが存在する場合、この選択は無効になります。
- 既存のフルスタックパイプラインがある環境に対して web 階層設定パイプラインを作成すると、フルスタックパイプライン内の web 階層設定は無視されます。この変更は、その環境の web 階層設定にのみ影響します。
ターゲットデプロイメントパイプラインを設定するには：
- 必要なデプロイメントのタイプを選択します。
-
適格なデプロイメント環境を定義します。
- パイプラインがデプロイメントパイプラインの場合、デプロイ先の環境を選択する必要があります。
-
ソースコードの下で次のオプションを定義します。
- リポジトリ - このオプションは、パイプラインがコードを取得する Git リポジトリを定義します。
note tip TIP Cloud Manager でリポジトリを追加および管理する方法については、リポジトリの追加と管理を参照してください。 - Git ブランチ - このオプションは、選択したパイプラインのどのブランチからコードを取得するかを定義します。
- ブランチ名の最初の数文字と、このフィールドのオートコンプリート機能を入力します。これにより、選択可能な一致するブランチが検索されます。
- コードの場所 - このオプションは、パイプラインがコードを取得する必要がある、選択したリポジトリーのブランチ内のパスを定義します。
- 実稼動へのデプロイ前に一時停止 - このオプションを使用すると、実稼動環境にデプロイする前にパイプラインを一時停止できます。
- スケジュール設定 - ユーザーはスケジュールされた実稼動デプロイメントを有効にできます。Web 階層ターゲットのデプロイメントでのみ使用できます。
-
「保存」をクリックします。
パイプラインが保存され、プログラムの概要ページの パイプライン カードでパイプラインを管理できるようになりました。
BETA：実稼動パイプラインでのスマートビルドの使用について about-smart-build-production-pipeline
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 プラグイン）。・ほとんどのモジュールが頻繁に変更されているかどうかを確認します。
・検証には 完全ビルド を使用します。
スマートビルドを有効にするには、実稼動パイプラインの追加を参照してください。
Dispatcher パッケージのスキップ skip-dispatcher-packages
ビルドストレージに公開せずにパイプラインで Dispatcher パッケージを作成するには、公開オプションを無効にします。これにより、パイプラインの実行時間を短縮できる場合があります。
Dispatcher パッケージの公開を無効にする次の設定を、プロジェクトの pom.xml ファイルを使用して追加する必要があります。環境変数は、Cloud Manager ビルドコンテナで設定して、Dispatcher パッケージを無視するタイミングを決定するフラグとして機能します。
<profile>
<id>only-include-dispatcher-when-it-isnt-ignored</id>
<activation>
<property>
<name>env.IGNORE_DISPATCHER_PACKAGES</name>
<value>[!NOTE]rue</value>
</property>
</activation>
<modules>
<module>dispatcher</module>
</modules>
</profile>