Erfahren Sie, wie Sie Ihr Projekt einrichten, damit Sie es mit Cloud Manager verwalten und bereitstellen können.
Vorhandene AEM müssen einige Grundregeln einhalten, damit sie erfolgreich mit Cloud Manager erstellt und bereitgestellt werden können.
pom.xml
im Stammverzeichnis des Git-Repositorys.
pom.xml
-Datei kann beliebig viele Untermodule (die wiederum weitere Untermodule enthalten können) enthalten.pom.xml
-Dateien hinzufügen.target
.
zip
Dateien enthielten Unterverzeichnisse von target
benannt conf
und conf.d
.In einigen wenigen Fällen müssen Sie den Build-Prozess möglicherweise etwas anders gestalten, wenn er in Cloud Manager und auf Entwickler-Workstations ausgeführt wird. In diesen Fällen können Sie mit Maven-Profilen definieren, wie der Build in verschiedenen Umgebungen (einschließlich Cloud Manager) abweichen soll.
Die Aktivierung eines Maven-Profils in der Cloud Manager-Build-Umgebung sollte durch Suchen nach CM_BUILD
Umgebungsvariable Umgebungsvariable. Beim Erstellen eines Profils, das nur außerhalb der Cloud Manager-Build-Umgebung verwendet werden soll, sollte hingegen das Nichtvorhandensein dieser Variable verifiziert werden.
Wenn zum Beispiel eine einfache Nachricht nur dann ausgegeben werden soll, wenn der Build innerhalb von Cloud Manager ausgeführt wird, verwenden Sie Folgendes:
<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>
Um dieses Profil auf einer Entwickler-Workstation zu testen, können Sie es entweder in der Befehlszeile (mit -PcmBuild
) oder in der integrierten Entwicklungsumgebung (IDE) aktivieren.
Wenn zum Beispiel eine einfache Nachricht nur dann ausgegeben werden soll, wenn der Build außerhalb von Cloud Manager ausgeführt wird, verwenden Sie Folgendes:
<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>
Artefakte aus einem kennwortgeschützten Maven-Repository sollten nur sehr vorsichtig verwendet werden, da Code, der über diesen Mechanismus bereitgestellt wird, nicht alle Qualitätsregeln durchläuft, die in den Quality Gates von Cloud Manager implementiert sind. Es wird empfohlen, neben der Binärdatei auch die Java-Quellen sowie den gesamten Projektquell-Code bereitzustellen.
Artefakte aus kennwortgeschützten Maven-Repositorys sollten nur in seltenen Fällen und für Code verwendet werden, der nicht an AEM gebunden ist.
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 <servers>
-Element in dieser Datei mit der von Cloud Manager bereitgestellten settings.xml
-Standarddatei zusammengeführt. Server-IDs, die mit adobe
und cloud-manager
beginnen, gelten als reserviert und sollten nicht von kundenspezifischen Servern verwendet werden. Server-IDs, die nicht mit einem dieser Präfixe oder der Standard-ID central
übereinstimmen, werden von Cloud Manager niemals gespiegelt.
Wenn diese Datei vorhanden ist, wird die Server-ID von innerhalb einer <repository>
und/oder <pluginRepository>
-Element innerhalb des pom.xml
-Datei. Im Allgemeinen wären diese <repository>
- und/oder <pluginRepository>
-Elemente in einem Cloud Manager-spezifischen Profil enthalten, auch wenn dies nicht unbedingt erforderlich ist.
Nehmen wir als Beispiel an, dass sich das Repository unter https://repository.myco.com/maven2
, sollte der Benutzername, den Cloud Manager verwenden sollte, lautet cloudmanager
und das Kennwort lautet 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 anschließend aus der .cloudmanager/maven/settings.xml
-Datei darauf:
<?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 auf die Server-ID in der pom.xml
-Datei:
<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>
Es empfiehlt sich, die Java-Quellen zusammen mit der Binärdatei in einem Maven-Repository bereitzustellen.
Konfigurieren Sie die 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>
Es empfiehlt sich, die gesamte Projektquelle zusammen mit der Binärdatei in einem Maven-Repository bereitzustellen. Dadurch kann das genaue Artefakt neu erstellt werden.
Konfigurieren Sie die 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>
In Cloud Manager können Builds eine beliebige Anzahl von Inhaltspaketen generieren. Aus vielerlei Gründen kann es sinnvoll sein, ein Inhaltspaket zu erstellen, es jedoch nicht bereitzustellen. Dies kann nützlich sein, etwa für Inhaltspakete, die nur zum Testen erstellt wurden, oder für Pakete, die in einem anderen Schritt im Build-Prozess (also als Unterpaket eines anderen Pakets) neu verpackt werden.
Um diese Szenarien zu berücksichtigen, sucht Cloud Manager in den Eigenschaften erstellter Inhaltspakete nach einer Eigenschaft namens cloudManagerTarget
. Wenn diese Eigenschaft auf none
, wird das Paket übersprungen und nicht bereitgestellt. Der Mechanismus zum Festlegen dieser Eigenschaft hängt davon ab, wie der Build das Inhaltspaket erzeugt. Beispiel: mit dem filevault-maven-plugin
Sie würden das Plug-in wie folgt konfigurieren:
<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 dem content-package-maven-plugin
ist ä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>
In vielen Fällen wird derselbe Code in mehreren AEM-Umgebungen bereitgestellt. Wenn festgestellt wird, dass derselbe Git-Commit in mehreren Pipeline-Ausführungen mit vollem Stapel verwendet wird, verhindert Cloud Manager, dass die Code-Basis neu erstellt wird.
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.
Beachten Sie, dass Ihr Programm über zwei Entwicklungs-Pipelines verfügt:
foo
bar
Beide Verzweigungen befinden sich auf derselben Commit-ID.
Beachten Sie, dass Ihr Programm zwei Verzweigungen hat:
foo
bar
Beide Verzweigungen haben dieselbe Commit-ID.
foo
und führt sie aus.bar
und führt sie aus.In diesem Fall wird das Artefakt von foo
für die Produktions-Pipeline wiederverwendet, da derselbe Commit-Hash erkannt wurde.
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 und die resultierenden Artefakte werden zur späteren Verwendung gespeichert, aber alle zuvor gespeicherten Artefakte werden nicht wiederverwendet. Um dieses Verhalten zu verstehen, sehen Sie sich das folgende Szenario an.
becdddb
. Die Ausführung ist erfolgreich und die resultierenden Artefakte werden gespeichert.CM_DISABLE_BUILD_REUSE
ist festgelegt.becdddb
verknüpft sind, werden sie aufgrund der Variablen CM_DISABLE_BUILD_REUSE
nicht wiederverwendet.f6ac5e6
. Die Ausführung ist erfolgreich und die resultierenden Artefakte werden gespeichert.CM_DISABLE_BUILD_REUSE
wird gelöscht.f6ac5e6
verknüpft sind, werden diese Artefakte wiederverwendet.CM_DISABLE_BUILD_REUSE
werden nicht berücksichtigt, wenn Cloud Manager zuvor erstellte Build-Artefakte wiederverwendet.Die Entwicklungs- und Beratungs-Teams von Adobe haben einen umfassenden Satz an Best Practices für AEM-Entwickler zusammengestellt.