Configuração do projeto project-setup

Saiba como os projetos do AEM são compilados no Maven e os padrões que você deve observar ao criar seu próprio projeto.

Detalhes de configuração do projeto project-setup-details

Para criar e implantar com sucesso com o Cloud Manager, os Projetos AEM precisam seguir as seguintes diretrizes:

Ativar perfis do Maven no Cloud Manager activating-maven-profiles-in-cloud-manager

Em alguns casos limitados, você varia um pouco o processo de criação ao executar no Cloud Manager, em vez de executar em estações de trabalho de desenvolvedor. Para esses casos, perfis Maven definem como a compilação difere em diferentes ambientes, incluindo o Cloud Manager.

A ativação de um perfil do Maven no ambiente de criação do Cloud Manager deve ser feita procurando a CM_BUILDvariável de ambiente. Da mesma forma, um perfil destinado a ser usado somente fora do ambiente de compilação do Cloud Manager é configurado procurando a ausência dessa variável.

Por exemplo, se você quiser gerar uma mensagem simples apenas quando a build for executada no Cloud Manager, faça o seguinte:

        <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 você quiser gerar uma mensagem simples apenas quando a build for executada fora do Cloud Manager, faça o seguinte:

        <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 um repositório Maven protegido por senha no Cloud Manager password-protected-maven-repositories

Para usar um repositório Maven protegido por senha no Cloud Manager:

Quando o processo de compilação do Cloud Manager é iniciado:

Por exemplo, suponha que o repositório esteja em https://repository.myco.com/maven2, o nome de usuário que a Cloud Manager usa seja cloudmanager e a senha seja secretword. Siga as etapas abaixo:

Implantar fontes deploying-sources

É recomendável implantar as fontes Java junto com o binário em um repositório Maven.

Para fazer isso, configure maven-source-plugin em seu projeto.

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

Implantar fontes do projeto deploying-project-sources

É recomendável implantar toda a origem do projeto junto com o binário em um repositório Maven. Isso permite reconstruir o artefato exato.

Configure o maven-assembly-plugin em seu projeto da seguinte maneira:

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

Ignorar pacotes de conteúdo skipping-content-packages

No Cloud Manager, as builds produzem qualquer número de pacotes de conteúdo. Por uma variedade de motivos, é desejável produzir um pacote de conteúdo, mas não implantá-lo. Um exemplo ocorre quando os pacotes de conteúdo são criados exclusivamente para fins de teste ou quando outra etapa do processo de criação os recompila. Ou seja, um subpacote de outro pacote.

Para acomodar esses cenários, o Cloud Manager procurará por uma propriedade chamada cloudManagerTarget nas propriedades dos pacotes de conteúdo criados. Se essa propriedade estiver definida como none, o pacote será ignorado e não será implantado.

O mecanismo para definir essa propriedade depende da forma como a compilação produz o pacote de conteúdo. Por exemplo, com o filevault-maven-plugin, você configura o plug-in da seguinte maneira.

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

O content-package-maven-plugin tem uma configuração semelhante.

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

Reutilização de artefato de compilação build-artifact-reuse

Em muitos casos, um mesmo código é implantado em vários ambientes do AEM. Sempre que possível, o Cloud Manager evitará reconstruir a base de código quando detectar que o mesmo commit do Git é usado em várias execuções de pipeline de pilha completa.

Quando uma execução é iniciada, é extraído. o commit HEAD atual do pipeline do branch (ramificação). O hash de confirmação fica visível na interface do usuário e por meio da API. Quando a etapa de criação é concluída com sucesso, os artefatos resultantes são armazenados com base nesse hash de confirmação e são reutilizados em execuções de pipeline subsequentes.

Os pacotes serão reutilizados nos pipelines, se estiverem no mesmo programa. Ao procurar pacotes que possam ser reutilizados, o AEM ignora ramificações e reutiliza artefatos entre ramificações.

Quando ocorre uma reutilização, as etapas de compilação e qualidade do código são efetivamente substituídas pelos resultados da execução original. O arquivo de log da etapa do build listará os artefatos e as informações de execução que foram usadas originalmente para criá-los.

Veja a seguir um exemplo do log gerado.

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)

O log da etapa de qualidade do código conterá informações semelhantes.

Exemplos example-reuse

Exemplo 1 example-1

Considere que seu programa tem dois pipelines de desenvolvimento:

Ambas as ramificações estão na mesma ID de confirmação.

Exemplo 2 example-2

Considere que seu programa tem duas ramificações:

Ambas as ramificações têm a mesma ID de confirmação.

Nesse caso, o artefato de foo será reutilizado para o pipeline de produção, pois o mesmo hash de commit foi identificado.

Recusar opting-out

Se desejado, o comportamento de reutilização pode ser desabilitado para pipelines específicos, definindo a variável de pipeline CM_DISABLE_BUILD_REUSE como true. Se essa variável for definida, o sistema extrairá o hash de confirmação e armazenará os artefatos resultantes para uso posterior, mas ignorará a reutilização de quaisquer artefatos armazenados anteriormente. Para entender esse comportamento, considere o seguinte exemplo:

Avisos caveats