プロジェクトのセットアップ project-setup
Maven を使用して AEM プロジェクトをビルドする方法と、独自のプロジェクトを作成する際に確認する必要がある標準について説明します。
プロジェクトの設定の詳細 project-setup-details
Cloud Manager で正常にビルドおよびデプロイするには、AEM プロジェクトは次のガイドラインに従う必要があります。
- プロジェクトは Apache Maven を使用してビルドする必要があります。
- Git リポジトリーのルートには
pom.xmlファイルが必要です。 このpom.xmlファイルは、必要に応じて多数のサブモジュール (その他のサブモジュールなど)を参照します。 - 追加の Maven アーティファクトリポジトリへの参照を
pom.xmlファイルに追加できます。 設定時には、パスワードで保護されたアーティファクトリポジトリーへのアクセスがサポートされます。 ただし、ネットワークで保護されたアーティファクトリポジトリーへのアクセスはサポートされていません。 - Cloud Managerは、
targetという名前のディレクトリに含まれているコンテンツパッケージ.zipファイルをスキャンして、デプロイ可能なコンテンツパッケージを検出します。 任意の数のサブモジュールがコンテンツパッケージを生成します。 - Cloud Managerは、
confおよびconf.dという名前のディレクトリを持つ.zipファイル(targetという名前のディレクトリにも含まれる)をスキャンして、デプロイ可能なDispatcher アーティファクトを検出します。 - 複数のコンテンツパッケージがある場合、パッケージデプロイメントの順序は保証されません。 特定の順序が必要な場合は、コンテンツパッケージの依存関係を使用して順序を定義できます。
- デプロイメント中にパッケージが スキップ されます。
Cloud Manager での Maven プロファイルのアクティベート activating-maven-profiles-in-cloud-manager
一部の限られたケースでは、デベロッパーワークステーションで実行する場合とは異なり、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>[!NOTE]nv.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>
Cloud Manager 内でのパスワードで保護された Maven リポジトリの使用 password-protected-maven-repositories
パスワードで保護された Maven リポジトリを Cloud Manager 内で使用するには:
- パスワード(およびオプションでユーザー名)をシークレットのパイプライン変数として指定します。
- 次に、Git リポジトリーの
.cloudmanager/maven/settings.xmlという名前のファイル内でそのシークレットを参照します。このファイルは、Maven Settings File スキーマに従います。
Cloud Manager のビルドプロセスが開始したとき、以下が行われます。
-
このファイル内の
<servers>要素が、Cloud Manager から提供されるデフォルトのsettings.xmlファイルに結合されます。adobeとcloud-managerで始まるサーバー ID は予約済みと見なされます。 カスタムサーバーでは使用しないでください。- Cloud Manager は、特定の接頭辞またはデフォルトの ID
centralに一致するサーバー ID のみをミラーリングします。その他のサーバー ID はすべてミラーリングから除外されます。
-
このファイルを配置した状態で、
pom.xmlファイル内の<repository>および/または<pluginRepository>要素の中からサーバーIDを参照します。 -
これらの
<repository>要素と<pluginRepository>要素はCloud Manager固有のプロファイル に含まれていますが、厳密には含める必要はありません。
例えば、リポジトリがhttps://repository.myco.com/maven2で、Cloud Managerが使用するユーザー名がcloudmanager、パスワードがsecretwordであるとします。 次の手順を実行します。
-
パスワードをパイプライン内のシークレットとして設定します。
code language-text $ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword` -
次の
.cloudmanager/maven/settings.xmlファイルからこの秘密鍵を参照します。code language-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> -
最後に、
pom.xmlファイル内のサーバーIDを参照します。code language-xml <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>
ソースのデプロイ deploying-sources
バイナリと一緒に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>
プロジェクトソースのデプロイ deploying-project-sources
バイナリと共にプロジェクトソース全体を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>
コンテンツパッケージのスキップ skipping-content-packages
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>
アーティファクトの再利用の構築 build-artifact-reuse
多くの場合、同じコードが複数の 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)
コード品質ステップのログには、類似した情報が含まれます。
例 example-reuse
例 1 example-1
プログラムに 2 つの開発パイプラインがあるとします。
- ブランチ
fooのパイプライン 1 - ブランチ
barのパイプライン 2
両方のブランチが同じコミット ID 上にあります。
- 最初にパイプライン 1 を実行すると、パッケージは通常どおりビルドされます。
- その後、パイプライン 2 を実行すると、パイプライン 1 で作成されたパッケージが再利用されます。
例 2 example-2
プログラムには次の 2 つのブランチがあるとします。
- ブランチ
foo - ブランチ
bar
両方のブランチのコミット ID が同じです。
- 開発パイプラインは、
fooのビルドと実行を行います。 - その後、実稼動パイプラインが
barをビルドおよび実行します。
この場合、同じコミットハッシュが特定されたので、foo のアーティファクトは実稼動パイプラインで再利用されます。
オプトアウト opting-out
必要に応じて、パイプライン変数 CM_DISABLE_BUILD_REUSE を true に設定して、特定のパイプラインに対して再利用動作を無効にできます。 この変数が設定されている場合、システムではコミットハッシュが抽出され、結果として生成されたアーティファクトは後で使用するために保存されますが、以前に保存されたアーティファクトの再利用はスキップされます。 この動作を理解するには、次のシナリオについて考えます。
- 新しいパイプラインが作成されます。
- そのパイプラインが実行され(実行番号 1)、現在の HEAD コミットが
becdddbとなっています。 実行が完了すると、結果として生成されたアーティファクトが保存されます。 - この
CM_DISABLE_BUILD_REUSE変数が設定されます。 - コードを変更せずにパイプラインが再実行されます。
becdddbに関連付けられたアーティファクトが保存されていますが、CM_DISABLE_BUILD_REUSE変数が設定されているので再利用されません。 - コードが変更され、パイプラインが実行されます。 HEAD コミットは
f6ac5e6になります。 実行が完了すると、結果として生成されたアーティファクトが保存されます。 CM_DISABLE_BUILD_REUSE変数が削除されます。- コードを変更せずに、パイプラインが再実行されます。
f6ac5e6に関連付けられたアーティファクトが保存されているため、それらのアーティファクトは再利用されます。
注意事項 caveats
- コミット ハッシュが同じかどうかに関係なく、ビルド アーティファクトは異なるプログラム間で再利用されません。
- ブランチやパイプラインが異なる場合でも、ビルドアーティファクトは同じプログラム内で再利用されます。
- Maven バージョン処理は、実稼動パイプライン内のプロジェクトバージョンのみを置き換えます。
開発用デプロイメントと実稼動用パイプラインの両方に同じコミットが使用され、開発用デプロイメントが最初に実行された場合、バージョンはステージングおよび実稼動用に変更されずにデプロイされます。ただし、この場合はタグが作成されます。 - 保存されたアーティファクトが正常に取得されなかった場合、ビルドステップは、アーティファクトが保存されていない場合と同じように実行されます。
- 以前に作成したビルドアーティファクトを Cloud Manager で再利用する場合、
CM_DISABLE_BUILD_REUSE以外のパイプライン変数は考慮されません。