Actualización de código y personalizaciones

Al planificar 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 detector de patrones que contenga más detalles sobre las áreas que se deben abordar, además de las API o paquetes no disponibles en la versión de AEM de Target. El informe Detección de patrones debería darle una indicación de cualquier incompatibilidad en su código. Si no hay ninguna, entonces la implementación ya es compatible con la versión 6.4, puede optar por hacer un nuevo desarrollo para utilizar la funcionalidad 6.4, pero no lo necesita solo para mantener la compatibilidad. Si se notifican incompatibilidades, puede elegir entre a) Ejecutar en modo de compatibilidad y aplazar el desarrollo para nuevas funciones o compatibilidad de 6.4, b) Decidir hacer desarrollo después de la actualización y pasar al paso 2. Consulte la Compatibilidad con versiones anteriores en AEM 6.4 para obtener más información.

  2. Desarrollo de la base de código para 6.4 : cree una rama o repositorio dedicado para el código base para la versión de Target. Utilice la información de Compatibilidad previa a la actualización para planificar las áreas de código que se actualizarán.

  3. Compilar con 6.4 Uber jar : Actualice los POMs de base de código para que apunten a 6.4 uber jar y compile código en contra de esto.

  4. Actualizar AEM personalizaciones : cualquier personalización o extensión que AEM debe actualizarse o validarse para funcionar en la versión 6.4 y agregarse a la base de código 6.4. Incluye Búsqueda de IU Forms, Personalizaciones de recursos, cualquier cosa que utilice /mnt/overlay

  5. Implementar en entorno 6.4 : Se debe instalar una instancia limpia de AEM 6.4 (Autor + Publicación) en un entorno de desarrollo/control de calidad. Se debe implementar una base de código actualizada y una muestra de contenido representativa (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 tanto en la instancia de autor como en la de publicación de 6.4. Cualquier error encontrado debe corregirse y confirmarse en la base de código de 6.4. Repita el ciclo de desarrollo según sea necesario hasta que se corrijan todos los errores.

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 menciona más arriba y se muestra en el diagrama siguiente, ejecutar Pattern Detector 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 página Compatibilidad con versiones anteriores en AEM 6.4 para obtener más información.
screen_shot_2018-03-30at175257

Actualizar la base de código

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

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.

Actualizar la versión de AEM Uber Jar

El AEM Uber jar incluye todas las API de AEM como una sola dependencia en el pom.xml de su proyecto Maven. 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

El uso de una sesión administrativa a través de 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, se eliminarán estos métodos. Se recomienda refactorizar cualquier código para utilizar usuarios de servicios en su lugar. Puede encontrar más información sobre los usuarios de servicios y cómo eliminar sesiones administrativas aquí.

Consultas e índices Oak

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 se deban 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

La creación de IU clásica sigue disponible en AEM 6.4, pero está en desuso. Puede encontrar más información aquí. 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. Puede encontrar más detalles sobre cómo configurar esto aquí.

NOTA

Para ayudarle a abandonar la IU clásica y aprovechar las últimas tecnologías de AEM, considere la posibilidad de aprovechar las AEM Herramientas de modernización para facilitar la migración.

Alinear con la estructura del repositorio 6.4

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 había sido el caso 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, 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 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

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 aquí. A continuación se encuentran las 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 Forms de búsqueda personalizada.

Personalizaciones de la interfaz de usuario de Assets

NOTA

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

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:

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

  2. Vaya al siguiente nodo:

    • /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 establezca 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 idealmente deben guardarse en el control de versiones e implementarse con el código base o con una copia de seguridad mínima como paquete de contenido.

Generación de ID de recursos para recursos existentes

Para generar ID de recursos para recursos existentes, actualice los recursos cuando actualice la instancia de AEM para ejecutar AEM 6.4. Esto es necesario para habilitar la función 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. Dependiendo del número de recursos en el 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 cualquier otro propósito, utilice la API migrateAllAssets().

Personalizaciones de scripts de InDesign

Adobe recomienda colocar scripts personalizados en la ubicación /apps/settings/dam/indesign/scripts . Puede encontrar más información sobre las personalizaciones de los scripts de InDesign aquí.

Recuperación de las configuraciones de ContextHub

Las configuraciones de ContextHub se realizan mediante una actualización. Las instrucciones sobre cómo recuperar las configuraciones existentes de ContextHub se encuentran aquí.

Personalizaciones de flujo de trabajo

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

NOTA

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

La estructura de las plantillas editables cambió 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á utilizar la Herramienta de limpieza de nodos interactivos. La herramienta está diseñada para ejecutar después 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 de CUG

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, las instrucciones para migrar a la nueva implementación de CUG se encuentran aquí.

Procedimiento de prueba

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

El procedimiento de actualización descrito aquí debe probarse en entornos de desarrollo y control de calidad tal 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

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.

Á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
a través de Dispatcher. Debe incluir criterios para las actualizaciones de página y la invalidación de 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 Target.
Integraciones con sistemas de terceros Las integraciones de terceros deben validarse en los niveles Author y Publish .
Autenticación, seguridad y permisos Cualquier mecanismo de autenticación como LDAP/SAML debe validarse.
Los permisos y grupos deben probarse tanto en Autor como en
Publicadores.
Consultas Los índices personalizados y las consultas deben probarse junto con el rendimiento de la consulta.
Personalizaciones de la interfaz de usuario Las extensiones o personalizaciones de la interfaz de usuario de AEM en el entorno de creación.
Flujos de trabajo Flujos de trabajo y funciones personalizados y/o listos para usar.
Pruebas de rendimiento Las pruebas de carga deben realizarse en los niveles Author y Publish que simulen escenarios reales.

Plan y resultados de prueba de documento

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.

En esta página

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now