Configuración del proyecto project-setup

Descubra cómo se crean los proyectos de AEM con Maven y los estándares que debe observar al crear su propio proyecto.

Detalles de configuración del proyecto project-setup-details

Para generar e implementar proyectos correctamente con Cloud Manager, AEM debe cumplir las siguientes directrices:

Activación de perfiles de Maven en Cloud Manager activating-maven-profiles-in-cloud-manager

En algunos casos limitados, el proceso de generación varía ligeramente al ejecutarse dentro de Cloud Manager, en lugar de hacerlo en las estaciones de trabajo de los desarrolladores. Para estos casos, los perfiles de Maven definen las diferencias de compilación en diferentes entornos, incluido Cloud Manager.

La activación de un perfil de Maven dentro del entorno de generación de Cloud Manager debe realizarse al buscar la CM_BUILD variable de entorno. Del mismo modo, un perfil que se vaya a usar solamente fuera del entorno de compilación de Cloud Manager se configura buscando la ausencia de esta variable.

Por ejemplo, si desea que salga un mensaje simple cuando la generación se ejecuta solamente dentro de Cloud Manager, haga lo siguiente:

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

Y si desea que salga un mensaje simple cuando la generación se ejecuta solamente fuera de Cloud Manager, haga lo siguiente:

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

Usar un repositorio Maven protegido por contraseña en Cloud Manager password-protected-maven-repositories

Para usar un repositorio Maven protegido por contraseña en Cloud Manager:

Cuando se inicia el proceso de generación de Cloud Manager:

Por ejemplo, suponga que el repositorio se encuentra en https://repository.myco.com/maven2, que el nombre de usuario que utiliza Cloud Manager es cloudmanager y que la contraseña es secretword. Siga estos pasos:

Implementación de fuentes deploying-sources

Se recomienda implementar las fuentes Java junto con el binario en un repositorio Maven.

Para ello, configure el complemento maven-source-plugin en su proyecto.

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

Implementación de fuentes de proyecto deploying-project-sources

Se recomienda implementar todo el origen del proyecto junto con el binario en un repositorio Maven. Al hacerlo, puede reconstruir el artefacto exacto.

Configure el complemento maven-assembly-plugin en su proyecto de la siguiente manera:

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

Omitir paquetes de contenido skipping-content-packages

En Cloud Manager, las compilaciones producen cualquier cantidad de paquetes de contenido. Por varios motivos, es deseable producir un paquete de contenido, pero no implementarlo. Un ejemplo ocurre cuando los paquetes de contenido se crean únicamente con fines de prueba o cuando otro paso en el proceso de compilación los vuelve a empaquetar. Es decir, un subpaquete de otro paquete.

Para dar cabida a estos escenarios, Cloud Manager busca una propiedad denominada cloudManagerTarget en las propiedades de los paquetes de contenido creados. Si esta propiedad se establece en none, el paquete se omite y no se implementa.

El mecanismo para establecer esta propiedad depende de la forma en que la generación produce el paquete de contenido. Por ejemplo, con filevault-maven-plugin puede configurar el complemento de la siguiente manera.

        <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 tiene una configuración similar.

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

Generar reutilización de artefactos build-artifact-reuse

En muchos casos, el mismo código se implementa en varios entornos de AEM. Cuando sea posible, Cloud Manager evita la reconstrucción del código base cuando detecte que se utiliza la misma confirmación de Git en varias ejecuciones de canalización full-stack.

Cuando se inicia una ejecución, se extrae el compromiso de HEAD actual para la canalización de ramas. El hash de compromiso se puede ver en la interfaz de usuario y a través de la API. Cuando el paso de generación se completa correctamente, los artefactos resultantes se almacenan en función de ese hash de compromiso y se reutilizan en ejecuciones de canalización posteriores.

Los paquetes se reutilizan en todas las canalizaciones si están en el mismo programa. Al buscar paquetes que puedan reutilizarse, AEM ignora las ramas y vuelve a utilizar artefactos a través de las ramas.

Cuando se produce una reutilización, los pasos de generación y calidad del código se sustituyen eficazmente por los resultados de la ejecución original. El archivo de registro para el paso de compilación enumera los artefactos y la información de ejecución que se utilizó para compilarlos originalmente.

El siguiente es un ejemplo de este resultado de 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)

El registro del paso de calidad del código contiene información similar.

Ejemplos example-reuse

Ejemplo 1 example-1

Imagine que su programa tiene dos canalizaciones de desarrollo:

Ambas ramas están en el mismo Id. de compromiso.

Ejemplo 2 example-2

Imagine que el programa tiene dos ramas:

Ambas ramas tienen el mismo Id. de compromiso.

En este caso, el artefacto de foo se reutiliza para la canalización de producción, ya que se identificó el mismo hash de compromiso.

Exclusión opting-out

Si lo desea, el comportamiento de reutilización se puede deshabilitar para canalizaciones específicas si configura la variable de canalización CM_DISABLE_BUILD_REUSE a true. Si se establece esta variable, el sistema extrae el hash de compromiso y almacena los artefactos resultantes para su uso posterior, pero omite la reutilización de los artefactos almacenados anteriormente. Para comprender este comportamiento, imagine el siguiente escenario.

Advertencias caveats