Atualização de código e personalizações upgrading-code-and-customizations

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

Visão geral overview

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

Além de, opcionalmente, atualizar sua base de código e as personalizações para funcionarem com a nova versão do AEM, o 6.5 também ajuda a gerenciar suas personalizações com mais eficiência com o recurso Compatibilidade com Versões Anteriores, conforme descrito em esta página.

Conforme mencionado acima e mostrado no diagrama abaixo, executar o Detector de padrões na primeira etapa pode ajudar a avaliar a complexidade geral da atualização. Ele também pode ajudá-lo a decidir se você deseja executar no modo de compatibilidade ou atualizar suas personalizações para usar todos os novos recursos do AEM 6.5. Consulte a página Compatibilidade com versões anteriores no AEM 6.5 para obter mais detalhes.

Atualizar a base de código upgrade-code-base

Criar uma Ramificação Dedicada para o Código 6.5 no Controle de Versão create-a-dedicated-branch-for-6.5-code-in-version-control

Todos os códigos e configurações necessários para a implementação do 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 destino do AEM. O teste iterativo da base de código em relação à versão de destino do AEM e correções de bugs subsequentes é gerenciado nessa ramificação.

Atualizar a versão AEM Uber Jar update-the-aem-uber-jar-version

O jar AEM Uber inclui todas as APIs AEM como uma única dependência no pom.xml do seu projeto Maven. É sempre uma prática recomendada incluir o Uber Jar como uma única dependência em vez de incluir dependências individuais da API do AEM. Ao atualizar a base de código, altere a versão do Uber Jar para apontar para a versão de destino do AEM. Se seu projeto foi desenvolvido em uma versão de AEM antes da existência do Uber Jar, remova todas as dependências individuais da API AEM. Substitua-os por uma única inclusão do Uber Jar para a versão de destino do AEM. Recompile a base de código em relação à nova versão do Uber Jar. Atualize quaisquer APIs ou métodos obsoletos para que sejam compatíveis com a versão de destino do AEM.

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

Eliminar o uso do Resolvedor de recursos administrativos phase-out-use-of-administrative-resource-resolver

O uso de uma sessão administrativa através de SlingRepository.loginAdministrative() e ResourceResolverFactory.getAdministrativeResourceResolver() foi predominante em bases de código antes do AEM 6.0. Esses métodos foram descontinuados por motivos de segurança, pois fornecem 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 os Usuários de serviço. Mais informações sobre Usuários de Serviço e como encerrar as sessões administrativas podem ser encontradas aqui.

Consultas e índices Oak queries-and-oak-indexes

Qualquer uso de queries na base de código deve ser totalmente testado como parte da atualização da base de código. Para clientes que estão atualizando do Jackrabbit 2 (versões do AEM anteriores à 6.0), esse teste é especialmente importante, pois o Oak não indexa o conteúdo automaticamente e os índices personalizados devem ser criados. Se estiver atualizando de uma versão AEM 6.x, as definições de índice Oak prontas para uso podem ter sido alteradas e podem afetar as consultas existentes.

As seguintes ferramentas estão disponíveis para analisar e inspecionar o desempenho da consulta:

Criação da interface clássica classic-ui-authoring

A criação da interface clássica ainda está disponível no AEM 6.5, mas está sendo descontinuada. Mais informações podem ser encontradas aqui. Se seu aplicativo estiver sendo executado no ambiente de autor da interface clássica, é recomendável atualizar para AEM 6.5 e continuar usando a interface clássica. A migração para a interface para 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.5, várias configurações de OSGi devem ser enviadas para a base de código. Mais detalhes sobre como fazer a configuração podem ser encontrados aqui.

Alinhar com a estrutura do repositório 6.5 align-repository-structure

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, várias configurações devem ser movidas para não residirem mais em /etc, como acontecia no passado. Para analisar o conjunto completo de problemas de reestruturação de repositório que devem ser revisados e acomodados no AEM 6.4 atualizado, consulte Reestruturação de repositório no AEM 6.4.

Personalizações do AEM aem-customizations

Todas as personalizações no ambiente de criação do AEM na versão de origem do AEM devem ser identificadas. Depois de identificadas, é recomendável que cada personalização seja armazenada no controle de versão ou que seja feito um backup mínimo como parte de um pacote de conteúdo. Todas as personalizações devem ser implantadas e validadas em um ambiente de controle de qualidade ou preparo que execute a versão de destino do AEM antes de uma atualização de produção.

