Go-Live

En esta parte del recorrido, aprenderá a planificar y realizar la migración una vez que el código y el contenido estén listos para moverse a AEM as a Cloud Service. Además, aprenderá cuáles son las prácticas recomendadas y las limitaciones conocidas al realizar la migración.

La historia hasta ahora

En las fases anteriores del recorrido:

  • You learned how to get started with the move to AEM as a Cloud Service in the Getting Started page.
  • Determined if your deployment is ready to be moved to the cloud by reading the Readiness phase
  • Familiarícese con las herramientas y el proceso a través del cual puede preparar su código y la nube de contenido con el Fase de implementación.

Objetivo

Este documento le ayudará a comprender cómo realizar la migración a AEM as a Cloud Service una vez que esté familiarizado con los pasos anteriores del recorrido. Aprenderá a realizar la migración inicial de producción, así como las prácticas recomendadas a seguir al migrar a AEM as a Cloud Service.

Migración de producción inicial

Before you can perform the production migration, please follow the fitment and proof of migration steps outlined in the Content migration strategy and timeline section of the Implementation phase.

  • Inicie la migración desde la producción en función de la experiencia adquirida durante la migración de la fase as a Cloud Service AEM realizada en los clones:

    • Author-Author
    • Publish-Publish

  • Validate the content ingested into both the AEM as a Cloud Service author and publish tiers.

  • Indica al equipo de creación de contenido que evite mover contenido tanto en el origen como en el destino hasta que se complete la ingesta

  • Se puede añadir, editar o eliminar contenido nuevo, pero evite moverlo. Esto se aplica tanto al origen como al destino.

  • Registre el tiempo empleado para la extracción e ingesta completas con una estimación de futuros cronogramas de migración adicionales.

  • Cree un planificador de migración tanto para autor como para publicación.

Ventajas principales incrementales

Después de la migración inicial desde la producción, debe realizar recargas incrementales para asegurarse de que el contenido se actualiza en la instancia de la nube. Por este motivo, se recomienda seguir estas prácticas recomendadas:

  • Recopile datos sobre la cantidad de contenido. Por ejemplo: por semana, dos semanas o un mes.
  • Asegúrese de planificar las recargas de forma que evite más de 48 horas de extracción e ingesta de contenido. Esto se recomienda para que las recargas de contenido encajen en un lapso de tiempo de fin de semana.
  • Planifique el número de recargas necesarias y utilice esas estimaciones para planificar la fecha de lanzamiento.

Identificar las cronologías de código y congelación de contenido para la migración

Como se mencionó anteriormente, tendrá que programar un período de congelación de código y contenido. Utilice las siguientes preguntas para ayudarle a planificar el periodo de congelación:

  • ¿Cuánto tiempo debo congelar las actividades de creación de contenido?
  • ¿Durante cuánto tiempo debo pedir a mi equipo de envío que deje de agregar nuevas funciones?

Para responder a la primera pregunta, debe tener en cuenta el tiempo que se ha tardado en realizar ejecuciones de prueba en entornos que no sean de producción. Para responder a la segunda pregunta, necesita una estrecha colaboración entre el equipo que agrega nuevas funciones y el equipo que refactoriza el código. El objetivo debe ser asegurarse de que todo el código que se agrega a la implementación existente también se agregue, pruebe e implemente en la rama de servicios en la nube. En términos generales, esto significa que la cantidad de congelación de código será menor.

Además, debe planificar un congelamiento de contenido cuando se programe el resumen final del contenido.

Prácticas recomendadas

Al planificar o realizar la migración, debe tener en cuenta las siguientes directrices:

  • Migrar de autor a autor y publicar para publicación
  • Solicite un clon de producción que se pueda utilizar para:
    • Capture repository statistics
    • Prueba de las actividades de migración
    • Preparación del plan de migración
    • Identificar los requisitos de congelación de contenido
    • Identifique cualquier necesidad de ampliación en Producción al realizar la migración desde la producción

Prácticas recomendadas de la herramienta de transferencia de contenido

Asegúrese de que, al activarse, ejecute la migración de contenido en producción en lugar de en un clon. Un buen enfoque es usar AZCopy para la migración inicial y luego ejecute las extracciones superiores con frecuencia (incluso diariamente) para extraer trozos más pequeños y para evitar cualquier carga a largo plazo en la AEM de origen.

Al realizar la migración de producción, debe evitar ejecutar la herramienta de transferencia de contenido desde un clon porque:

  • Si un cliente requiere que las versiones de contenido se migren durante las migraciones superiores, la ejecución de la herramienta de transferencia de contenido desde un clon no migra las versiones. Incluso si el clon se vuelve a crear con frecuencia desde el autor activo, cada vez que se crea un clon se restablecen los puntos de comprobación que utilizará la herramienta de transferencia de contenido para calcular los deltas.
  • Dado que un clon no se puede actualizar como un todo, el paquete ACL Query debe utilizarse para empaquetar e instalar el contenido que se está añadiendo o editando de producción a clon. El problema con este enfoque es que cualquier contenido eliminado en la instancia de origen nunca llegará al clon a menos que se elimine manualmente tanto del origen como del clon. Esto introduce la posibilidad de que el contenido eliminado en la producción no se elimine en el clon y AEM as a Cloud Service.

Optimización de la carga en el origen de AEM al realizar la migración de contenido

Recuerde que la carga en el origen de AEM será buena durante la fase de extracción. Debe tener en cuenta que:

  • La herramienta de transferencia de contenido es un proceso Java externo que utiliza un JVM Heap de 4 GB
  • La versión que no es de AzCopy descarga binarios, los almacena en un espacio temporal en el autor de la AEM de origen, lo que consume E/S de disco y, a continuación, carga en el contenedor de Azure que consume ancho de banda de la red
  • AzCopy transfiere blobs directamente desde el almacén de blobs al contenedor de Azure, que ahorra E/S de disco y ancho de banda de red. La versión de AzCopy todavía utiliza el disco y el ancho de banda de red para extraer y cargar los datos del almacén de segmentos en el contenedor de Azure
  • El proceso de la herramienta de transferencia de contenido es más ligero en los recursos del sistema durante la fase de ingesta, ya que solo transmite registros de ingesta y no hay mucha carga en la instancia de origen en lo que se refiere a E/S de disco o ancho de banda de red.

Limitaciones conocidas

Tenga en cuenta que la ingesta completa falla si se encuentra alguna de las siguientes limitaciones como parte del conjunto de migración extraído:

  • Nodo JCR con un nombre superior a 150 caracteres
  • Nodo JCR mayor de 16 MB
  • Cualquier usuario o grupo con rep:AuthorizableID ingesta que ya está presente en AEM as a Cloud Service
  • Si cualquier recurso extraído e ingerido se mueve a una ruta diferente, ya sea en el origen o en el destino, antes de la siguiente iteración de la migración.

Estado de los recursos

Comparado con la sección anterior a la ingesta no falla debido a las siguientes preocupaciones sobre los activos. Sin embargo, es muy recomendable que realice los pasos adecuados en estos casos:

  • Falta cualquier recurso que tenga la representación original
  • Cualquier carpeta que falte jcr:content node

Los dos elementos anteriores se identificarán y presentarán informes en la Analizador de prácticas recomendadas informe.

Go-Live Checklist

Revise esta lista de actividades para asegurarse de que realiza una migración sin problemas y sin problemas.

  • Ejecute una canalización de producción completa con pruebas funcionales y de interfaz de usuario para garantizar un always current AEM experiencia del producto. Consulte los siguientes recursos.
  • Migre contenido a producción y asegúrese de que hay un subconjunto relevante disponible en el entorno de ensayo para realizar pruebas.
    • Tenga en cuenta que las prácticas recomendadas de DevOps para AEM implican que el código sube del desarrollo al entorno de producción mientras que el contenido baja de los entornos de producción.
  • Programe un período de congelación de contenido y código.
  • Realice el resumen final del contenido.
  • Valide las configuraciones de Dispatcher.
    • Utilice un validador de Dispatcher local que facilite la configuración, validación y simulación del Dispatcher localmente
    • Revise detenidamente la configuración del host virtual.
      • La solución más sencilla (y predeterminada) es incluir ServerAlias * en el archivo host virtual de /dispatcher/src/conf.d/available_vhostsfolder.
        • Esto permitirá que funcionen los alias de host utilizados por las pruebas funcionales del producto, la invalidación de la caché de Dispatcher y los clones.
      • Sin embargo, si ServerAlias * no es aceptable, como mínimo lo siguiente ServerAlias además de los dominios personalizados:
        • localhost
        • *.local
        • publish*.adobeaemcloud.net
        • publish*.adobeaemcloud.com
  • Configure CDN, SSL y DNS.
  • Ejecute pruebas de rendimiento y seguridad que cumplan con los requisitos y objetivos de su negocio.
  • Realice un corte y asegúrese de que el lanzamiento real se realiza sin ninguna implementación nueva o actualización de contenido.

Siempre puede hacer referencia a la lista en caso de que necesite volver a calibrar las tareas mientras realiza la migración.

Siguientes pasos

Una vez que sepa cómo realizar la migración a AEM as a Cloud Service, puede comprobar la variable Publicar Go-Live para mantener la instancia funcionando sin problemas.

En esta página