プロジェクトの設定 setting-up-your-project
Cloud Manager でプロジェクトを管理およびデプロイできるようにプロジェクトを設定する方法について説明します。
既存プロジェクトの編集 modifying-project-setup-details
既存の AEM プロジェクトは、Cloud Manager で正常にビルドおよびデプロイするように、いくつかの基本ルールに従う必要があります。
-
プロジェクトは Apache Maven を使用してビルドする必要があります。
-
Git リポジトリのルートに
pom.xml
ファイルが必要です。- この
pom.xml
ファイルでは、必要な数のサブモジュール(その中にさらに他のサブモジュールを含む場合があります)を参照できます。 - 追加の Maven アーティファクトリポジトリへの参照を
pom.xml
ファイルに追加できます。 - 設定時には、パスワードで保護されたアーティファクトリポジトリーへのアクセスがサポートされます。ただし、ネットワークで保護されたアーティファクトリポジトリーへのアクセスはサポートされていません。
- この
-
デプロイ可能なコンテンツパッケージは、
target
という名前のディレクトリに含まれているコンテンツパッケージ .zip ファイルをスキャンすることで検出されます。- 任意の数のサブモジュールでコンテンツパッケージを作成することができます。
-
デプロイ可能な Dispatcher アーティファクトは、
conf
およびconf.d
という名前のtarget
のサブディレクトリに含まれているzip
ファイルをスキャンすることで検出されます。 -
複数のコンテンツパッケージがある場合、パッケージデプロイメントの順序は保証されません。
-
特定の順序が必要な場合は、コンテンツパッケージの依存関係を使用して順序を定義できます。
-
パッケージはデプロイメントからスキップできます。
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>!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 リポジトリのサポート password-protected-maven-repositories
パスワードで保護された Maven リポジトリのアーティファクトは、この方法でデプロイされるコードが Cloud Manager の品質ゲートによって適用される品質チェックに完全には従わないので、慎重に使用する必要があります。アドビでは、バイナリと共に Java ソースおよびプロジェクトのソースコード全体もデプロイすることをお勧めします。
Cloud Manager からのパスワードで保護された Maven リポジトリを使用するには、パスワード(および任意でユーザー名)を秘密のパイプライン変数として指定し、Git リポジトリの .cloudmanager/maven/settings.xml
という名前のファイル内でその秘密鍵を参照します。このファイルは、Maven 設定ファイルスキーマに従います。
Cloud Manager のビルドプロセスが開始すると、このファイル内の <servers>
要素が、Cloud Manager から提供されるデフォルトの settings.xml
ファイルに結合されます。カスタムサーバーでは、adobe
および cloud-manager
で始まるサーバー ID を使用しないでください。このような ID は予約済みと見なされます。Cloud Manager は、指定したプレフィックスの 1 つまたはデフォルトの ID central
に一致するサーバー ID のみをミラーリングします。
このファイルを配置すると、サーバー ID は pom.xml
ファイル内の <repository>
要素や <pluginRepository>
要素内から参照されます。一般に、これらの <repository>
要素や <pluginRepository>
要素は、Cloud Manager 固有のプロファイルに含まれていますが、厳密には必要ありません。
例えば、リポジトリが https://repository.myco.com/maven2
にあり、Cloud Manager が使用するユーザー名が cloudmanager
で、パスワードが secretword
だとします。
まず、パスワードをパイプライン上の秘密として設定します。
$ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword
次に、.cloudmanager/maven/settings.xml
ファイルから次を参照します。
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://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 を参照します。
<profiles>
<profile>
<id>cmBuild</id>
<activation>
<property>
<name>env.CM_BUILD</name>
</property>
</activation>
<build>
<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>
</build>
</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 コミットが抽出されます。コミットハッシュは、API を使用して UI に表示されます。ビルドステップが正常に完了すると、結果として生成されたアーティファクトはそのコミットハッシュに基づいて保存され、後続のパイプライン実行で再利用できます。
同じプログラム内にあるパッケージは、パイプラインをまたいで再利用されます。再利用可能なパッケージを探す際に、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
プログラムにはブランチ foo
とブランチ bar
という 2 つのブランチがあるとします。
両方のブランチのコミット 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
以外のパイプライン変数は考慮されません。
ベストプラクティスに基づくコードの開発 develop-your-code-based-on-best-practices
アドビのエンジニアリングチームとコンサルティングチームは、AEM 開発者向けの包括的なベストプラクティスを策定しました。