Configurazione del progetto project-setup

Scopri come creare i progetti AEM con Maven e gli standard da osservare durante la creazione di un progetto personalizzato.

Dettagli configurazione progetto project-setup-details

Per generare e distribuire correttamente con Cloud Manager, i progetti AEM devono rispettare le seguenti linee guida:

Attivazione dei profili Maven in Cloud Manager activating-maven-profiles-in-cloud-manager

In alcuni casi limitati, potrebbe essere necessario modificare leggermente il processo di build durante l’esecuzione in Cloud Manager rispetto a quando viene eseguito dalle workstation di sviluppo. Per questi casi è possibile utilizzare i profili Maven per definire il modo in cui la build deve differire nei diversi ambienti, incluso Cloud Manager.

L’attivazione di un profilo Maven all’interno dell’ambiente di build di Cloud Manager deve essere eseguita cercando la CM_BUILD variabile di ambiente. Analogamente, per un profilo destinato a essere utilizzato esclusivamente al di fuori dell’ambiente di build di Cloud Manager, è necessario verificare l’assenza di tale variabile.

Ad esempio, se desideri inviare un messaggio semplice solo quando la build viene eseguita in Cloud Manager, effettua la seguente operazione:

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

E se desideri inviare un messaggio semplice solo quando la build viene eseguita al di fuori di Cloud Manager, effettua le seguenti operazioni:

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

Utilizzare un archivio Maven protetto da password in Cloud Manager password-protected-maven-repositories

Per utilizzare un archivio Maven protetto da password in Cloud Manager:

All’avvio del processo di build di Cloud Manager:

Supponiamo ad esempio che l’archivio si trovi nella posizione https://repository.myco.com/maven2 e che il nome utente che Cloud Manager debba utilizzare sia cloudmanager, con password secretword. Effettua le seguenti operazioni:

Distribuire le origini deploying-sources

È buona prassi distribuire le origini Java insieme ai dati binari in un archivio Maven.

Per farlo, configura il plug-in maven-source nel progetto.

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

Distribuzione delle origini del progetto deploying-project-sources

È buona prassi distribuire l’intera origine del progetto insieme ai dati binari in un archivio Maven. In questo modo è possibile ricostruire l’artefatto esatto.

Configura il maven-assembly-plugin nel progetto nel modo seguente:

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

Ignorare i pacchetti di contenuti skipping-content-packages

In Cloud Manager le build possono produrre qualsiasi numero di pacchetti di contenuti. Per diversi motivi può essere utile produrre un pacchetto di contenuti ma non distribuirlo. Un esempio si verifica quando i pacchetti di contenuti vengono generati solo a scopo di test o quando un altro passaggio del processo di build li ricompila. ovvero un pacchetto secondario di un altro pacchetto.

Per soddisfare questi scenari, Cloud Manager cerca una proprietà denominata cloudManagerTarget tra le proprietà dei pacchetti di contenuto della build. Se questa proprietà è impostata su none, il pacchetto viene ignorato e non distribuito.

Il meccanismo per impostare questa proprietà dipende dal modo in cui la build produce il pacchetto di contenuti. Ad esempio, con filevault-maven-plugin è possibile configurare il plug-in come indicato di seguito.

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

content-package-maven-plugin presenta una configurazione analoga.

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

Riutilizzo degli artefatti di generazione build-artifact-reuse

In molti casi, lo stesso codice viene distribuito in più ambienti AEM. Quando possibile, Cloud Manager evita di ricostruire la base di codice quando rileva che lo stesso commit Git viene utilizzato in più esecuzioni di pipeline full-stack.

All’avvio di un’esecuzione, viene estratto il commit HEAD corrente per la pipeline del ramo. L’hash del commit è visibile nell’interfaccia utente e tramite l’API. Al termine della fase di build, gli artefatti risultanti vengono archiviati in base a tale hash di commit e possono essere riutilizzati nelle esecuzioni successive della pipeline.

Se si trovano nello stesso programma, i pacchetti vengono riutilizzati tra le pipeline. Durante la ricerca di pacchetti da poter riutilizzare, AEM ignora i rami e riutilizza gli artefatti tra rami.

In caso di un riutilizzo, i passaggi di build e qualità del codice vengono effettivamente sostituiti con i risultati dell’esecuzione originale. Il file di registro per il passaggio di build elenca gli artefatti e le informazioni di esecuzione utilizzate per generarli originariamente.

Di seguito è riportato un esempio di tale output del registro.

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)

Il log del passaggio di qualità del codice conterrà informazioni simili.

Esempi example-reuse

Esempio 1 example-1

Ipotizza di utilizzare un programma con due pipeline di sviluppo:

Entrambi i rami presentano lo stesso ID commit.

Esempio 2 example-2

Ipotizza di utilizzare un programma con due rami:

Entrambi i rami presentano lo stesso ID commit.

In questo caso, l’artefatto da foo viene riutilizzato per la pipeline di produzione poiché è stato identificato lo stesso hash del commit.

Disattivazione opting-out

Se lo desideri, puoi disattivare il comportamento di riutilizzo per specifiche pipeline impostando la variabile di pipeline CM_DISABLE_BUILD_REUSE su true. Se questa variabile è impostata, il sistema estrae l’hash di commit e memorizza gli artefatti risultanti per un uso successivo, ma non riutilizza gli artefatti archiviati in precedenza. Per comprendere questo comportamento, considera lo scenario seguente:

Avvertenze caveats