Actualizar código y personalizaciones upgrading-code-and-customizations

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

Información general overview

Antes de continuar con la actualización, debe tener una base de código de aplicación estable que se haya probado exhaustivamente con AEM 6.5 LTS.

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

Crear una rama dedicada para el código LTS 6.5 en el control de versiones create-a-dedicated-branch-for-6.5-lts-code-in-version-control

Todo el código y las configuraciones necesarios para la implementación de AEM deben administrarse mediante algún tipo de control de versiones. Se debe crear una rama dedicada en el control de versiones para administrar los cambios necesarios para el código base en la versión de destino de AEM. En esta rama se gestionan las pruebas iterativas del código base con la versión de destino de AEM y las correcciones de errores subsiguientes.

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

AEM Uber jar incluye todas las API de AEM como una sola dependencia en pom.xml de su proyecto Maven. Siempre es recomendable incluir Uber Jar como una sola dependencia en lugar de incluir dependencias de API de AEM individuales. Al actualizar el código base, cambie la versión de Uber Jar para que apunte a la versión 6.5 LTS de AEM. Actualice las API o los métodos obsoletos para que sean compatibles con la versión de destino de AEM. Recompile el código base con la nueva versión de Uber Jar.

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

Uber Jars para AEM 6.5

Uber Jars for AEM 6.5 LTS

Para AEM 6.5 LTS, hay de nuevo dos tipos de Uber Jars:

Diferencia clave: AEM 6.5 frente a AEM 6.5 LTS Uber Jars

Coordenadas Maven para Jar de API obsoletas

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

Notas del desarrollador developer-notes

Procedimiento de prueba testing-procedure

Se debe preparar un plan de pruebas completo para probar las actualizaciones. La aplicación y la base de código actualizadas deben probarse 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 deben actualizarse los entornos de nivel superior.

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

El procedimiento de actualización como se describe aquí debe probarse en los entornos de desarrollo y control de calidad, tal como se documenta en su manual 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 manual 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 deben incluirse en el plan de prueba una vez que se haya actualizado el entorno y se haya implementado la base de código actualizada.

Documentar el plan y los resultados de prueba document-test-plan-and-results

Debe crearse un plan de pruebas que cubra las áreas de prueba de implementación mencionadas anteriormente. A menudo, tiene sentido separar el plan de prueba por las listas de tareas Autor y Publicar. Este plan de prueba debe ejecutarse en los entornos de desarrollo, control de calidad y ensayo 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 ensayo y producción.