Découvrez comment les projets AEM sont créés avec Maven et les normes que vous devez respecter lors de la création de votre propre projet.
Pour pouvoir être créés et déployés dans Cloud Manager, les projets AEM doivent se conformer à ces directives :
pom.xml
doit se trouver à la racine du référentiel Git. Ce fichier pom.xml
peut faire référence à autant de sous-modules (qui, à leur tour, peuvent comporter d’autres sous-modules, etc.) que nécessaire.pom.xml
.
.zip
de package de contenu se trouvant dans un répertoire appelé target
.
.zip
(également contenus dans le répertoire appelé target
) dont les répertoires sont appelés conf
et conf.d
.Dans certains cas, vous devrez peut-être légèrement modifier le processus de génération lors de l’exécution dans Cloud Manager, contrairement à celui qui s’exécute sur les postes de travail des développeurs. Dans ce cas, les profils Maven peuvent être utilisés pour définir la manière dont la génération doit être différente dans différents environnements, notamment Cloud Manager.
L’activation d’un profil Maven dans l’environnement de génération Cloud Manager doit se faire en recherchant la présence de la variable d’environnement CM_BUILD
. De la même manière, un profil destiné à être utilisé uniquement en dehors de l’environnement de création Cloud Manager doit être généré en vérifiant l’absence de cette variable.
Par exemple, si vous souhaitez générer un message de sortie simple uniquement lorsque la génération est exécutée dans Cloud Manager, procédez comme suit.
<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>
Pour tester ce profil sur un poste de travail de développeur, vous pouvez l’activer sur la ligne de commande (avec -PcmBuild
) ou dans l’environnement de développement intégré (IDE).
Si vous souhaitez générer un message de sortie simple uniquement lorsque la génération est exécutée en dehors de Cloud Manager, procédez comme suit.
<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>
Les artefacts d’un référentiel Maven protégé par mot de passe ne doivent être utilisés que très prudemment, car le code déployé par ce mécanisme ne passe actuellement pas par les règles de qualité de code intégrées aux points de contrôle de qualité de Cloud Manager. Par conséquent, ce mécanisme ne devrait être utilisé que dans de rares cas et pour le code non lié à AEM. Il est conseillé de déployer les sources Java ainsi que l’ensemble du code source du projet avec le binaire.
Pour utiliser un référentiel Maven protégé par mot de passe dans Cloud Manager :
.cloudmanager/maven/settings.xml
dans le référentiel git, qui suit le schéma du fichier des paramètres Maven.Lorsque le processus de création de Cloud Manager démarre :
<servers>
dans ce fichier sera fusionné dans le fichier settings.xml
par défaut fourni par Cloud Manager.
adobe
et cloud-manager
sont considérés comme réservés et ne doivent pas être utilisés par des serveurs personnalisés.central
ne seront jamais mis en miroir par Cloud Manager.<repository>
et <pluginRepository>
dans le fichier pom.xml
.<repository>
et <pluginRepository>
sont contenus dans un profil spécifique à Cloud Manager, bien que cela ne soit pas strictement nécessaire.Par exemple, supposons que le référentiel se trouve à l’adresse https://repository.myco.com/maven2
, que le nom d’utilisateur que Cloud Manager doit utiliser soit cloudmanager
et que le mot de passe soit secretword
. Procédez comme suit.
Définissez le mot de passe comme secret sur le pipeline.
$ aio cloudmanager:set-pipeline-variables PIPELINEID --secret CUSTOM_MYCO_REPOSITORY_PASSWORD secretword`
Établissez ensuite la référence à partir du fichier .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>
Enfin, référencez l’identifiant du serveur dans le fichier pom.xml
:
<profiles>
<profile>
<id>cmBuild</id>
<activation>
<property>
<name>env.CM_BUILD</name>
</property>
</activation>
<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>
</profile>
</profiles>
Il est recommandé de déployer les sources Java avec le binaire dans un référentiel Maven.
Pour ce faire, configurez le plug-in maven-source-plugin dans votre projet.
<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>
Il est recommandé de déployer la source du projet dans son intégralité avec le binaire dans un référentiel Maven, ce qui permet de reconstruire l’artefact exact.
Pour ce faire, configurez le plug-in maven-assembly dans votre projet.
<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>
Dans Cloud Manager, chaque build peut produire un certain nombre de modules de contenu. Pour diverses raisons, il peut être préférable de produire un module de contenu, mais de ne pas le déployer, par exemple, lors de la création de modules de contenu utilisés uniquement à des fins de test ou qui seront recompilés lors d’une autre étape du processus de build, c’est-à-dire sous la forme d’un sous-module d’un autre module.
Pour tenir compte de ces scénarios, Cloud Manager recherche une propriété nommée cloudManagerTarget
dans les propriétés des modules de contenu créés. Si cette propriété est définie sur none
, le module sera ignoré et non déployé.
Le mécanisme permettant de définir cette propriété dépend de la manière dont le build produit le module de contenu. Par exemple, avec le filevault-maven-plugin
, vous devez configurer le plug-in de la manière suivante.
<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>
Le content-package-maven-plugin
a une configuration similaire.
<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>
Dans de nombreux cas, le même code est déployé dans plusieurs environnements AEM. Dans la mesure du possible, Cloud Manager évite de reconstruire la base du code lorsqu’il détecte que la même validation Git est utilisée dans plusieurs exécutions de pipelines de piles pleines.
Lorsqu’une exécution est lancée, la validation HEAD en cours pour le pipeline de branche est extraite. Le hachage de validation est visible dans l’interface utilisateur et via l’API. Une fois l’étape de build terminée, les artefacts obtenus sont stockés en fonction de ce hachage de validation et peuvent être réutilisés dans les exécutions ultérieures du pipeline.
Les packages sont réutilisés sur plusieurs pipelines s’ils se trouvent dans le même programme. Lorsque vous recherchez des modules qui peuvent être réutilisés, AEM ignore les branches et réutilise les artefacts entre les branches.
En cas de réutilisation, les étapes de build et de qualité du code sont effectivement remplacées par les résultats de l’exécution initiale. Le fichier journal de l’étape de build répertorie les artefacts et les informations d’exécution qui ont été utilisés pour les créer à lʼorigine.
Voici un exemple dʼune telle sortie de journal.
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)
Le journal de l’étape de qualité du code contient des informations similaires.
Partez du principe que votre programme comporte deux pipelines de développement :
foo
bar
Les deux branches utilisent le même identifiant de validation.
Partez du principe que votre programme comporte deux branches :
foo
bar
Les deux branches ont le même identifiant de validation.
foo
.bar
.Dans ce cas, l’artefact de foo
sera réutilisé pour le pipeline de production, car le même hachage de validation a été identifié.
Si vous le souhaitez, le comportement de réutilisation peut être désactivé pour des pipelines spécifiques en définissant la variable de pipeline CM_DISABLE_BUILD_REUSE
sur true
. Si cette variable est définie, le hachage de validation est toujours extrait et les artefacts obtenus sont stockés pour une utilisation ultérieure, mais les artefacts précédemment stockés ne seront pas réutilisés. Pour comprendre ce comportement, considérez le scénario suivant.
becdddb
. L’exécution est réussie et les artefacts obtenus sont stockés.CM_DISABLE_BUILD_REUSE
est définie.becdddb
, ils ne sont pas réutilisés en raison de la variable CM_DISABLE_BUILD_REUSE
.f6ac5e6
. L’exécution est réussie et les artefacts obtenus sont stockés.CM_DISABLE_BUILD_REUSE
est supprimée.f6ac5e6
, ces artefacts sont réutilisés.CM_DISABLE_BUILD_REUSE
ne sont pas prises en compte lorsque Cloud Manager décide de réutiliser des artefacts de build créés précédemment.