Configuration du projet project-setup

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.

Détails de configuration du projet project-setup-details

Pour créer et déployer avec succès avec Cloud Manager, les projets AEM doivent respecter les instructions suivantes :

Activer des profils Maven dans Cloud Manager activating-maven-profiles-in-cloud-manager

Dans certains cas, vous pouvez légèrement modifier votre processus de génération lors de l’exécution dans Cloud Manager par opposition à celui exécuté sur les postes de travail des développeurs. Pour ces cas, les profils Maven définissent la manière dont la version diffère selon les environnements, y compris 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 même, un profil destiné à être utilisé uniquement en dehors de l’environnement de création Cloud Manager est configuré en vérifiant l’absence de cette variable.

Par exemple, si vous souhaitez générer un message simple uniquement lorsque la version 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>

Et si vous souhaitez générer un message simple uniquement lorsque la version est exécutée en dehors de Cloud Manager, procédez comme suit :

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

Utiliser un référentiel Maven protégé par mot de passe dans Cloud Manager password-protected-maven-repositories

Pour utiliser un référentiel Maven protégé par mot de passe dans Cloud Manager :

Lorsque le processus de création de Cloud Manager démarre :

Supposons, par exemple, que le référentiel se trouve à l’adresse https://repository.myco.com/maven2, que le nom d’utilisateur utilisé par Cloud Manager soit cloudmanager et que le mot de passe soit secretword. Procédez comme suit :

Déployer des sources deploying-sources

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>

Déployer des sources de projet deploying-project-sources

Il est recommandé de déployer l’ensemble de la source du projet avec le binaire dans un référentiel Maven. Vous pouvez ainsi reconstruire l’artefact exact.

Configurez le plug-in maven-assembly dans votre projet comme suit :

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

Ignorer les modules de contenu skipping-content-packages

Dans Cloud Manager, les versions produisent un nombre illimité de packages de contenu. Pour diverses raisons, il est préférable de produire un package de contenu, mais de ne pas le déployer. Un exemple se produit lorsque les packages de contenu sont créés uniquement à des fins de test ou lorsqu’une autre étape du processus de création les recompresse. C’est-à-dire un sous-package d’un autre package.

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 package est ignoré et n’est pas 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 configurez le plug-in comme suit.

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

Réutilisation des artefacts de build build-artifact-reuse

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 sont 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 packages 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 création répertorie les artefacts et les informations d’exécution qui ont été utilisées 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.

Exemples example-reuse

Exemple 1 example-1

Partez du principe que votre programme comporte deux pipelines de développement :

Les deux branches utilisent le même identifiant de validation.

Exemple 2 example-2

Partez du principe que votre programme comporte deux branches :

Les deux branches ont le même identifiant de validation.

Dans ce cas, l’artefact de foo est réutilisé pour le pipeline de production, car le même hachage de validation a été identifié.

Opt-out opting-out

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 système extrait le hachage de validation et stocke les artefacts obtenus pour une utilisation ultérieure, mais ignore la réutilisation des artefacts précédemment stockés. Pour comprendre ce comportement, considérez le scénario suivant :

Avertissements caveats