Sobreposições em geral overlays-in-general

É uma prática comum estender a funcionalidade do AEM imediatamente, 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 destino do AEM. Se um arquivo (como JS, JSP, HTL) estiver sobreposto, a Adobe recomenda que você deixe um comentário sobre qual funcionalidade foi aumentada para facilitar o teste de regressão na versão de destino do AEM. Mais informações sobre sobreposições em geral podem ser encontradas aqui. As instruções para sobreposições específicas de AEM podem ser encontradas abaixo.

Atualização do Forms de pesquisa personalizada upgrading-custom-search-forms

Os Aspectos de pesquisa personalizados exigem alguns ajustes manuais após a atualização para funcionarem corretamente. Para obter mais detalhes, consulte Atualizando Forms de Pesquisa Personalizada.

Personalizações da interface do usuário do Assets assets-ui-customizations

As instâncias que personalizaram implantações do Assets devem ser preparadas para a atualização. Essa ação é necessária para garantir que todo o conteúdo personalizado seja compatível com a nova estrutura de nó 6.4.

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

Gerar IDs de ativos para Assets existentes generating-asset-ids-for-existing-assets

Para gerar IDs de ativos para ativos existentes, atualize os ativos ao atualizar a instância do AEM para executar o AEM 6.5. Esta etapa é necessária para habilitar o recurso do Assets Insights. Para obter mais detalhes, consulte Adicionar código incorporado.

Para atualizar ativos, configure o pacote Associar IDs de ativos no console JMX. Dependendo do número de ativos no repositório, migrateAllAssets pode demorar. Os testes internos da Adobe estimam aproximadamente uma hora para 125.000 ativos na TarMK.

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

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

Personalizações do script do InDesign indesign-script-customizations

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

Recuperando configurações do ContextHub recovering-contexthub-configurations

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

Personalizações do fluxo de trabalho workflow-customizations

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

Modelos editáveis editable-templates

A estrutura dos modelos Editáveis foi alterada entre o AEM 6.2 e 6.3. Se você estiver atualizando a partir da versão 6.2 ou anterior, e se o conteúdo do site for criado com modelos editáveis, você deverá usar a Ferramenta de Limpeza de Nós Responsivos. A ferramenta deve executar após uma atualização para limpar o conteúdo. Execute-o nos níveis do Author e do Publish.

Alterações na implementação de CUG cug-implementation-changes

A implementação de Grupos de usuários fechados mudou significativamente para lidar com as limitações de desempenho e escalabilidade em versões anteriores do AEM. A versão anterior do CUG foi descontinuada no 6.3 e a nova implementação é compatível somente com a interface para toque. Se você estiver atualizando a partir da versão 6.2 ou anterior, as instruções para migrar para a nova implementação CUG podem ser encontradas aqui.

Procedimento de teste testing-procedure

Um plano de teste abrangente deve ser preparado para testar as atualizações. O teste da base de código e do aplicativo atualizados deve ser feito primeiro em ambientes inferiores. Quaisquer bugs 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 superior devem ser atualizados.

Testando o procedimento de atualização testing-the-upgrade-procedure

O procedimento de atualização descrito aqui deve ser testado em ambientes de Desenvolvimento e Controle de Qualidade, conforme documentado no seu manual de execução personalizado (consulte Planejando sua atualização). O procedimento de atualização deve ser repetido até que todas as etapas sejam documentadas no livro de execução de atualização e o processo de atualização seja tranquilo.

Áreas de teste de implementação implementation-test-areas-

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

Documentar o plano de teste e os resultados document-test-plan-and-results

Deve ser criado um plano de teste que abranja as áreas de teste de implementação acima. Muitas vezes, faz sentido separar o plano de teste por Autor e listas de tarefas do Publish. Esse plano de teste deve ser executado em ambientes de Desenvolvimento, Controle de qualidade e Preparo antes da atualização dos ambientes de Produção. Os resultados dos testes e as métricas de desempenho devem ser capturados em ambientes inferiores para fornecer comparação ao atualizar ambientes de Preparo e Produção.