実稼動以外のパイプラインの追加 configuring-non-production-pipelines

プログラムを設定し、Cloud Manager UIで少なくとも1つの環境を作成したら、実稼動以外のパイプラインを追加できます。 これらのパイプラインを使用すると、実稼動環境にデプロイする前にコード品質をテストできます。

実稼働パイプラインを設定するには、ユーザーに​ デプロイメントマネージャー ​の役割が必要です。

NOTE
初期設定後に、パイプライン設定を編集できます。

新しい実稼動以外のパイプラインの追加 adding-non-production-pipeline

プログラムを設定し、Cloud Manager UIで少なくとも1つの環境を作成したら、実稼動以外のパイプラインを追加できます。 実稼動環境にデプロイする前に、これらのパイプラインを使用してコード品質をテストします。

新しい実稼動以外のパイプラインを追加するには:

  1. experiece.adobe.com で Cloud Manager にログインします。

  2. クイックアクセス セクションで、Experience Manager​をクリックします。

  3. 左側のサイドパネルで、「Cloud Manager」をクリックします。

  4. 必要な組織を選択します。

  5. マイプログラム コンソールで、プログラムをクリックします。

  6. 左側のパネルで、パイプライン​をクリックします。

  7. パイプライン ページの右上隅付近で、パイプラインを追加 > 実稼動以外のパイプラインを追加​をクリックします。

    実稼動以外のパイプラインを追加

  8. 実稼動以外のパイプラインを追加 ダイアログボックスの「設定」タブで、作成する次のいずれかの実稼動以外のパイプラインを選択します。

    • コード品質パイプライン - GIT ブランチでコードをビルドし、単体テストを実行し、環境にデプロイせずにコード品質を評価するパイプラインを作成します。
    • デプロイメントパイプライン - コードのビルド、単体テストの実行、コード品質の評価、実稼動以外の環境へのデプロイを行うパイプラインを作成します。

    実稼動以外のパイプラインを追加ダイアログ

  9. パイプライン設定」セクションの「実稼動以外のパイプライン名」フィールドに、実稼動以外のパイプラインの説明を入力します。

  10. デプロイメントオプション」セクションで、使用するデプロイメントトリガーの1つを選択します。

    • 手動 - パイプラインを手動で開始します。
    • Git の変更時 - 設定された Git 分岐にコミットが追加される際にパイプラインを開始します。 このオプションを使用すると、必要に応じてパイプラインを手動で開始できます。
  11. 使用する​ 重要な指標の失敗の動作 ​を選択します。

    • 毎回確認する - デフォルトの設定。重要なエラーが検出されたときに手動で介入する必要があります。
    • 直ちに失敗 - 重要なエラーが検出されると、パイプラインはキャンセルされます。基本的に、各エラーを手動で拒否するユーザーをエミュレートします。
    • 直ちに続行 - 重要なエラーが検出されても、パイプラインは自動的に続行されます。基本的に、各エラーを手動で承認するユーザーをエミュレートします。
  12. 続行」をクリックします。

  13. 実稼動以外のパイプラインの設定を完了するために使用する残りの手順は、使用するソースコードのタイプによって異なります。
    実稼動以外のパイプラインを追加 ダイアログボックスの「Source コード」タブで、実稼動以外のパイプラインで処理するコードの種類を選択します。

    パイプラインのタイプについて詳しくは、CI/CD パイプラインを参照してください。

フルスタックコードを使用している full-stack-code

フルスタックコードパイプラインは、1 つ以上の AEM サーバーアプリケーションを含んだバックエンドおよびフロンエンドコードビルドと HTTPD/Dispatcher 設定を同時にデプロイします。

NOTE
選択した環境にフルスタックコードパイプラインが存在する場合、この選択は無効になります。

