Atualização de código e personalizações

Ao planejar uma atualização, as seguintes áreas de uma implementação precisam ser investigadas e tratadas.

Visão geral

  1. Detector de padrões - execute o Detector de padrões conforme descrito no planejamento de atualização e descrito detalhadamente nesta página para obter um relatório do detector de padrões que contenha mais detalhes sobre áreas que precisam ser abordadas além das APIs/pacotes não disponíveis na versão do Público alvo do AEM. O relatório de Detecção de padrão deve fornecer uma indicação de quaisquer incompatibilidades no código. Se não houver nenhuma, sua implantação já será compatível com a versão 6.4, você ainda poderá optar por fazer um novo desenvolvimento para utilizar a funcionalidade 6.4, mas não precisará apenas para manter a compatibilidade. Se houver incompatibilidades reportadas, você poderá optar por a) Executar no modo de compatibilidade e adiar seu desenvolvimento para novos recursos 6.4 ou compatibilidade, b) Decidir fazer o desenvolvimento após a atualização e passar para a etapa 2. Consulte Compatibilidade com versões anteriores no AEM 6.4 para obter mais detalhes.

  2. Desenvolver base de código para a versão 6.4 - Crie uma ramificação ou repositório dedicado para a base de código para a versão do Público alvo. Use as informações da Compatibilidade de pré-atualização para planejar áreas de código a serem atualizadas.

  3. Compile com o jar 6.4 Uber - atualize os POMs base de código para apontar para o jar de 6.4 uber e compile o código em relação a isso.

  4. Atualização AEM personalizações - Quaisquer personalizações ou extensões para AEM devem ser atualizadas/validadas para funcionarem na versão 6.4 e adicionadas à base de código 6.4. Inclui o UI Search Forms, Personalizações de ativos, qualquer coisa que use /mnt/overlay

  5. Implantar no Ambiente 6.4 - uma instância limpa do AEM 6.4 (Autor + Publicar) deve estar em pé no ambiente Dev/QA. A base de código atualizada e uma amostra representativa de conteúdo (da produção atual) devem ser implantadas.

  6. Validação do controle de qualidade e correção de erros - O controle de qualidade deve validar o aplicativo nas instâncias de Autor e Publicação da versão 6.4. Quaisquer erros encontrados devem ser corrigidos e confirmados para a base de códigos 6.4. Repita Dev-Cycle conforme necessário até que todos os erros sejam corrigidos.

Antes de continuar com uma atualização, você deve ter uma base de código de aplicativo estável que tenha sido testada completamente em relação à versão de público alvo do AEM. Com base em observações feitas em testes, pode haver maneiras de otimizar o código personalizado. Isso pode incluir a refatoração do código para evitar atravessar o repositório, a indexação personalizada para otimizar a pesquisa ou o uso de nós não ordenados no JCR, entre outros.

Além da opção de atualizar sua base de código e personalizações para trabalhar com a nova versão do AEM, o 6.4 também ajuda a gerenciar suas personalizações com mais eficiência com o recurso Compatibilidade com versões anteriores, conforme descrito nesta página.

Como mencionado acima e mostrado no diagrama abaixo, executar o Detector de padrões na primeira etapa ajudará você a avaliar a complexidade geral da atualização e se deseja executar no modo de compatibilidade ou atualizar suas personalizações para usar todos os novos recursos do AEM 6.4. Consulte a página Compatibilidade com versões anteriores AEM 6.4 para obter mais detalhes.
screen_shot_2018-03-30at175257

Atualizar a base de código

Criar uma ramificação dedicada para o código 6.4 no controle de versão

Todos os códigos e configurações necessários para sua implementação de AEM devem ser gerenciados usando alguma forma de controle de versão. Uma ramificação dedicada no controle de versão deve ser criada para gerenciar todas as alterações necessárias para a base de código na versão de público alvo do AEM. O teste iterativo da base de código em relação à versão de público alvo do AEM e as subsequentes correções de erros serão gerenciados nesta ramificação.

Atualize a versão AEM Uber Jar

O AEM Uber jar inclui todas as APIs AEM como uma única dependência no projeto Maven pom.xml. É sempre uma prática recomendada incluir o Uber Jar como uma única dependência em vez de incluir dependências individuais AEM API. Ao atualizar a base de código, a versão do Uber Jar deve ser alterada para apontar para a versão de público alvo do AEM. Se o seu projeto foi desenvolvido em uma versão do AEM anterior à existência do Uber Jar, todas as dependências individuais AEM API devem ser removidas e substituídas por uma única inclusão do Uber Jar para a versão do público alvo do AEM. A base de código deve então ser recompilada em relação à nova versão do Uber Jar. Quaisquer APIs ou métodos obsoletos devem ser atualizados para serem compatíveis com a versão de público alvo do AEM.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.4.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Uso gradual do Resolvedor de Recursos Administrativos

