Actualización del código y las personalizaciones

Cuando se planifica una actualización, es necesario investigar y abordar las siguientes áreas de una implementación.

Información general

  1. Detector de patrones: ejecute el detector de patrones tal como se describe en la planificación de actualizaciones y se describe en detalle en esta página para obtener un informe de detector de patrones que contenga más detalles sobre las áreas que deben abordarse además de las API o paquetes no disponibles en la versión de Destinatario de AEM. El informe Detección de patrones debe proporcionarle una indicación de cualquier incompatibilidad en el código. Si no hay ninguna, entonces la implementación ya es compatible con la versión 6.5, aún puede elegir realizar un nuevo desarrollo para utilizar la funcionalidad 6.5, pero no la necesita sólo para mantener la compatibilidad. Si hay incompatibilidades notificadas, puede elegir entre: a) Ejecutar en modo de compatibilidad y postergar el desarrollo para nuevas características de 6.5 o compatibilidad, b) Decidir realizar el desarrollo después de la actualización y pasar al paso 2. Consulte Compatibilidad con versiones anteriores en AEM 6.5 para obtener más información.

  2. Desarrollar base de código para 6.5- Crear una rama o repositorio dedicado para la base de código para la versión de Destinatario. Utilice la información de Compatibilidad previa a la actualización para planificar las áreas de código que se van a actualizar.

  3. Compile con 6.5 Uber jar- Actualice los POM base de código para que señalen a 6.5 uber jar y compile código en contra de esto.

  4. Actualización AEM personalizaciones*: *Cualquier personalización o extensión de AEM debe actualizarse/validarse para funcionar en 6.5 y agregarse a la base de código 6.5. Incluye la búsqueda en la interfaz de usuario de Forms, las personalizaciones de recursos y todo lo que utilice /mnt/overlay

  5. Implementar en Entorno 6.5: una instancia limpia de AEM 6.5 (Autor + Publicar) debe colocarse en un entorno Dev/QA. Se debe implementar una base de código actualizada y una muestra representativa de contenido (de la producción actual).

  6. Validación de control de calidad y corrección de errores: el control de calidad debe validar la aplicación en instancias de autor y publicación de 6.5. Los errores encontrados deben corregirse y confirmarse en la base de código 6.5. Repita Dev-Cycle según sea necesario hasta que se corrijan todos los errores.

Antes de proceder 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 destinatario de AEM. Según 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, indexar a medida para optimizar la búsqueda o usar nodos no ordenados en JCR, entre otros.

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

Como se mencionó anteriormente y se muestra en el diagrama siguiente, la ejecución del 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.5. Consulte la página Compatibilidad con versiones anteriores en AEM 6.5 para obtener más información.
opt_cropped

Actualizar la base de código

Crear una rama dedicada para el código 6.5 en el control de versiones

Todo el código y las configuraciones necesarias para la implementación de su AEM deben administrarse 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 destinatario de AEM. En esta rama se gestionarán pruebas iterativas de la base de código con respecto a la versión de destinatario de AEM y las posteriores correcciones de errores.

Actualice la versión de AEM Uber Jar

El tarro de AEM Uber incluye todas las API de AEM como una sola dependencia en el pom.xml del proyecto de Maven. Siempre es recomendable incluir Uber Jar como una dependencia única en lugar de incluir dependencias de API de AEM individuales. Al actualizar la base de código, se debe cambiar la versión de Uber Jar para que apunte a la versión de destinatario de AEM. Si su proyecto se desarrolló en una versión de AEM antes de la existencia de Uber Jar, todas las dependencias de API de AEM individuales deben eliminarse y reemplazarse por una sola inclusión de Uber Jar para la versión de destinatario 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 destinatario de AEM.

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

Elimine gradualmente el uso de Resolver recursos administrativos

El uso de una sesión administrativa a través de SlingRepository.loginAdministrative() y ResourceResolverFactory.getAdministrativeResourceResolver() fue bastante frecuente en las bases de códigos anteriores a la 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 redimensionar cualquier código para utilizar usuarios de servicios. Puede encontrar más información sobre los usuarios de servicios y cómo eliminar las sesiones administrativas aquí.

