Os fundamentos do desenvolvimento de código são semelhantes no AEM as a Cloud Service em comparação às soluções locais do AEM e Managed Services. Os desenvolvedores criam o código e o testam localmente, e depois o enviam para ambientes remotos do AEM as a Cloud Service. O uso do Cloud Manager, que era uma ferramenta opcional de entrega de conteúdo do Managed Services, é obrigatório. Esse agora é o único mecanismo para implantar código AEM ambientes de desenvolvimento, estágio e produção as a Cloud Service. Para validação e depuração rápidas de recursos antes da implantação dos ambientes mencionados anteriormente, o código pode ser sincronizado de um ambiente local para um Ambiente de desenvolvimento rápido.
A atualização da versão do AEM é sempre um evento de implantação separado do envio de código personalizado. Visto de outra maneira, as versões de código personalizado devem ser testadas em relação à versão do AEM que está em produção, pois é nela que o código será implantado. As atualizações frequentes da versão do AEM que ocorrem depois disso são aplicadas automaticamente. Elas são feitas para serem compatíveis com versões anteriores do código do cliente já implantado.
O resto deste documento descreverá como os desenvolvedores devem adaptar suas práticas para que possam trabalhar com as atualizações da versão do AEM as a Cloud Service e as atualizações do cliente.
Para soluções anteriores do AEM, a versão mais recente era alterada com pouca frequência (geralmente de forma anual com pacotes de serviços trimestrais) e os clientes atualizavam as instâncias de produção para o Quickstart mais recente no seu próprio ritmo, referenciando o Jar da API. No entanto, os aplicativos do AEM as a Cloud Service são atualizados automaticamente para a versão mais recente com mais frequência, portanto, o código personalizado para versões internas deve ser criado baseado na versão mais recente do AEM.
Assim como nas versões fora da nuvem do AEM já existentes, haverá suporte para um desenvolvimento local e offline com base em um Quickstart específico, e essa deve ser a ferramenta preferencial para depuração na maioria dos casos.
Existem algumas diferenças operacionais sutis entre a maneira como o aplicativo funciona em um computador local comparado à Adobe Cloud. Essas diferenças de arquitetura devem ser respeitadas durante o desenvolvimento local e podem resultar em um comportamento diferente ao implantar na infraestrutura em nuvem. Devido a essas diferenças, é importante executar testes exaustivos nos ambientes de desenvolvimento e de preparo antes de implantar o novo código personalizado na produção.
Para desenvolver um código personalizado para uma versão interna, a versão relevante do SDK do AEM as a Cloud Service deve ser baixada e instalada. Para obter informações adicionais sobre o uso das ferramentas do Dispatcher do AEM as a Cloud Service, consulte esta página.
O vídeo a seguir fornece uma visão geral de alto nível sobre como implantar código no AEM as a Cloud Service:
Os clientes implantam código personalizado em ambientes na nuvem por meio do Cloud Manager. Observe que o Cloud Manager transforma pacotes de conteúdo montados localmente em um artefato em conformidade com o modelo de recurso do Sling, que é a forma como um aplicativo do AEM as a Cloud Service é descrito ao ser executado em um ambiente na nuvem. Como resultado, ao examinar os pacotes do Gerenciador de pacotes em ambientes na nuvem, o nome incluirá “cp2fm” e os pacotes transformados terão todos os metadados removidos. Não é possível interagir com eles, o que significa que não podem ser baixados, replicados ou abertos. A documentação detalhada sobre o conversor pode ser encontrada aqui.
Os pacotes de conteúdo criados para aplicativos do AEM as a Cloud Service devem ter uma separação clara entre conteúdo imutável e mutável (o Cloud Manager só instalará o conteúdo mutável), além de exibir uma mensagem como:
Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type
O resto desta seção descreverá a composição e as implicações dos pacotes imutáveis e mutáveis.
Todo conteúdo e código persistente no repositório imutável deve ser verificado no Git e implantado por meio do Cloud Manager. Em outras palavras, ao contrário das soluções atuais do AEM, o código nunca é implantado diretamente em uma instância em execução do AEM. Isso garante que o código executado para uma determinada versão seja idêntico em qualquer ambiente da nuvem, o que elimina o risco de uma variação não intencional do código na produção. Como exemplo, a configuração do OSGI deve ser enviada para o controle de origem em vez de ser gerenciada no tempo de execução por meio do gerenciador de configuração do console da web do AEM.
À medida que o aplicativo muda devido ao padrão de implantação azul-verde ativado por um botão, ele não pode depender de alterações no repositório mutável, com exceção de alterações nos usuários de serviço, seus ACLs, tipos de nó e definições de índice.
Para clientes com bases de código já existentes, é muito importante realizar o exercício de reestruturação de repositório descrito na documentação do AEM para garantir que o conteúdo anteriormente contido em /etc seja movido para o local correto.
Algumas restrições adicionais se aplicam a esses pacotes de código, por exemplo, instalar ganchos não é permitido.
Como mencionado acima, a configuração do OSGI deve ser confirmada pelo controle de origem em vez do console da web. As técnicas para fazer isso incluem:
Leia mais sobre a configuração do OSGI em Configuração do OSGi para o AEM as a Cloud Service.
Em alguns casos, pode ser útil preparar as alterações de conteúdo no controle de origem para que elas possam ser implantadas pelo Cloud Manager sempre que um ambiente for atualizado. Por exemplo, pode ser razoável implantar determinadas estruturas de pastas raiz ou alinhar alterações em modelos editáveis a fim de ativar políticas para componentes que foram atualizados pela implantação do aplicativo.
Há duas estratégias para descrever o conteúdo que será implantado pelo Cloud Manager no repositório mutável: pacotes de conteúdo mutáveis e instruções repoinit.
Conteúdos como hierarquias de caminho de pasta, usuários de serviço e controles de acesso (ACLs) normalmente são confirmados em um projeto do AEM baseado no arquétipo Maven. As técnicas incluem exportar do AEM ou gravar diretamente como XML. Durante o processo de criação e implantação, o Cloud Manager compacta o pacote de conteúdo mutável resultante. O conteúdo mutável é instalado em 3 momentos diferentes durante a fase de implantação no pipeline:
Antes da inicialização da nova versão do aplicativo:
Durante a inicialização da nova versão do aplicativo, mas antes da mudança:
Após a mudança para a nova versão do aplicativo:
/conf
) (adicionar, modificar, remover)É possível limitar a instalação de conteúdo mutável para criar ou publicar incorporando pacotes em uma pasta install.author ou install.publish sob /apps
. A reestruturação para refletir esta separação foi efetuada no AEM 6.5 e os detalhes sobre a reestruturação de projetos recomendada podem ser encontrados na documentação do AEM 6.5.
Os pacotes de conteúdo são implantados em todos os tipos de ambiente (desenvolvimento, preparo, produção). Não é possível limitar a implantação a um ambiente específico. Esta limitação está em vigor para garantir a opção de uma execução de teste automatizada. Conteúdos que são específicos a um ambiente necessitam de instalação manual por meio do Gerenciador de pacotes.
Além disso, não há mecanismo para reverter as alterações no pacote de conteúdo mutável depois de terem sido aplicadas. Se os clientes detectarem um problema, poderão optar por corrigi-lo na próxima versão do código ou, como último recurso, restaurar o sistema inteiro para um determinado estado antes da implantação.
Qualquer pacote de terceiros incluído deve ser validado como sendo compatível com o AEM as a Cloud Service, caso contrário, sua inclusão resultará em uma falha de implantação.
Como mencionado acima, os clientes com bases de código existentes devem estar em conformidade com o exercício de reestruturação do repositório exigido de acordo com as alterações da versão 6.5 do repositório, descritas na documentação do AEM 6.5.
Nos casos a seguir, é preferível adotar a abordagem de codificação manual para criação de conteúdo explícito com instruções repoinit
em configurações de fábrica do OSGI:
Criar/excluir/desativar usuários do serviço
Criar/excluir grupos
Criar/excluir usuários
Adicionar ACLs
A definição de ACLs requer que as estruturas de nó já estejam presentes. Portanto, talvez sejam necessárias instruções de criação de caminho anteriores.
Adicionar caminho (por exemplo, para estruturas de pasta raiz)
Adicionar CNDs (definições de tipo de nó)
O repoinit é recomendado nesses casos de uso de modificação de conteúdo compatíveis devido aos seguintes benefícios:
Quando o Cloud Manager implanta o aplicativo, ele executa essas instruções, independentemente da instalação de qualquer pacote de conteúdo.
Para criar instruções repoinit, siga o procedimento abaixo:
org.apache.sling.jcr.repoinit.RepositoryInitializer
em uma pasta de configuração do projeto. Use um nome descritivo para a configuração, como org.apache.sling.jcr.repoinit.RepositoryInitializer~initstructure./content
antes de /content/myfolder
, antes de /content/myfolder/mysubfolder
. Para ACLs configuradas em estruturas de baixo nível, é recomendável defini-las em um nível superior e trabalhar com uma restrição rep:glob
. Por exemplo, (allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs))
.Para ACLs definidas para nós abaixo de /apps
ou /libs
a execução repoinit será iniciada em um repositório em branco. Os pacotes são instalados após o repoinit, portanto, as instruções não podem depender de nada definido nos pacotes, mas devem definir as pré-condições como as estruturas principais abaixo.
Para ACLs, a criação de estruturas profundas pode ser complicada, portanto, é mais razoável definir uma ACL em um nível superior e restringir onde ela deve atuar por meio de uma restrição rep:glob.
Mais detalhes sobre o repoinit podem ser encontrados na Documentação do Sling
Há casos de uso em que um pacote de conteúdo deve ser instalado como “único”. Por exemplo, importação de conteúdo específico da produção para o preparo a fim de depurar um problema de produção. Para esses cenários, o Gerenciador de pacotes pode ser usado em ambientes do AEM as a Cloud Service.
Como o Gerenciador de pacotes é um conceito de tempo de execução, não é possível instalar conteúdo ou código no repositório invariável, portanto, esses pacotes de conteúdo devem ter apenas conteúdo variável (principalmente /content
ou /conf
). Se o pacote de conteúdo incluir conteúdo misto (conteúdo variável e invariável), somente o conteúdo variável será instalado.
A interface do Gerenciador de pacotes pode retornar uma mensagem de erro indefinida se um pacote levar mais de 10 minutos para ser instalado.
Isso não acontece devido a um erro na instalação, mas a um tempo limite que o Cloud Service tem para todas as solicitações.
Não repita a instalação se esse erro aparecer. A instalação está ocorrendo corretamente em segundo plano. Se você reiniciar a instalação, alguns conflitos poderão ser introduzidos por vários processos de importação simultâneos.
Todos os pacotes de conteúdo instalados pelo Cloud Manager (variáveis e invariáveis) aparecerão em um estado congelado na interface do Gerenciador de pacotes do AEM. Esses pacotes não podem ser reinstalados, recriados ou até mesmo baixados e serão listados com um sufixo “cp2fm”, indicando que a instalação foi gerenciada pelo Cloud Manager.
É comum que os clientes incluam pacotes pré-criados de fornecedores de software de terceiros, como parceiros de tradução da Adobe. A recomendação é hospedar esses pacotes em um repositório remoto e referenciá-los no pom.xml
. Isso é possível para repositórios públicos e também para repositórios privados com proteção por senha, conforme descrito em repositórios maven protegidos por senha.
Se não for possível armazenar o pacote em um repositório remoto, os clientes poderão colocá-lo em um repositório Maven local baseado em sistema de arquivos, que é confirmado no SCM como parte do projeto e referenciado pelo que depender dele. O repositório seria declarado no pom do projeto, conforme ilustrado abaixo:
<repository>
<id>project.local</id>
<name>project</name>
<url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>
Quaisquer pacotes de terceiros incluídos devem estar em conformidade com as diretrizes de codificação e empacotamento do AEM as a Cloud Service descritas neste artigo; caso contrário, a inclusão resultará em uma falha de implantação.
O snippet POM.xml
do Maven a seguir mostra como os pacotes de terceiros podem ser incorporados ao pacote “Container” do projeto, normalmente denominado “todos”, por meio da configuração do plug-in filevault-package-maven-plugin do Maven.
...
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
...
<embeddeds>
...
<!-- Include any other extra packages -->
<embedded>
<groupId>com.vendor.x</groupId>
<artifactId>vendor.plug-in.all</artifactId>
<type>zip</type>
<target>/apps/vendor-packages/container/install</target>
</embedded>
<embeddeds>
</configuration>
</plugin>
...
Assim como as atualizações do AEM, as versões do cliente são implantadas usando uma estratégia de implantação contínua para eliminar o tempo de inatividade do cluster de autor nas circunstâncias certas. A sequência geral de eventos é a descrita abaixo, em que Azul é a versão antiga do código do cliente e Verde é a nova versão. Azul e Verde estão executando a mesma versão do código do AEM.
Índices novos ou modificados causarão uma etapa adicional de indexação ou reindexação antes que a nova versão (Verde) possa ganhar tráfego. Detalhes sobre a gestão de índice no AEM as a Cloud Service podem ser encontrados neste artigo. Você pode verificar o status do trabalho de indexação na página de construção do Cloud Manager e receberá uma notificação quando a nova versão estiver pronta para receber tráfego.
O tempo necessário para uma implantação contínua variará dependendo do tamanho do índice, já que a versão Verde não pode aceitar tráfego até que o novo índice tenha sido gerado.
No momento, o AEM as a Cloud Service não funciona com ferramentas de gerenciamento de índice, como a ferramenta ACS Commons Ensure Oak Index.
O mecanismo de publicação é compatível com versões anteriores das APIs Java de Replicação do AEM.
Para desenvolver e testar a replicação com o início rápido do AEM pronto para nuvem, os recursos clássicos de replicação precisam ser usados com uma configuração de Autor/Publicação. No caso do ponto de entrada da interface no AEM Author ter sido removido para a nuvem, os usuários acessariam http://localhost:4502/etc/replication
para configuração.
Como detalhado acima, a estratégia de implantação contínua do AEM as a Cloud Service implica que as versões antigas e novas possam estar funcionando ao mesmo tempo. Portanto, tenha cuidado com alterações de código que não sejam compatíveis com a versão antiga do AEM que ainda está em operação.
Além disso, a versão antiga deve ser testada quanto à compatibilidade com qualquer nova estrutura de conteúdo mutável aplicada pela nova versão em caso de reversão, já que o conteúdo mutável não é removido.
Alterar os usuários do serviço ou as ACLs necessárias para acessar o conteúdo ou o código pode levar a erros nas versões do AEM mais antigas, resultando no acesso a esse conteúdo ou código com usuários de serviço desatualizados. Para lidar com esse comportamento, uma recomendação é fazer alterações distribuídas em pelo menos duas versões, com a primeira versão funcionando como uma ponte antes da limpeza na versão subsequente.
Se forem feitas alterações nos índices, é importante que a versão Azul continue a usar seus índices até que seja encerrada, enquanto a versão Verde use seu próprio conjunto modificado de índices. O desenvolvedor deve seguir as técnicas de gerenciamento de índice descritas neste artigo.
Se uma falha for relatada ou detectada após a implantação, é possível que uma reversão para a versão Azul seja necessária. Seria sensato garantir que o código Azul seja compatível com quaisquer novas estruturas criadas pela versão Verde, uma vez que as novas estruturas (qualquer conteúdo mutável) não serão revertidas. Se o código antigo não for compatível, as correções precisarão ser aplicadas nas versões subsequentes do cliente.
Ambientes de desenvolvimento rápido (ou RDEs como abreviação) permitem que os desenvolvedores implantem e revisem rapidamente as alterações, minimizando o tempo necessário para testar os recursos que já comprovadamente funcionam em um ambiente de desenvolvimento local.
Ao contrário dos ambientes de desenvolvimento comuns, que implantam código por meio do pipeline do Cloud Manager, os desenvolvedores usam ferramentas de linha de comando para sincronizar o código de um ambiente de desenvolvimento local com o RDE. Depois que as alterações forem testadas com êxito em um RDE, elas deverão ser implantadas em um ambiente de desenvolvimento de nuvem comum por meio do pipeline do Cloud Manager , que colocará o código por meio das portas de qualidade apropriadas.
Nas soluções de AEM existentes, os clientes têm a opção de executar instâncias com modos de execução arbitrários e aplicar a configuração OSGI ou instalar pacotes OSGI a essas instâncias específicas. Os modos de execução definidos normalmente incluem o service (criar e publicar) e o ambiente (rde, dev, stage, prod).
O AEM as a Cloud Service, por outro lado, é mais opinativo sobre quais modos de execução estão disponíveis e como os pacotes OSGI e a configuração OSGI podem ser mapeados para eles:
<service>.<environment_type>
está tendo suporte, mas elas devem ser usadas nessa ordem específica (por exemplo, author.dev
ou publish.prod
). Os tokens OSGI devem ser referenciados diretamente do código, em vez de usar o método de getRunModes
, que não incluirá mais o environment_type
no tempo de execução. Para obter mais informações, consulte Configuração do OSGi para o AEM as a Cloud Service.install.author
ou install.publish
.AEM as a Cloud Service não permite o uso de modos de execução para instalar conteúdo para ambientes ou serviços específicos. Se um ambiente de desenvolvimento precisar ser pré-implantado com dados ou HTML que não estejam nos ambientes de armazenamento temporário ou de produção, o gerenciador de pacotes poderá ser usado.
As configurações de modo de execução compatíveis são:
A configuração OSGI que tem os modos de execução mais correspondentes é usada.
Ao desenvolver localmente, um parâmetro de inicialização do modo de execução, -r
, é usado para especificar a configuração OSGI do modo de execução.
$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev
As configurações da Tarefa de manutenção devem ser mantidas no controle de origem já que a tela Ferramentas > Operações não estará mais disponível nos ambientes na nuvem. Isto tem o benefício de assegurar que as mudanças sejam intencionalmente persistentes em vez de aplicadas de forma reativa e talvez até esquecidas. Consulte o artigo da Tarefa de manutenção para obter mais informações.