Einrichten eines Projekts setting-up-your-project

Erfahren Sie, wie Sie Ihr Projekt einrichten, damit Sie es mit Cloud Manager verwalten und bereitstellen können.

Bearbeiten vorhandener Projekte modifying-project-setup-details

Vorhandene AEM-Projekte müssen bestimmte Grundregeln einhalten, damit sie erfolgreich mit Cloud Manager erstellt und bereitgestellt werden können.

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

In einigen wenigen Fällen können Sie den Build-Prozess beim Ausführen in Cloud Manager geringfügig ändern. Dies unterscheidet sich von der Ausführung auf Entwickler-Workstations. In diesen Fällen 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 CM_BUILDUmgebungsvariable​ erfolgen. Umgekehrt sollte ein Profil, das nur außerhalb der Cloud Manager-Build-Umgebung verwendet werden soll, aktiviert werden, 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>!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>

Unterstützung für kennwortgeschützte Maven-Repositorys password-protected-maven-repositories

Artefakte aus einem passwortgeschützten Maven-Repository sollten mit Vorsicht verwendet werden, da Code, der auf diese Weise bereitgestellt wird, nicht vollständig den Qualitätsprüfungen unterliegt, die von den Cloud Manager-Qualitätsstandards durchgesetzt werden. Adobe empfiehlt außerdem, die Java-Quellen und den gesamten Projektquell-Code zusammen mit der Binärdatei bereitzustellen.

Um ein kennwortgeschütztes Maven-Repository aus Cloud Manager zu verwenden, geben Sie das Kennwort (und optional den Benutzernamen) als geheime Pipeline-Variable an und verweisen Sie dann in einer Datei im Git-Repository mit dem Namen .cloudmanager/maven/settings.xml auf dieses Geheimnis. Diese Datei folgt dem Schema der Maven-Einstellungsdatei.

Wenn der Build-Vorgang von Cloud Manager gestartet wird, wird das Element <servers> in dieser Datei mit der von Cloud Manager bereitgestellten Standarddatei settings.xml zusammengeführt. Benutzerdefinierte Server verwenden Server-IDs, die nicht mit adobe oder cloud-manager beginnen. Solche IDs werden als reserviert betrachtet. Cloud Manager spiegelt nur die Server-IDs wider, die mit einem der angegebenen Präfixe oder der standardmäßigen ID central übereinstimmen.

Wenn diese Datei vorhanden ist, wird die Server-ID von innerhalb eines <repository> und/oder <pluginRepository> Elements in der pom.xml referenziert. Diese <repository>- und/oder <pluginRepository> sind in einem Cloud Manager-spezifischen Profil enthalten obwohl dies nicht unbedingt erforderlich ist.

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

Legen Sie zunächst in der Pipeline das Kennwort als Geheimnis fest:

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

Verweisen Sie dann über die Datei .cloudmanager/maven/settings.xml auf Folgendes:

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

Verweisen Sie schließlich in der Datei pom.xml auf die Server-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>

Bereitstellen von Quellen deploying-sources

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

Konfigurieren Sie das maven-source-plugin 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 empfiehlt sich, den gesamten Quell-Code des Projekts zusammen mit der Binärdatei in einem Maven-Repository bereitzustellen. Dadurch kann das genaue Artefakt neu erstellt werden.

Konfigurieren Sie das maven-assembly-plugin in Ihrem Projekt.

        <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 können Builds eine beliebige Anzahl von Inhaltspaketen generieren. Aus verschiedenen Gründen kann es wünschenswert sein, ein Inhaltspaket zu erstellen, es jedoch nicht bereitzustellen. Dieser Ansatz kann beispielsweise nützlich sein, wenn Sie Inhaltspakete ausschließlich zum Testen erstellen oder wenn diese durch einen anderen Schritt im Build-Prozess neu verpackt werden. Das heißt, sie werden zum 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 das Plug-in beispielsweise 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>

Mit content-package-maven-plugin ist es ähnlich:

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

Wiederverwenden 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 können in nachfolgenden Pipeline-Ausführungen wiederverwendet werden.

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 über zwei Verzweigungen verfügt: die Verzweigung foo und die Verzweigung bar.

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, wird der Commit-Hash weiterhin extrahiert. Die resultierenden Artefakte werden zur späteren Verwendung gespeichert, aber zuvor gespeicherte Artefakte werden nicht wiederverwendet. Um dieses Verhalten zu verstehen, sehen Sie sich das folgende Szenario an.

Einschränkungen caveats

Entwickeln von Code anhand von Best Practices develop-your-code-based-on-best-practices

Die Entwicklungs- und Beratungs-Teams von Adobe haben einen umfassenden Satz an Best Practices für AEM-Entwickelnde zusammengestellt.