Actualización de código y personalizaciones upgrading-code-and-customizations

Al planificar una actualización, es necesario investigar y abordar las siguientes áreas de una implementación.

Información general overview

Antes de continuar con una actualización, debe tener una base de código de aplicación estable que se haya probado a fondo con la versión de destino de AEM. En función de las observaciones realizadas en las pruebas, podría haber maneras de optimizar el código personalizado. Esto podría incluir refactorizar el código para evitar atravesar el repositorio, la indexación personalizada para optimizar la búsqueda, o el uso de nodos no ordenados en JCR, entre otros.

Además de la opción de actualizar la base de código y las personalizaciones para que funcionen con la nueva versión de AEM, la versión 6.4 también ayuda a administrar las personalizaciones de forma más eficiente con la función Compatibilidad con versiones anteriores como se describe en esta página.

Como se ha mencionado anteriormente y se muestra en el diagrama siguiente, al ejecutar el Detector de patrones en el primer paso le ayudará a evaluar la complejidad general de la actualización y si desea ejecutar en modo de compatibilidad o actualizar sus personalizaciones para utilizar todas las nuevas funciones de AEM 6.4. Consulte la Compatibilidad con versiones anteriores en AEM 6.4 para obtener más información.

Actualizar la base de código upgrade-code-base

Crear una rama dedicada para el código 6.4 en el control de versiones create-a-dedicated-branch-for-6-4-code-in-version-control

Todo el código y las configuraciones necesarias para la implementación de AEM se deben administrar con alguna forma de control de versiones. Se debe crear una rama dedicada en el control de versiones para administrar los cambios necesarios para la base de código en la versión de destino de AEM. En esta rama se gestionarán pruebas iterativas del código base con respecto a la versión de destino de AEM y correcciones de errores posteriores.

Actualización de la versión de AEM Uber Jar update-the-aem-uber-jar-version

El AEM Uber jar incluye todas las API de AEM como una sola dependencia en el proyecto Maven pom.xml. Siempre es una práctica recomendada incluir Uber Jar como una dependencia única en lugar de incluir dependencias de API de AEM individuales. Al actualizar la base de código, la versión de Uber Jar debe cambiarse para que apunte a la versión de destino de AEM. Si el proyecto se desarrolló en una versión de AEM antes de la existencia de Uber Jar, todas las dependencias individuales de la API de AEM deben eliminarse y reemplazarse por una sola inclusión de Uber Jar para la versión de destino de AEM. La base de código debe recompilarse con la nueva versión de Uber Jar. Cualquier API o método obsoleto debe actualizarse para que sea compatible con la versión de destino de AEM.

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

Eliminación progresiva del uso de la resolución de recursos administrativos phase-out-use-of-administrative-resource-resolver

El uso de una sesión administrativa mediante SlingRepository.loginAdministrative() y ResourceResolverFactory.getAdministrativeResourceResolver() era bastante frecuente en las bases de código antes de AEM 6.0. Estos métodos han quedado obsoletos por motivos de seguridad, ya que ofrecen un nivel de acceso demasiado amplio. En futuras versiones de Sling, estos métodos se eliminarán. Se recomienda refactorizar cualquier código para utilizar usuarios de servicios en su lugar. Más información sobre los usuarios de servicios y cómo eliminar sesiones administrativas aquí.

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

Cualquier uso de consultas en la base de código debe probarse exhaustivamente como parte de la actualización de la base de código. Para los clientes que actualizan desde Jackrabbit 2 (versiones de AEM anteriores a la 6.0), esto es especialmente importante, ya que Oak no indexa el contenido automáticamente y es posible que sea necesario crear índices personalizados. Si se actualiza desde una versión AEM 6.x, las definiciones de índice Oak pueden haber cambiado y podrían afectar a las consultas existentes.

Hay varias herramientas disponibles para analizar e inspeccionar el rendimiento de las consultas:

Creación de IU clásica classic-ui-authoring

La creación de IU clásica sigue disponible en AEM 6.4, pero está en desuso. Encontrará más información here. Si la aplicación se está ejecutando en el entorno de creación de la IU clásica, se recomienda actualizar a AEM 6.4 y seguir utilizando la IU clásica. La migración a la interfaz de usuario táctil se puede planificar como proyecto independiente para completarlo en varios ciclos de desarrollo. Para utilizar la IU clásica en AEM 6.4, es necesario confirmar varias configuraciones de OSGi en la base de código. Encontrará más detalles sobre cómo configurar esto here.

Alinear con la estructura de repositorio 6.4 align-repository-structure

Para facilitar las actualizaciones y garantizar que las configuraciones no se sobrescriban durante una actualización, el repositorio se reestructurará en la versión 6.4 para separar el contenido de la configuración.

Por lo tanto, se debe mover una serie de configuraciones para dejar de residir en /etc como en el pasado. Para revisar el conjunto completo de preocupaciones de reestructuración de repositorios que deben revisarse y adaptarse en la versión actualizada a la AEM 6.4, véase Reestructuración de repositorios en AEM 6.4.

Personalizaciones de AEM aem-customizations

Es necesario identificar todas las personalizaciones del entorno de creación de AEM en la versión de origen de AEM. Una vez identificados, se recomienda almacenar cada personalización en el control de versiones o, como mínimo, en una copia de seguridad como parte de un paquete de contenido. Todas las personalizaciones deben implementarse y validarse en un entorno de control de calidad o ensayo que ejecute la versión de destino de AEM antes de una actualización de producción.

