プロジェクトの設定 setting-up-your-project

Cloud Manager でプロジェクトを管理およびデプロイできるようにプロジェクトを設定する方法について説明します。

既存プロジェクトの編集 modifying-project-setup-details

既存の AEM プロジェクトは、Cloud Manager で正常にビルドおよびデプロイするように、いくつかの基本ルールに従う必要があります。

  • プロジェクトは Apache Maven を使用してビルドする必要があります。

  • Git リポジトリのルートに pom.xml ファイルが必要です。

    • このpom.xml ファイルは、必要な数のサブモジュール (その後、他のサブモジュールを含む)を参照できます。
    • 追加の Maven アーティファクトリポジトリへの参照を pom.xml ファイルに追加できます。
    • 設定時には、パスワードで保護されたアーティファクトリポジトリーへのアクセスがサポートされます。 ただし、ネットワークで保護されたアーティファクトリポジトリーへのアクセスはサポートされていません。
  • Cloud Managerは、targetという名前のディレクトリに含まれているコンテンツパッケージ .zip ファイルをスキャンして、デプロイ可能なコンテンツパッケージを検出します。

    • 任意の数のサブモジュールがコンテンツパッケージを生成します。
  • Cloud Managerは、confおよびconf.dという名前のtargetのサブディレクトリに含まれるzip個のファイルをスキャンすることで、デプロイ可能なDispatcher アーティファクトを検出します。

  • 複数のコンテンツパッケージがある場合、パッケージデプロイメントの順序は保証されません。

    • 特定の順序が必要な場合は、コンテンツパッケージの依存関係を使用して順序を定義できます。
  • パッケージは、デプロイメントから​ スキップ ​できます。

Cloud Manager での Maven プロファイルのアクティベート activating-maven-profiles-in-cloud-manager

場合によっては、Cloud Manager内で実行する際に、ビルドプロセスを少し変更します。 これは、開発者ワークステーションで実行する場合とは異なります。 このような場合、Maven Profilesは、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>
NOTE
開発用ワークステーションでこのプロファイルをテストするには、(-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の品質基準によって実施される品質検査の対象にはならないため、慎重に使用する必要があります。 また、Adobeでは、Java ソースとプロジェクトのソースコード全体をバイナリと一緒にデプロイすることをお勧めします。

TIP
パスワードで保護されたMaven リポジトリのアーティファクトは、使用頻度の低いケースと、AEMに関連付けられていないコードに対してのみ使用してください。

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

例 2 example-2

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

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

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

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

オプトアウト opting-out

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

  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 に関連付けられた保存済みアーティファクトがあるので、それらのアーティファクトは再利用されます。

注意事項 caveats

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

ベストプラクティスに基づくコードの開発 develop-your-code-based-on-best-practices

アドビのエンジニアリングチームとコンサルティングチームは、AEM 開発者向けの包括的なベストプラクティスを策定しました。

recommendation-more-help
experience-manager-cloud-manager-help-main-toc