A utilização de uma sessão administrativa através de SlingRepository.loginAdministrative() e ResourceResolverFactory.getAdministrativeResourceResolver() era bastante predominante em bases de códigos antes da AEM 6.0. Esses métodos foram descontinuados por motivos de segurança, pois proporcionam um nível de acesso muito amplo. Em versões futuras do Sling, esses métodos serão removidos. É altamente recomendável refatorar qualquer código para usar Usuários do serviço. Mais informações sobre os Usuários do serviço e como eliminar sessões administrativas podem ser encontradas aqui.

Query e índices Oak

Qualquer uso de query na base de códigos deve ser testado minuciosamente como parte da atualização da base de códigos. Para clientes que atualizam do Jackrabbit 2 (versões de AEM anteriores à 6.0), isso é especialmente importante, pois o Oak não indexa o conteúdo automaticamente e talvez seja necessário criar índices personalizados. Se você estiver atualizando de uma versão AEM 6.x, as definições de índice Oak podem ter sido alteradas e podem afetar query existentes.

Várias ferramentas para analisar e inspecionar o desempenho do query estão disponíveis:

Classic UI Authoring

A criação da interface de usuário clássica ainda está disponível no AEM 6.4, mas está sendo descontinuada. Mais informações podem ser encontradas aqui. Se seu aplicativo estiver sendo executado no momento no ambiente do autor da interface clássica, é recomendável atualizar para o AEM 6.4 e continuar usando a interface clássica. A migração para a interface de usuário de toque pode ser planejada como um projeto separado a ser concluído em vários ciclos de desenvolvimento. Para usar a interface clássica no AEM 6.4, várias configurações de OSGi precisam ser confirmadas na base de código. Mais detalhes sobre como configurar isso podem ser encontrados aqui.

NOTE

Para ajudá-lo a sair da interface clássica e aproveitar as vantagens das mais recentes tecnologias AEM, considere aproveitar as ferramentas de modernização AEM para facilitar a migração.

Alinhar com a estrutura do repositório 6.4

Para facilitar as atualizações e garantir que as configurações não sejam substituídas durante uma atualização, o repositório é reestruturado na versão 6.4 para separar o conteúdo da configuração.

Portanto, algumas configurações devem ser movidas para que não residam mais /etc como acontecia no passado. Para analisar o conjunto completo de preocupações em matéria de reestruturação dos repositórios que devem ser revistas e acomodadas na atualização para AEM 6.4, ver reestruturação dos repositórios no AEM 6.4.

Personalizações AEM

Todas as personalizações do ambiente de criação AEM na versão de origem do AEM precisam ser identificadas. Depois de identificada, é recomendável que cada personalização seja armazenada no controle de versão ou no mínimo seja copiada como parte de um pacote de conteúdo. Todas as personalizações devem ser implantadas e validadas em um QA ou ambiente de armazenamento temporário executando a versão do público alvo do AEM antes da atualização da produção.

Sobreposições em geral

É uma prática comum estender a funcionalidade AEM fora da caixa sobrepondo nós e/ou arquivos em /libs com nós adicionais em /apps. Essas sobreposições devem ser rastreadas no controle de versão e testadas em relação à versão de público alvo do AEM. Se um arquivo (JS, JSP, HTL) estiver sobreposto, é recomendável deixar um comentário sobre qual funcionalidade foi aumentada para um teste de regressão mais fácil na versão de público alvo do AEM. Mais informações sobre sobreposições em geral podem ser encontradas aqui. As instruções para sobreposições de AEM específicas podem ser encontradas abaixo.

Atualização do Forms de pesquisa personalizada

Os Aspectos de pesquisa personalizados exigem alguns ajustes manuais após a atualização para funcionarem corretamente. Para obter mais detalhes, consulte Atualização do Formsde pesquisa personalizada.

Personalizações da interface do usuário do Assets

NOTE

Este procedimento é necessário apenas para atualizações de versões anteriores à AEM 6.2.

As instâncias que possuem implantações personalizadas de Ativos precisam estar preparadas para a atualização. Isso é necessário para garantir que todo o conteúdo personalizado seja compatível com a nova estrutura de nós 6.4.

Você pode preparar personalizações para a interface do usuário do Assets executando o seguinte procedimento:

  1. Na instância que precisa ser atualizada, abra o CRXDE Lite indo para https://server:port/crx/de/index.jsp

  2. Vá para o seguinte nó:

    • /apps/dam/content
  3. Renomeie o nó de conteúdo como content_backup. Para fazer isso, clique com o botão direito do mouse no painel do explorador, no lado esquerdo da janela, e escolha Renomear.

  4. Depois que o nó tiver sido renomeado, crie um novo nó com o nome de conteúdo sob /apps/dam o conteúdo nomeado e defina seu tipo de nó como sling:Folder.

  5. Mova todos os nós filhos do content_backup para o nó de conteúdo recém-criado. Você pode fazer isso clicando com o botão direito do mouse em cada nó filho no painel explorador e selecionando Mover.

  6. Exclua o nó content_backup .

  7. Os nós atualizados abaixo /apps/dam com o tipo de nó correto de sling:Folder devem ser salvos no controle de versão e implantados com a base de código ou em um backup mínimo como pacote de conteúdo.

Geração de IDs de ativos para ativos existentes

