Nesta parte do jornada do desenvolvedor sem periféricos do AEM, saiba como implantar um aplicativo sem periféricos, colocando seu código local no Git e movendo-o para o Git do Cloud Manager para o pipeline de CI/CD.
No documento anterior da jornada sem cabeçalho AEM, Como atualizar seu conteúdo por meio das APIs do AEM Assets você aprendeu a atualizar o conteúdo sem cabeçalho existente no AEM por meio da API e agora deve:
Este artigo se baseia nesses fundamentos para que você entenda como preparar seu próprio projeto sem periféricos AEM para entrar em funcionamento.
Este documento ajuda você a entender o pipeline de publicação sem periféricos AEM e as considerações de desempenho que você precisa ter em mente antes de entrar em contato com seu aplicativo.
O SDK do AEM é usado para criar e implantar código personalizado. É a principal ferramenta necessária para desenvolver e testar seu aplicativo sem periféricos antes de entrar online. Ele contém os seguintes artefatos:
Além do SDK AEM, você precisará de ferramentas adicionais que facilitem o desenvolvimento e o teste do código e conteúdo localmente:
Como AEM é um aplicativo Java, é necessário instalar o Java e o SDK do Java para dar suporte ao desenvolvimento AEM as a Cloud Service.
O Git é o que você usará para gerenciar o controle do código-fonte, bem como para verificar as alterações no Cloud Manager e, em seguida, implantá-las em uma instância de produção.
AEM usa o Apache Maven para criar projetos gerados a partir do arquétipo de projeto AEM Maven. Todos os principais IDEs fornecem suporte de integração para Maven.
Node.js é um ambiente de tempo de execução JavaScript usado para trabalhar com os ativos de front-end de um projeto de AEM ui.frontend
subprojeto. O Node.js é distribuído com npm, é o gerenciador de pacotes Node.js de fato, usado para gerenciar dependências do JavaScript.
Em seguida, vamos dar uma olhada nas partes constituintes de um ambiente AEM.
Um ambiente AEM completo é composto de um Autor, Publicação e Dispatcher. Esses mesmos componentes serão disponibilizados no tempo de execução de desenvolvimento local para facilitar a visualização do código e conteúdo antes de entrar no ar.
O serviço do Autor é onde os usuários internos criam, gerenciam e visualizam conteúdo.
O serviço de Publicação é considerado o ambiente "ativo" e é, normalmente, com o que os usuários finais interagem. O conteúdo, após ser editado e aprovado no serviço do Autor, é distribuído ao serviço de Publicação. O padrão de implantação mais comum com aplicativos headless do AEM é ter uma versão de produção do aplicativo conectada a um serviço de publicação do AEM.
O Dispatcher é um servidor Web estático aumentado com o módulo dispatcher do AEM. Armazena em cache as páginas da Web produzidas pela instância de publicação para melhorar o desempenho.
O projeto de desenvolvimento local é construído no Apache Maven e está usando o Git para controle de origem. Para atualizar o projeto, os desenvolvedores podem usar seu ambiente de desenvolvimento integrado preferido, como Eclipse, Visual Studio Code ou IntelliJ, entre outros.
Para testar atualizações de código ou conteúdo que serão assimiladas pelo aplicativo sem periféricos, é necessário implantar as atualizações no tempo de execução do AEM local, que inclui instâncias locais dos serviços de criação e publicação do AEM.
Anote as distinções entre cada componente no tempo de execução do AEM local, pois é importante testar suas atualizações onde elas são mais importantes. Por exemplo, teste as atualizações de conteúdo no autor ou teste o novo código na instância de publicação.
Em um sistema de produção, um dispatcher e um servidor http Apache sempre se sentarão na frente de uma instância de publicação de AEM. Eles fornecem serviços de armazenamento em cache e de segurança para o sistema de AEM, portanto, é fundamental testar atualizações de código e conteúdo no dispatcher também.
Para preparar o seu projeto sem periféricos AEM para lançamento, você precisa garantir que todas as partes constituintes do seu projeto estejam funcionando bem.
Para fazer isso, você precisa juntar tudo: código, conteúdo e configuração e teste-os em um ambiente de desenvolvimento local para estar em prontidão.
O ambiente de desenvolvimento local compreende três áreas principais:
Depois que o ambiente de desenvolvimento local for configurado, é possível simular o conteúdo que serve para o aplicativo React ao implantar um servidor Node estático localmente.
Para obter uma análise mais detalhada da configuração de um ambiente de desenvolvimento local e todas as dependências necessárias para a visualização de conteúdo, consulte Documentação de implantação de produção.
Agora, é hora de preparar seu aplicativo sem periféricos AEM para o lançamento, seguindo as práticas recomendadas descritas abaixo.
Last-modified-since
para atualizar recursos._reference
saída no arquivo JSON para iniciar o download de ativos sem precisar analisar os arquivos JSON completos.Depois de verificar se tudo foi testado e está funcionando corretamente, você estará pronto para enviar as atualizações de código para um repositório Git centralizado no Cloud Manager.
Depois que as atualizações forem carregadas no Cloud Manager, elas poderão ser implantadas em AEM as a Cloud Service usando pipeline de CI/CD do Cloud Manager.
Você pode começar a implantar seu código aproveitando o pipeline de CI/CD do Cloud Manager, que é coberto extensivamente here.
Para que os usuários tenham a melhor experiência possível ao usar o aplicativo sem periféricos AEM, é importante monitorar as principais métricas de desempenho, conforme detalhado abaixo:
Siga essas práticas recomendadas como uma abordagem geral para depurar:
Para registrar um bug com suporte com eficiência, caso precise de assistência adicional, siga as etapas abaixo:
Parabéns! Você concluiu a Jornada do desenvolvedor sem cabeçalho AEM! Agora você deve conhecer:
Você já lançou seu primeiro projeto AEM Headless ou agora tem todo o conhecimento necessário para isso. Excelente trabalho!
As lojas sem cabeça no AEM não precisam parar aqui. Você deve se lembrar do Parte Introdução da jornada discutimos brevemente como o AEM não só suporta o delivery sem interface e os modelos de pilha completa tradicionais, como também pode suportar modelos híbridos que combinam as vantagens de ambos.
Se esse tipo de flexibilidade é algo que você precisa para o seu projeto, continue para a parte adicional opcional da jornada, Como criar aplicativos de página única (SPA) com AEM.