Superposiciones en general overlays-in-general

Es una práctica habitual ampliar AEM funcionalidad predeterminada superponiendo nodos y/o archivos bajo /libs con nodos adicionales bajo /apps. Estas superposiciones deben rastrearse en el control de versiones y probarse con la versión de destino de AEM. Si se superpone un archivo (ya sea JS, JSP, HTL), se recomienda dejar un comentario sobre qué funcionalidad se ha aumentado para facilitar las pruebas de regresión en la versión de AEM de destino. Puede encontrar más información sobre las superposiciones en general here. A continuación se encuentran las instrucciones para superposiciones de AEM específicas.

Actualización de Forms de búsqueda personalizada upgrading-custom-search-forms

Las facetas de búsqueda personalizadas requieren algunos ajustes manuales después de la actualización para funcionar correctamente. Para obtener más información, consulte Actualización de Forms de búsqueda personalizada.

Personalizaciones de la interfaz de usuario de Assets assets-ui-customizations

Las instancias que tienen implementaciones personalizadas de Assets deben estar preparadas para la actualización. Esto es necesario para garantizar que todo el contenido personalizado sea compatible con la nueva estructura de nodos 6.4.

Puede preparar las personalizaciones de la interfaz de usuario de Assets haciendo lo siguiente:

Generación de ID de recursos para recursos existentes generating-asset-ids-for-existing-assets

Para generar ID de recursos para recursos existentes, actualice los recursos al actualizar la instancia de AEM para que se ejecute AEM 6.4. Esto es necesario para habilitar la variable Función de Assets Insights. Para obtener más información, consulte Adición de código incrustado.

Para actualizar recursos, configure el paquete Asociar ID de recursos en la consola JMX. En función del número de recursos del repositorio, migrateAllAssets puede tardar mucho tiempo. Nuestras pruebas internas estiman aproximadamente una hora para 125 mil activos en TarMK.

Si necesita ID de recursos para un subconjunto de todos los recursos, use la variable migrateAssetsAtPath API.

Para todos los demás fines, utilice la variable migrateAllAssets() API.

Personalizaciones de secuencias de comandos de InDesign indesign-script-customizations

Adobe recomienda colocar scripts personalizados en /apps/settings/dam/indesign/scripts ubicación. Encontrará más información sobre las personalizaciones de las secuencias de comandos de InDesign here.

Recuperación de las configuraciones de ContextHub recovering-contexthub-configurations

Las configuraciones de ContextHub se realizan mediante una actualización. Encontrará instrucciones sobre cómo recuperar las configuraciones existentes de ContextHub here.

Personalizaciones de flujo de trabajo workflow-customizations

Es una práctica habitual actualizar los flujos de trabajo de modificación para añadir o eliminar funciones que no son necesarias. Un flujo de trabajo común personalizado es el flujo de trabajo de recursos de actualización de DAM . Todos los flujos de trabajo necesarios para una implementación personalizada deben realizarse copias de seguridad y almacenarse en el control de versiones, ya que se pueden sobrescribir durante una actualización.

Plantillas editables editable-templates

La estructura de las plantillas editables ha cambiado entre AEM 6.2 y 6.3. Si actualiza desde 6.2 o versiones anteriores y el contenido del sitio se crea con plantillas editables, deberá usar la variable Herramienta de limpieza de nodos interactivos. La herramienta está pensada para ejecutarse after una actualización para limpiar el contenido. Tendrá que ejecutarse tanto en el nivel de Author como en el de Publish.

Cambios en la implementación del CUG cug-implementation-changes

La implementación de Grupos de usuarios cerrados ha cambiado significativamente para abordar las limitaciones de rendimiento y escalabilidad en versiones anteriores de AEM. La versión anterior de CUG quedó obsoleta en la versión 6.3 y la nueva implementación solo es compatible con la interfaz de usuario táctil. Si está actualizando desde la versión 6.2 o anterior, encontrará instrucciones para migrar a la nueva implementación de CUG here.

Procedimiento de prueba testing-procedure

Se debe preparar un plan de prueba completo para probar las actualizaciones. La prueba de la base de código y la aplicación actualizados deberán realizarse primero en entornos más bajos. Los errores encontrados deben corregirse de forma iterativa hasta que la base de código sea estable, solo entonces se deben actualizar los entornos de nivel superior.

Prueba del procedimiento de actualización testing-the-upgrade-procedure

El procedimiento de actualización como se describe aquí debe probarse en entornos de desarrollo y control de calidad como se documenta en su libro de ejecución personalizado (consulte Planificación de la actualización). El procedimiento de actualización debe repetirse hasta que todos los pasos estén documentados en el libro de ejecución de la actualización y el proceso de actualización sea fluido.

Áreas de prueba de implementación implementation-test-areas-

A continuación, se muestran áreas críticas de cualquier implementación de AEM que debería incluirse en el plan de prueba una vez que el entorno se haya actualizado y se haya implementado la base de código actualizada.

Plan y resultados de la prueba de documento document-test-plan-and-results

Se debe crear un plan de prueba que cubra las áreas de prueba de implementación anteriores. En muchos casos, tendrá sentido separar el plan de prueba por listas de tareas Autor y Publicación . Este plan de prueba debe ejecutarse en los entornos Dev, QA y Stage antes de actualizar los entornos de producción. Los resultados de las pruebas y las métricas de rendimiento deben capturarse en entornos más bajos para proporcionar comparación al actualizar entornos de fase y producción.