Índices de consultas y robles

Cualquier uso de consultas en la base de código debe probarse a fondo como parte de la actualización de la base de código. Para los clientes que se actualizan desde Jackrabbit 2 (versiones de AEM anteriores a 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 predeterminadas pueden haber cambiado y podrían afectar a las consultas existentes.

Existen varias herramientas para analizar e inspeccionar el rendimiento de la consulta:

Creación de IU clásica

La creación de la IU clásica aún está disponible en AEM 6.5, pero está en desuso. Puede encontrar más información aquí. Si la aplicación se está ejecutando actualmente en el entorno de creación de la IU clásica, se recomienda actualizar a AEM 6.5 y seguir usando la IU clásica. La migración a la IU táctil se puede planificar como un proyecto independiente que se completará en varios ciclos de desarrollo. Para utilizar la IU clásica en AEM 6.5, se necesitan varias configuraciones de OSGi que se confirmen en la base de código. Encontrará más detalles sobre cómo configurar esto aquí.

Alinear con la estructura de repositorio 6.5

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

Por lo tanto, se debe mover una serie de configuraciones para que dejen de residir en /etc como en el pasado. Para revisar el conjunto completo de problemas de reestructuración de repositorios que deben revisarse y adaptarse en la actualización a la AEM 6.4, consulte Reestructuración de repositorios en la AEM 6.4.

Personalizaciones de AEM

Es necesario identificar todas las personalizaciones del entorno de creación de AEM en la versión de origen de AEM. Una vez identificadas, 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 destinatario de AEM antes de una actualización de producción.

Superposiciones en general

Es una práctica común extender AEM de la funcionalidad preestablecida superponiendo nodos y/o archivos en /libs con nodos adicionales en /apps. Estas superposiciones deben rastrearse en el control de versiones y probarse con la versión de destinatario de AEM. Si un archivo (ya sea JS, JSP, HTL) está superpuesto, se recomienda dejar un comentario sobre qué funcionalidad se ha aumentado para facilitar las pruebas de regresión en la versión de destinatario de AEM. Encontrará más información sobre las superposiciones en general aquí. A continuación encontrará instrucciones para superposiciones de AEM específicas.

Actualización de Forms de búsqueda personalizada

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 la búsqueda personalizada en Forms.

Personalizaciones de la interfaz de usuario de recursos

NOTA

Este procedimiento solo es necesario para las actualizaciones de versiones anteriores a AEM 6.2.

Las instancias que tienen implementaciones personalizadas de Recursos 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 Recursos de la siguiente manera:

  1. En la instancia que debe actualizarse, abra el CRXDE Lite en https://server:port/crx/de/index.jsp

  2. Vaya al nodo siguiente:

    • /apps/dam/content
  3. Cambie el nombre del nodo de contenido a content_backup. Para ello, haga clic con el botón derecho en el panel del explorador en el lado izquierdo de la ventana y elija Cambiar nombre.

  4. Una vez que se haya cambiado el nombre del nodo, cree un nuevo nodo denominado content en /apps/dam denominado content y defina su tipo de nodo en sling:Folder.

  5. Mueva todos los nodos secundarios de content_backup al nodo de contenido recién creado. Para ello, haga clic con el botón derecho en cada nodo secundario del panel del explorador y seleccione Mover.

  6. Elimine el nodo content_backup.

  7. Los nodos actualizados debajo de /apps/dam con el tipo de nodo correcto de sling:Folder deberían guardarse en control de versiones e implementarse con la base de código o, como mínimo, con una copia de seguridad como paquete de contenido.

Generación de ID de recursos para recursos existentes

Para generar ID de recursos para recursos existentes, actualice los recursos al actualizar la instancia de AEM para que se ejecute AEM 6.5. Esto es necesario para habilitar la función Perspectivas de recursos. Para obtener más información, consulte Añadir código incrustado.

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

1487758945977

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

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

Personalizaciones de secuencias de comandos de InDesign

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

Recuperación de configuraciones de ContextHub

Las configuraciones de ContextHub se ven afectadas por una actualización. Encontrará aquí instrucciones sobre cómo recuperar las configuraciones existentes de ContextHub.

Personalizaciones del flujo de trabajo

Es una práctica común actualizar los flujos de trabajo de modificación inmediata para agregar o eliminar funciones no necesarias. Un flujo de trabajo común personalizado es el recurso de actualización de DAM flujo de trabajo. Todos los flujos de trabajo requeridos para una implementación personalizada deben ser respaldados y almacenados en el control de versiones, ya que se pueden sobrescribir durante una actualización.

Plantillas editables

NOTA

Este procedimiento solo es necesario para las actualizaciones de sitios mediante plantillas editables de AEM 6.2

La estructura de las plantillas editables cambió entre AEM 6.2 y 6.3. Si está actualizando desde la versión 6.2 o anterior y si el contenido del sitio se genera con plantillas editables, deberá utilizar la Herramienta de limpieza de nodos interactivos. La herramienta está pensada para ejecutar después de una actualización para limpiar el contenido. Tendrá que ejecutarse tanto en los niveles de autor como de publicación.

Cambios en la implementación de CUG

La implementación de los 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 6.3 y la nueva implementación solo se admite en la IU táctil. Si está actualizando desde 6.2 o anterior, las instrucciones para migrar a la nueva implementación de CUG se pueden encontrar aquí.

Procedimiento de prueba

Debe prepararse un plan de pruebas completo para realizar pruebas de actualización. La prueba de la base del código actualizado y la aplicación deberán realizarse primero en entornos inferiores. Los errores encontrados deben corregirse de forma iterativa hasta que la base de código sea estable, solo entonces se actualizarán los entornos de nivel superior.

Prueba del procedimiento de actualización

El procedimiento de actualización, como se describe aquí, debe probarse en entornos Dev y QA, como se documenta en el libro de ejecución personalizado (consulte Planificación de la actualización). El procedimiento de actualización debe repetirse hasta que todos los pasos se documenten en el libro de ejecución de la actualización y el proceso de actualización sea fluido.

Áreas de prueba de implementación

A continuación se indican las áreas críticas de cualquier implementación de AEM que debe cubrir el plan de prueba una vez que se haya actualizado el entorno y se haya implementado la base de códigos actualizada.

Área de prueba funcional Descripción
Sitios publicados Prueba de la implementación de AEM y el código asociado en el nivel de publicación
mediante el despachante. Debe incluir criterios para las actualizaciones de página y la invalidación de la caché
.
Creación Prueba de la implementación de AEM y el código asociado en el nivel Autor. Debe incluir la creación de páginas, componentes y cuadros de diálogo.
Integraciones con soluciones de Marketing Cloud Validación de integraciones con productos como Analytics, DTM y Destinatario.
Integraciones con sistemas de terceros Todas las integraciones de terceros deben validarse en los niveles Autor y Publicación.
Autenticación, seguridad y permisos Se deben validar todos los mecanismos de autenticación como LDAP/SAML.
Los permisos y grupos deben probarse tanto en Autor como en
Publicadores.
Consultas Los índices y consultas personalizados deben probarse junto con el rendimiento de la consulta.
Personalizaciones de la interfaz de usuario Cualquier extensión o personalización de la IU de AEM en el entorno de creación.
Flujos de trabajo Flujos de trabajo y funcionalidades personalizados y/o listos para usar.
Prueba de rendimiento Las pruebas de carga deben realizarse en los niveles Autor y Publicación que simulan escenarios reales.

Resultados y plan de pruebas de documento

Debe crearse un plan de prueba que abarque las áreas de prueba de implementación mencionadas. En muchos casos, tiene sentido separar el plan de prueba por listas de creación y tarea de publicación. Este plan de prueba debe ejecutarse en 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 inferiores para proporcionar una comparación al actualizar los entornos de fase y producción.

En esta página