フルスタックコードの実稼動以外のパイプラインの設定を完了するには、次の操作を行います。

  1. Source コード」セクションで、次のオプションを定義します。

    • 適格なデプロイメント環境 – 実稼動以外のパイプラインを編集する場合にのみ使用できます。 パイプラインがデプロイメントパイプラインの場合、デプロイ先の環境を選択する必要があります。

    • リポジトリ - ドロップダウンリストから、パイプラインがソースとして使用するGit リポジトリを選択します。 Cloud Managerは、ここで選択したリポジトリからコードをビルドします。

      note tip
      TIP
      Cloud Manager でリポジトリを追加および管理する方法については、リポジトリの追加と管理を参照してください。
    • Git ブランチ - ドロップダウンリストから、選択したリポジトリ内のどのブランチからパイプラインを構築するかを選択します。 デフォルトは、main です。 パイプラインは、選択したブランチをビルドとデプロイメントのソースとして使用します。 必要に応じて、更新​をクリックして、選択したリポジトリで使用可能なブランチのリストを更新します。 最近作成したブランチがリストに表示されない場合は、このオプションを使用します。

    • 戦略の構築

      • 完全ビルド - リポジトリ内のすべてのモジュールを毎回作成します

      • BETA スマートビルド – 前回のコミット以降に変更されたモジュールのみをビルドします。
        実稼動以外のパイプラインで​ スマートビルドを使用する方法について詳しく見る

        note important
        IMPORTANT
        スマートビルドは、コード品質パイプラインとDev フルスタックコードのデプロイメントパイプラインでのみ使用できます。
    • Web階層設定を無視 チェックボックス – オンにすると、パイプラインがWeb階層設定をデプロイしません。

  2. パイプライン」セクションでは、パイプラインがデプロイメントパイプラインの場合、テストフェーズを実行することを選択できます。 このフェーズで有効にするオプションを選択します。どのオプションも選択していない場合、テストフェーズはパイプラインの実行中に表示されません。

    フルスタックパイプライン

  3. 保存」をクリックします。

パイプラインが保存され、[ パイプラインを管理できるようになりました] (managing-pipe
プログラムの概要 ページの​パイプライン カードのlines.md)です。

ターゲットデプロイメントを使用しています targeted-deployment

ターゲットデプロイメントは、AEM アプリケーションの選択した部分のコードのみをデプロイします。このようなデプロイメントでは、次のいずれかのタイプのコードを​ 含む ​よう選択できます。

ターゲットデプロイメントオプション

  • フロントエンドコード - AEM アプリケーションのフロントエンド用に JavaScript と CSS を設定します。

    • フロントエンドパイプラインを使用すると、フロントエンド開発者の作業の独立性が高まるほか、開発プロセスを速めることができます。
    • このプロセスの可能性を最大限に引き出すために知っておくべきいくつかの考慮事項と、このプロセスがどのように機能するかについては、フロントエンドパイプラインを使用したサイトの開発のドキュメントを参照してください。
  • Web 階層の設定 - Web ページをクライアントに保存、処理、配信するための Dispatcher プロパティを設定します。

    • 詳しくは、CI/CD パイプラインのドキュメントを参照してください。

    • 選択した環境に web 階層コードパイプラインが存在する場合、この選択は無効になります。

    • フルスタックパイプラインが既に環境にデプロイされている場合でも、同じ環境に対してweb層設定パイプラインを作成できます。 これを行うと、Cloud Managerはフルスタックパイプラインのweb層設定を無視します。

      note note
      NOTE
      Web 階層設定パイプラインは、プライベートリポジトリではサポートされていません。制限の詳細と完全なリストについては、Cloud Manager でのプライベートリポジトリの追加を参照してください。
  1. Source コード」セクションで、次のオプションを定義します。

    • リポジトリ – このオプションは、実稼動以外のパイプラインがコードを取得するGIT リポジトリを定義します。

      note tip
      TIP
      Cloud Manager でリポジトリを追加および管理する方法については、リポジトリの追加と管理を参照してください。
    • Git Branch – このオプションは、選択したパイプラインのどのブランチからコードを取得するかを定義します。 ブランチ名の最初の数文字と、このフィールドのオートコンプリート機能を入力します。これにより、選択可能な一致するブランチが検索されます。

    • コードの場所 - このオプションは、パイプラインがコードを取得する必要がある、選択したリポジトリーのブランチ内のパスを定義します。

  2. エクスペリエンス監査を有効にした場合は、「続行」をクリックして「エクスペリエンス監査」タブに進みます。ここでは、エクスペリエンス監査に常に含めるパスを定義できます。

    • エクスペリエンス監査」を有効にした場合、設定方法について詳しくは、エクスペリエンス監査のドキュメントを参照してください。
    • 有効にしていない場合は、この手順をスキップします。
  3. 保存」をクリックしてパイプラインを保存します。

