Configuration de votre projet setting-up-your-project

Découvrez comment configurer votre projet afin de pouvoir le gérer et le déployer avec Cloud Manager.

Modification de projets existants modifying-project-setup-details

Les projets AEM existants doivent respecter certaines règles de base afin qu’ils puissent être créés et déployés avec succès avec Cloud Manager.

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

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 être effectuée en recherchant CM_BUILD variable d’environnement. Par contre, 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 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>

Si vous souhaitez générer un message 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>

Prise en charge du référentiel Maven protégé par mot de passe password-protected-maven-repositories

Les artefacts d’un référentiel Maven protégé par mot de passe doivent être utilisés avec précaution, car le code déployé de cette manière n’est pas entièrement soumis aux contrôles de qualité appliqués par les points de contrôle qualité Cloud Manager. Adobe vous conseille également de déployer les sources Java et tout le code source du projet avec le binaire.

Pour utiliser un référentiel Maven protégé par mot de passe dans Cloud Manager, spécifiez le mot de passe (et éventuellement le nom d’utilisateur) en tant que Variable de pipeline secrète, puis référencez ce secret dans un fichier nommé .cloudmanager/maven/settings.xml dans le référentiel git. Ce fichier suit le schéma du fichier de paramètres Maven.

Lorsque le processus de création Cloud Manager démarre, l’élément <servers> de ce fichier est fusionné dans le fichier settings.xml par défaut fourni par Cloud Manager. Les serveurs personnalisés ne doivent pas utiliser d’ID de serveur commençant par adobe et cloud-manager. Ces identifiants sont considérés comme réservés. Cloud Manager ne reflète que les ID de serveur correspondant à l’un des préfixes spécifiés ou à l’ID par défaut central.

Une fois ce fichier en place, l’ID de serveur est référencé à l’intérieur d’un élément <repository> et/ou <pluginRepository> dans le fichier pom.xml. En règle générale, ces éléments <repository> et/ou <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 à 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.

Tout d’abord, définissez le mot de passe comme secret sur le pipeline :

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

Faites ensuite référence aux éléments suivants à 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>
        <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>

Déploiement de sources deploying-sources

Il est recommandé de déployer les sources Java avec le binaire dans un référentiel Maven.

Configurez le 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éploiement de sources de projet deploying-project-sources

Il est recommandé de déployer la source du projet dans son intégralité avec le binaire vers un référentiel Maven. Cela permet de reconstruire l’artefact exact.

Configurez le maven-assembly-plugin 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>

Ignorer les modules de contenu skipping-content-packages

Dans Cloud Manager, chaque compilation peut produire un certain nombre de packages de contenu. Pour diverses raisons, il peut être préférable de produire un package de contenu, mais de ne pas le déployer, Par exemple, cette approche peut s’avérer utile lorsque vous créez des modules de contenu uniquement à des fins de test ou lorsqu’une autre étape du processus de création les recompile. C'est-à-dire sous la forme d'un sous-paquet d'un autre paquet.

Pour tenir compte de ces scénarios, Cloud Manager recherche une propriété nommée cloudManagerTarget dans les propriétés des packages 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 de définition de cette propriété dépend de la manière dont la version produit le module de contenu. Par exemple, avec filevault-maven-plugin, vous configurez le module externe 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>

Avec le content-package-maven-plugin, il est 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 de l’artefact de création 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 de code lorsqu’il détecte que la même validation Git est utilisée dans plusieurs exécutions de pipeline pleine pile.

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 par le biais de 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 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és pour les créer initialement.

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

Supposons que votre programme comporte deux branches : Branche foo et Branche bar.

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

Se désabonner 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 hachage de validation est toujours extrait. Les artefacts ainsi obtenus sont stockés pour une utilisation ultérieure, mais aucun artefact précédemment stocké n’est réutilisé. Pour comprendre ce comportement, envisagez le scénario suivant :

Restrictions caveats

Développez votre code en fonction des bonnes pratiques develop-your-code-based-on-best-practices

Les équipes d’ingénierie et de conseil Adobe ont développé un ensemble complet de bonnes pratiques pour les développeurs AEM.