プロジェクトのセットアップ

Maven を使用して AEM プロジェクトをビルドする方法と、独自のプロジェクトを作成する際に遵守する必要のある標準規格について説明します。

プロジェクト設定の詳細

Cloud Manager で正常にビルドおよびデプロイされるために、AEM プロジェクトは次のガイドラインに従う必要があります。

  • プロジェクトは Apache Maven を使用してビルドする必要があります。
  • Git リポジトリーのルートには pom.xml ファイルが必要です。この pom.xml ファイルでは、必要な数のサブモジュールを参照できます（それらのサブモジュールでさらに他のサブモジュールなどを参照している場合もあります）。
  • 追加の Maven アーティファクトリポジトリーへの参照を pom.xml ファイルに追加できます。
  • デプロイ可能なコンテンツパッケージは、target という名前のディレクトリに含まれているコンテンツパッケージ .zip ファイルをスキャンすることで検出されます。
    • 任意の数のサブモジュールでコンテンツパッケージを作成することもできます。
  • デプロイ可能な Dispatcher アーティファクトは、conf および conf.d というディレクトリを持つ .zip ファイル（これも target という名前のディレクトリに含まれる）をスキャンすることで検出されます。
  • 複数のコンテンツパッケージがある場合、パッケージデプロイメントの順序は保証されません。
    • 特定の順序が必要な場合は、コンテンツパッケージの依存関係を使用して順序を定義できます。
  • パッケージはデプロイメント時にスキップできます。

Cloud Manager での Maven プロファイルのアクティブ化

ごく一部のケースでは、Cloud Manager 内で実行する場合と、開発用ワークステーションで実行する場合とで、ビルドプロセスを若干変更する必要があるかもしれません。この場合は、Maven プロファイルを使用して、Cloud Manager を含む環境ごとのビルドの違いを定義できます。

Cloud Manager ビルド環境内での Maven プロファイルのアクティベーションは、CM_BUILD 環境変数があるかどうかを調べて行う必要があります。同様に、Cloud Manager ビルド環境以外でのみ使用するためのプロファイルは、この変数がないかどうかを調べることでアクティブ化する必要があります。

例えば、Cloud Manager 内でビルドが実行されたときにのみ簡単なメッセージを出力する場合は、次のようにします。

        <profile>
            <id>cmBuild</id>
            <activation>
                  <property>
                        <name>env.CM_BUILD</name>
                  </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.8</version>
                        <executions>
                            <execution>
                                <phase>initialize</phase>
                                <configuration>
                                    <target>
                                        <echo>I'm running inside Cloud Manager!</echo>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
メモ

開発用ワークステーションでこのプロファイルをテストするには、（-PcmBuild を付けた）コマンドラインまたは統合開発環境（IDE）でプロファイルを有効にします。

Cloud Manager 以外でビルドが実行されたときにのみ簡単なメッセージを出力する場合は、次のようにします。

        <profile>
            <id>notCMBuild</id>
            <activation>
                  <property>
                        <name>!env.CM_BUILD</name>
                  </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.8</version>
                        <executions>
                            <execution>
                                <phase>initialize</phase>
                                <configuration>
                                    <target>
                                        <echo>I'm running outside Cloud Manager!</echo>
                                    </target>
                                </configuration>
                                <goals>
                                    <goal>run</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

パスワードで保護された Maven リポジトリーのサポート

メモ

パスワードで保護された Maven リポジトリーのアーティファクトは、慎重に使用する必要があります。これは、このメカニズムを通じてデプロイされるコードは現在、Cloud Manager の品質ゲートに実装されているすべてのコード品質ルールを通じて実行されないからです。したがって、まれなケースで、AEM に結び付けられていないコードに対してのみ使用する必要があります。Java ソース、およびプロジェクトのソースコード全体もバイナリとともにデプロイすることをお勧めします。

パスワードで保護された Maven リポジトリーを Cloud Manager 内で使用するには：

  1. パスワード（およびオプションでユーザー名）をシークレットのパイプライン変数として指定します。
  2. 次に、Git リポジトリーの .cloudmanager/maven/settings.xml という名前のファイル内でそのシークレットを参照します。このファイルは、Maven Settings File スキーマに従います。

Cloud Manager のビルドプロセスが開始したとき、以下が行われます。

  • このファイル内の <servers> 要素が、Cloud Manager から提供されるデフォルトの settings.xml ファイルに結合されます。
    • adobe と cloud-manager で始まるサーバー ID は予約済みと見なされるため、カスタムサーバーでは使用しないでください。
    • サーバー ID がこれらのプレフィックスのいずれかに一致しない場合、デフォルトの ID central は Cloud Manager でミラーリングされません。
  • このファイルを配置すると、サーバー ID は <repository> 内や pom.xml ファイル内の <pluginRepository> 要素から参照されます。
  • 一般に、これらの <repository> や <pluginRepository> 要素は、Cloud Manager 固有のプロファイルに含まれますが、厳密に必要とは限りません。

