Projekt-Setup project-setup

Erfahren Sie, wie AEM-Projekte mit Maven erstellt werden und welche Standards Sie bei der Erstellung eigener Projekte einhalten müssen.

Details zur Projekteinstellung project-setup-details

Um mit Cloud Manager erfolgreich Projekte zu erstellen und bereitzustellen, müssen AEM-Projekte den folgenden Richtlinien entsprechen:

Aktivieren von Maven-Profilen in Cloud Manager activating-maven-profiles-in-cloud-manager

In einigen wenigen Fällen variieren Sie den Build-Prozess geringfügig, wenn er innerhalb von Cloud Manager und nicht auf Entwickler-Workstations ausgeführt wird. Für diese Fälle definieren Maven-Profile wie sich der Build in verschiedenen Umgebungen, einschließlich Cloud Manager, unterscheidet.

Die Aktivierung eines Maven-Profils innerhalb der Cloud Manager-Build-Umgebung sollte durch die Suche nach der Umgebungsvariablen CM_BUILD erfolgen. Ebenso wird ein Profil, das nur außerhalb der Cloud Manager-Build-Umgebung verwendet werden soll, konfiguriert, indem darauf geachtet wird, dass diese Variable nicht vorhanden ist.

Wenn Sie beispielsweise eine einfache Meldung nur dann ausgeben möchten, wenn der Build in Cloud Manager ausgeführt wird, führen Sie die folgenden Schritte aus:

        <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>

Wenn Sie eine einfache Meldung nur dann ausgeben möchten, wenn der Build außerhalb von Cloud Manager ausgeführt wird, gehen Sie wie folgt vor:

        <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>

Verwenden eines kennwortgeschützten Maven-Repositorys in Cloud Manager password-protected-maven-repositories

So verwenden Sie ein kennwortgeschütztes Maven-Repository in Cloud Manager:

Wenn der Build-Prozess von Cloud Manager gestartet wird:

Angenommen, das Repository befindet sich auf https://repository.myco.com/maven2, der von Cloud Manager verwendete Benutzername ist cloudmanager und das Kennwort ist secretword. Gehen Sie wie folgt vor:

Bereitstellen von Quellen deploying-sources

Es wird empfohlen, die Java-Quellen zusammen mit der Binärdatei in einem Maven-Repository bereitzustellen.

Konfigurieren Sie dazu das Maven-Source-Plug-in in Ihrem Projekt.

         <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>

Bereitstellen von Projektquellen deploying-project-sources

Es wird empfohlen, die gesamte Projektquelle zusammen mit der Binärdatei in einem Maven-Repository bereitzustellen. Auf diese Weise können Sie das genaue Artefakt neu erstellen.

Konfigurieren Sie das maven-assembly-plugin in Ihrem Projekt wie folgt:

         <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>

Überspringen von Inhaltspaketen skipping-content-packages

In Cloud Manager erzeugen Builds eine beliebige Anzahl von Inhaltspaketen. Aus verschiedenen Gründen ist es wünschenswert, ein Inhaltspaket zu erstellen, es jedoch nicht bereitzustellen. Ein Beispiel wäre etwa, wenn Inhaltspakete ausschließlich zum Testen erstellt oder wenn diese durch einen anderen Schritt im Build-Prozess neu verpackt werden. Das heißt, sie werden ein Unterpaket eines anderen Pakets.

Um diesen Szenarien gerecht zu werden, sucht Cloud Manager in den Eigenschaften erstellter Inhaltspakete nach einer Eigenschaft namens cloudManagerTarget. Wenn diese Eigenschaft auf none festgelegt ist, wird das Paket übersprungen und nicht bereitgestellt.

Der Mechanismus zum Festlegen dieser Eigenschaft hängt davon ab, wie der Build das Inhaltspaket erzeugt. Mit dem filevault-maven-plugin konfigurieren Sie beispielsweise das Plug-in wie folgt.

        <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>

Das content-package-maven-plugin weist eine ähnliche Konfiguration auf.

        <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>

Wiederverwendung von Build-Artefakten build-artifact-reuse

In vielen Fällen wird derselbe Code in mehreren AEM-Umgebungen bereitgestellt. Wenn festgestellt wird, dass derselbe Git-Commit in mehreren Full-Stack-Pipeline-Ausführungen verwendet wird, verhindert Cloud Manager nach Möglichkeit eine Neuerstellung der Code-Basis.

Wenn eine Ausführung gestartet wird, wird der aktuelle HEAD-Commit für die Zweig-Pipeline extrahiert. Der Commit-Hash ist in der Benutzeroberfläche und über die API sichtbar. Wenn der Build-Schritt erfolgreich abgeschlossen wurde, werden die resultierenden Artefakte basierend auf diesem Commit-Hash gespeichert und in nachfolgenden Pipeline-Ausführungen wiederverwendet.

Pakete werden in allen Pipelines wiederverwendet, wenn sie sich im selben Programm befinden. Bei der Suche nach Paketen, die wiederverwendet werden können, ignoriert AEM Verzweigungen und verwendet Artefakte in allen Verzweigungen wieder.

Wenn eine Wiederverwendung erfolgt, werden die Build- und Code-Qualitätsschritte effektiv durch die Ergebnisse der ursprünglichen Ausführung ersetzt. In der Protokolldatei für den Build-Schritt werden die Artefakte und die Ausführungsinformationen aufgelistet, die ursprünglich zum Erstellen verwendet wurden.

Im Folgenden finden Sie ein Beispiel für eine solche Protokollausgabe.

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)

Das Protokoll des Code-Qualitätsschritts enthält ähnliche Informationen.

Beispiele example-reuse

Beispiel 1 example-1

Beachten Sie, dass Ihr Programm über zwei Entwicklungs-Pipelines verfügt:

Beide Verzweigungen befinden sich auf derselben Commit-ID.

Beispiel 2 example-2

Beachten Sie, dass Ihr Programm zwei Verzweigungen hat:

Beide Verzweigungen haben dieselbe Commit-ID.

In diesem Fall wird das Artefakt von foo für die Produktions-Pipeline wiederverwendet, da derselbe Commit-Hash erkannt wurde.

Opt-out opting-out

Falls gewünscht, kann das Wiederverwendungsverhalten für bestimmte Pipelines deaktiviert werden, indem die Pipeline-Variable CM_DISABLE_BUILD_REUSE auf true festgelegt wird. Wenn diese Variable festgelegt ist, extrahiert das System den Commit-Hash und speichert die resultierenden Artefakte zur späteren Verwendung, verzichtet allerdings auf eine Wiederverwendung aller zuvor gespeicherten Artefakte. Um dieses Verhalten zu verstehen, sehen Sie sich das folgende Szenario an.

Einschränkungen caveats