Para gerar IDs de ativos para ativos existentes, atualize os ativos ao atualizar sua instância de AEM para executar AEM 6.4. Isso é necessário para ativar o recurso Assets Insights. Para obter mais detalhes, consulte Adicionar códigoincorporado.

Para atualizar ativos, configure o pacote Associate Asset IDs no console JMX. Dependendo do número de ativos no repositório, migrateAllAssets pode levar muito tempo. Nossos testes internos estimam aproximadamente uma hora para 125 mil ativos no TarMK.

1487758945977

Se você precisar de IDs de ativos para um subconjunto de todos os ativos, use a migrateAssetsAtPath API.

Para todos os outros fins, use a migrateAllAssets() API.

Personalizações de script de InDesign

O Adobe recomenda colocar scripts personalizados no /apps/settings/dam/indesign/scripts local. Mais informações sobre personalizações de scripts de InDesign podem ser encontradas aqui.

Recuperando configurações do ContextHub

As configurações do ContextHub são efetuadas por uma atualização. As instruções sobre como recuperar as configurações existentes do ContextHub podem ser encontradas aqui.

Personalizações do fluxo de trabalho

É uma prática comum atualizar a modificação dos workflows prontos para uso para adicionar ou remover a funcionalidade desnecessária. Um fluxo de trabalho comum personalizado é o fluxo de trabalho do Ativo de atualização do DAM. Todos os workflows necessários para uma implementação personalizada devem ter backup e ser armazenados no controle de versão, pois podem ser substituídos durante uma atualização.

Modelos editáveis

NOTE

Este procedimento é necessário somente para atualizações de Sites usando Modelos editáveis do AEM 6.2

A estrutura para modelos editáveis foi alterada entre AEM 6.2 e 6.3. Se você estiver atualizando da versão 6.2 ou anterior e se o conteúdo do site for criado usando modelos editáveis, será necessário usar a Ferramenta de limpeza de nósresponsivos. A ferramenta deve ser executada após uma atualização para limpar o conteúdo. Ele precisará ser executado nos níveis Autor e Publicar.

Alterações de implementação de CUG

A implementação de Grupos de usuários fechados mudou significativamente para atender às limitações de desempenho e escalabilidade em versões anteriores do AEM. A versão anterior do CUG foi descontinuada na versão 6.3 e a nova implementação só é suportada na interface do usuário de toque. Se você estiver atualizando da versão 6.2 ou anterior, as Instruções para migrar para a nova implementação do CUG podem ser encontradas aqui.

Procedimento de teste

Deve ser preparado um plano de teste abrangente para testar atualizações. O teste da base de código atualizada e o aplicativo precisarão ser feitos em ambientes menores primeiro. Quaisquer erros encontrados devem ser corrigidos de forma iterativa até que a base de código seja estável, somente então os ambientes de nível mais alto devem ser atualizados.

Teste do procedimento de atualização

O procedimento de atualização, conforme descrito aqui, deve ser testado em ambientes Dev e QA, conforme documentado em seu manual de execução personalizado (consulte Planejamento da atualização). O procedimento de atualização deve ser repetido até que todas as etapas sejam documentadas no manual de execução da atualização e o processo de atualização seja suave.

Áreas de teste de implementação

Abaixo estão áreas críticas de qualquer implementação AEM que deve ser coberta pelo seu plano de teste depois que o ambiente for atualizado e a base de código atualizada tiver sido implantada.

Área de teste funcional Descrição
Sites publicados Testando a implementação AEM e o código associado na camada
de publicação por meio do dispatcher. Deve incluir critérios para atualizações de página e invalidação de cache
.
Criação Testando a implementação AEM e o código associado na camada Autor. Deve incluir páginas, criação de componentes e caixas de diálogo.
Integrações com soluções de Marketing Cloud Validação de integrações com produtos como Analytics, DTM e Público alvo.
Integrações com sistemas de terceiros Todas as integrações de terceiros devem ser validadas nos níveis de Autor e Publicação.
Autenticação, segurança e permissões Quaisquer mecanismos de autenticação como LDAP/SAML devem ser validados.
As permissões e os grupos devem ser testados nos níveis de Autor e Publicação
.
Query Os índices e query personalizados devem ser testados juntamente com o desempenho do query.
Personalizações da interface Quaisquer extensões ou personalizações à interface do usuário AEM no ambiente do autor.
Fluxos de trabalhos workflows e funcionalidade personalizados e/ou prontos para uso.
Teste de desempenho O teste de carga deve ser executado em níveis de Autor e Publicação que simulam cenários reais.

Plano de teste e resultados do Documento

Deve ser criado um plano de ensaio que abranja as áreas de ensaio de implementação acima referidas. Em muitos casos, fará sentido separar o plano de teste por listas de Autor e Publicação de tarefa. Este plano de teste deve ser executado em ambientes de desenvolvimento, controle de qualidade e estágio antes da atualização dos ambientes de produção. Os resultados do teste e as métricas de desempenho devem ser capturados em ambientes menores para fornecer comparação ao atualizar ambientes de estágio e de produção.

Nesta página