例えば、リポジトリーが https://repository.myco.com/maven2 にあり、Cloud Manager が使用するユーザー名が cloudmanager で、パスワードが secretword だとします。次の手順を実行します。

  1. パスワードをパイプライン内のシークレットとして設定します。

    $ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword`

  2. これを .cloudmanager/maven/settings.xml ファイルから参照します。

    <?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="https://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="https://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
    <servers>
        <server>
            <id>myco-repository</id>
            <username>cloudmanager</username>
           <password>${env.CUSTOM_MYCO_REPOSITORY_PASSWORD}</password>
        </server>
    </servers>
</settings>

  3. 最後に、pom.xml ファイル内のサーバー ID を参照します。

    <profiles>
    <profile>
        <id>cmBuild</id>
        <activation>
                <property>
                    <name>env.CM_BUILD</name>
                </property>
        </activation>
        <repositories>
             <repository>
                 <id>myco-repository</id>
                 <name>MyCo Releases</name>
                 <url>https://repository.myco.com/maven2</url>
                 <snapshots>
                     <enabled>false</enabled>
                 </snapshots>
                 <releases>
                     <enabled>true</enabled>
                 </releases>
             </repository>
         </repositories>
         <pluginRepositories>
             <pluginRepository>
                 <id>myco-repository</id>
                 <name>MyCo Releases</name>
                 <url>https://repository.myco.com/maven2</url>
                 <snapshots>
                     <enabled>false</enabled>
                 </snapshots>
                 <releases>
                     <enabled>true</enabled>
                 </releases>
             </pluginRepository>
         </pluginRepositories>
    </profile>
</profiles>

ソースのデプロイ

バイナリと共に Java ソースを Maven リポジトリーにデプロイすることをお勧めします。

それには、プロジェクトに maven-source-plugin を設定します。

         <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-source-plugin</artifactId>
             <executions>
                 <execution>
                     <id>attach-sources</id>
                     <goals>
                         <goal>jar-no-fork</goal>
                     </goals>
                 </execution>
             </executions>
         </plugin>

プロジェクトソースのデプロイ

バイナリと一緒にプロジェクトソース全体を Maven リポジトリーにデプロイすることをお勧めします。これにより、正確なアーティファクトを再ビルドできます。

それには、プロジェクトに maven-assembly-plugin を設定します。

         <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-assembly-plugin</artifactId>
             <executions>
                 <execution>
                     <id>project-assembly</id>
                     <phase>package</phase>
                     <goals>
                         <goal>single</goal>
                     </goals>
                     <configuration>
                         <descriptorRefs>
                             <descriptorRef>project</descriptorRef>
                         </descriptorRefs>
                     </configuration>
                 </execution>
             </executions>
         </plugin>

コンテンツパッケージのスキップ

Cloud Manager では、ビルドは、任意の数のコンテンツパッケージを作成できます。
様々な理由により、コンテンツパッケージを生成してもデプロイしないことが望ましい場合があります。例えば、テストのみに使用するコンテンツパッケージを作成する場合や、ビルドプロセスの別のステップで（つまり、別のパッケージのサブパッケージとして）再パッケージ化される場合です。

これらのシナリオに対応するために、Cloud Manager は、ビルドコンテンツパッケージのプロパティで、cloudManagerTarget という名前のプロパティを探します。このプロパティが none に設定されている場合、パッケージはスキップされ、デプロイされません。

このプロパティを設定する仕組みは、ビルドがコンテンツパッケージを生成する方法によって異なります。例えば、filevault-maven-plugin を使用する場合は、次のようにプラグインを設定します。

        <plugin>
            <groupId>org.apache.jackrabbit</groupId>
            <artifactId>filevault-package-maven-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                <properties>
                    <cloudManagerTarget>none</cloudManagerTarget>
                </properties>
        <!-- other configuration -->
            </configuration>
        </plugin>

content-package-maven-plugin にも同様の設定があります。

        <plugin>
            <groupId>com.day.jcr.vault</groupId>
            <artifactId>content-package-maven-plugin</artifactId>
            <extensions>true</extensions>
            <configuration>
                <properties>
                    <cloudManagerTarget>none</cloudManagerTarget>
                </properties>
        <!-- other configuration -->
            </configuration>
        </plugin>

ビルドアーティファクトの再利用

多くの場合、同じコードが複数の AEM 環境にデプロイされます。Cloud Manager は、複数のフルスタックパイプライン実行で同じ Git コミットが使用されていることを検出した場合、コードベースの再ビルドを可能な限り避けます。

実行が開始されると、ブランチパイプラインの現在の HEAD コミットが抽出されます。コミットハッシュは、UI に表示され、API を使用して確認できます。ビルドステップが正常に完了すると、結果として生成されたアーティファクトはそのコミットハッシュに基づいて保存され、後続のパイプライン実行で再利用できます。

同じプログラム内にあるパッケージは、パイプラインをまたいで再利用されます。再利用可能なパッケージを探す際に、AEM はブランチを無視し、ブランチをまたいでアーティファクトを再利用します。

再利用が行われると、ビルドステップとコード品質ステップが元の実行の結果に事実上置き換えられます。ビルドステップのログファイルには、アーティファクトと、最初にアーティファクトのビルドに使用された実行情報が一覧表示されます。

そのようなログ出力の例を次に示します。

The following build artifacts were reused from the prior execution 4 of pipeline 1 which used commit f6ac5e6943ba8bce8804086241ba28bd94909aef:
build/aem-guides-wknd.all-2021.1216.1101633.0000884042.zip (content-package)
build/aem-guides-wknd.dispatcher.cloud-2021.1216.1101633.0000884042.zip (dispatcher-configuration)

コード品質ステップのログにも、類似の情報が含まれます。

例

例 1

プログラムに 2 つの開発パイプラインがあるとします。

  • ブランチ foo のパイプライン 1
  • ブランチ bar のパイプライン 2

両方のブランチが同じコミット ID 上にあります。

  1. 最初にパイプライン 1 を実行すると、パッケージは通常どおりビルドされます。
  2. その後、パイプライン 2 を実行すると、パイプライン 1 で作成したパッケージが再利用されます。

例 2

プログラムには次の 2 つのブランチがあるとします。

  • ブランチ foo
  • ブランチ bar

両方のブランチのコミット ID が同じです。

  1. 開発パイプラインは、foo のビルドと実行を行います。
  2. その後、実稼動パイプラインが bar をビルドおよび実行します。

この場合、同じコミットハッシュが特定されたので、foo のアーティファクトは実稼動パイプラインで再利用されます。

オプトアウト

必要に応じて、パイプライン変数 CM_DISABLE_BUILD_REUSE を true に設定して、特定のパイプラインに対して再利用動作を無効にできます。この変数を設定した場合でも、コミットハッシュは抽出され、結果として生成されたアーティファクトは後で使用するために保存されますが、以前に保存されたアーティファクトは再利用されません。この動作を理解するために、次のシナリオについて考えてみます。

  1. 新しいパイプラインが作成されます。
  2. そのパイプラインが実行され（実行番号 1）、現在の HEAD コミットが becdddb となっています。実行が完了すると、結果として生成されたアーティファクトが保存されます。
  3. この CM_DISABLE_BUILD_REUSE 変数が設定されます。
  4. コードを変更せずにパイプラインが再実行されます。becdddb に関連付けられたアーティファクトが保存されていますが、CM_DISABLE_BUILD_REUSE 変数が設定されているので再利用されません。
  5. コードが変更され、パイプラインが実行されます。HEAD コミットは f6ac5e6 になります。実行が完了すると、結果として生成されたアーティファクトが保存されます。
  6. CM_DISABLE_BUILD_REUSE 変数が削除されます。
  7. コードを変更せずに、パイプラインが再実行されます。f6ac5e6 に関連付けられたアーティファクトが保存されているため、それらのアーティファクトは再利用されます。

注意事項

  • ビルドアーティファクトは、コミットハッシュが同じかどうかに関係なく、異なるプログラムをまたいで再利用されることはありません。
  • ブランチやパイプラインが異なる場合でも、ビルドアーティファクトは同じプログラム内で再利用されます。
  • Maven バージョン処理では、実稼動パイプラインでのみ、プロジェクトのバージョンを置き換えます。したがって、開発デプロイ実行と実稼動パイプライン実行の両方で同じコミットが使用され、開発デプロイパイプラインが先に実行される場合、バージョンは変更されずにステージング環境と実稼動環境にデプロイされます。ただし、この場合もタグは作成されます。
  • 保存されたアーティファクトが正常に取得されなかった場合、ビルドステップは、アーティファクトが保存されていない場合と同じように実行されます。
  • 以前に作成したビルドアーティファクトを Cloud Manager で再利用する場合、CM_DISABLE_BUILD_REUSE 以外のパイプライン変数は考慮されません。

このページ