パイプラインが保存され、プログラムの概要​ページの​ パイプライン ​カードでパイプラインを管理できるようになりました。

実稼動以外のパイプラインでのスマートビルドの使用について about-smart-build

Cloud Managerの​ スマートビルド ​は、実稼動以外のパイプライン向けに最適化されたビルド戦略です。 スマートビルド モジュールをキャッシュし、前回の正常な実行以降に変更されたモジュールのみを再構築することで、ビルド時間を短縮します。 変更されていないモジュールはキャッシュから再利用されますが、変更されたモジュールとその依存関係のみが再構築され、反復的な開発ワークフローの効率が向上します。

スマートビルドは現在、次の場合にのみ使用できます。

  • コード品質パイプライン。
  • フルスタックのデプロイメントパイプラインを開発する。
NOTE
スマートビルドを有効にした後の最初の実行は、キャッシュが空であるため、フルビルドのように動作します。

次のような場合は、スマートビルドをお勧めします。

  • 段階的な変更を頻繁に行っています。
  • プロジェクトに複数のMaven モジュールが含まれています。
  • 完全なビルドには膨大な時間がかかります。

スマートビルドは、次のような場合には必ずしも理想的ではありません。

  • ビルドは、Mavenの依存グラフ外で操作を実行するプラグインに大きく依存しています。
  • すべての実行に対して完全な再構築の検証が必要です。

ビルドパフォーマンスについて smart-build-performance

スマートビルドの使用によるパフォーマンスの向上は、次のような要因によって異なります。

  • プロジェクト内のモジュール数。
  • コード変更の頻度と範囲。
  • モジュール間の依存関係の分布:

一般的に、多くの独立したモジュールを伴うプロジェクトは、大きな改善が見られます。

モジュールごとのキャッシュオプトアウト smart-build-cache-optout

スマートビルドでは、特定のモジュールのキャッシュを無効にできるきめ細かい制御が提供されます。 この機能は、特定のモジュールで次のような場合に便利です。

  • exec-maven-pluginmaven-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 プラグイン)。
パフォーマンスが向上しない
・ 複数の実行が発生したことを確認します(キャッシュウォームアップ)。
・ほとんどのモジュールが頻繁に変更されているかどうかを確認します。
予期しないアーティファクトまたは欠落している変更
・ 変更がMaven依存関係トラッキング外かどうかを確認します。
・検証には​ 完全ビルド ​を使用します。

スマートビルドを有効にする実稼動以外のパイプラインを追加を参照してください。

Dispatcher パッケージの除外 exclude-dispatcher-packages

パイプラインにDispatcher パッケージを組み込むが、ストレージを構築するためにアップロードしない場合は、公開を無効にします。 そうすることで、パイプラインのランタイムを短縮できます。

次の設定をプロジェクト pom.xml ファイルに追加して、Dispatcher パッケージの公開を無効にします。 Cloud Manager ビルドコンテナで環境変数を設定して、Dispatcher パッケージを無視するタイミングをフラグします。 パイプラインはこのフラグを読み取り、それに応じて無視します。

<profile>
  <id>only-include-dispatcher-when-it-isnt-ignored</id>
  <activation>
    <property>
      <name>env.IGNORE_DISPATCHER_PACKAGES</name>
      <value>!true</value>
    </property>
  </activation>
  <modules>
    <module>dispatcher</module>
  </modules>
</profile>
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab