Migración de contenido de producción de AEM a QA y DEV
Los probadores de control de calidad se enfrentan a un dilema al validar nuevas compilaciones: quieren tener casos de prueba del mundo real, pero es difícil recrear el contenido de producción real.
Los autores de contenido crean (y publican) contenido nuevo dentro del autor de producción todo el tiempo. ¡La cantidad de contenido puede ser mucha! Algunas empresas impulsan 100, si no 1,000 páginas al día. ¿Cómo puede un equipo de probadores de control de calidad asegurarse de que el nuevo contenido que se crea funciona con las últimas compilaciones de desarrollo que se están probando? ¿Qué sucede si hay cambios importantes que no están cubiertos por el contenido de prueba generado dentro de QA con fines de prueba? ¡Estas brechas no se notarán hasta que la última versión se envíe a producción!
¿Cuál es la solución? ¡Simple, migre el contenido de producción real al entorno de control de calidad!
Sin embargo, migrar este contenido no es trivial. Hay un par de opciones (algunas se tratarán en publicaciones posteriores). Un método es realizar migraciones con la herramienta VLT de línea de comandos. Esta herramienta se puede utilizar para realizar sincronizaciones regulares de contenido PROD en sus entornos de nivel inferior (por ejemplo, todos los domingos a las 2 a.m.) o bajo demanda (directamente antes de que comiencen las pruebas). También tiene control sobre qué contenido se mueve de PROD a DEV/QA y no necesita enviar todo el repositorio de contenido, sino solo un subconjunto o un árbol de contenido de destino (ejemplo: /content/en_us/site/test
).
He publicado una versión genérica de un vlt rcp
el guión que comencé a escribir para la migración inicial de adobe.com en 2012. He estado usando esto desde esa actualización / migración (pasamos de 5.3 a > 5.5 y lanzamos el primer sitio CQ 5.5 en todo el mundo). El script se puede encontrar en nuestro repositorio público de gitlab. Las variables dentro del script y cómo usarlo se documentan en el archivo README correspondiente.
Por lo general, ejecutaríamos este script a pedido (./vlt_rcp_content_sync.sh
) o lo programaríamos a través de un trabajo cron para que se ejecute a un intervalo regular. Esto debería programarlo para que se ejecute el 1er y 3er domingo a las 2 a.m., por ejemplo:
0 2 1-7,15-21 * * [ `date +\%u` = 7 ] && /
/vlt_rcp_content_sync.sh
¿Te gusta lo que escuchaste? ¿Tiene preguntas sobre lo que es adecuado para usted? ¡Nos encantaría hablar! Contáctenos