Migración de un sitio de producción production-migration
Utilice este flujo de trabajo para mover una lista acordada de páginas a Edge Delivery Services, el servicio de Adobe Experience Manager que ofrece sitios web. Comience con una página de muestra para cada plantilla, establezca cómo su contenido y diseño se asignan al nuevo sitio e importe más páginas solo una vez que las muestras funcionen en el editor que utilizarán los autores. Si los términos como bloques, contenido predeterminado o vista previa son nuevos para usted, vea Cómo se crea y actualiza su sitio y Dar forma a la estructura de contenido.
Para ver algunas páginas de demostración o una primera evaluación, use los flujos de trabajo de demostración y prueba más pequeños. No necesitan las comprobaciones que necesita un sitio de producción antes del lanzamiento.
Acordar ámbitos y destinos scope
El responsable de la migración y el arquitecto coinciden en el ámbito y los destinos. Necesita autorización para leer el origen, modificar el repositorio de destino y escribir contenido y recursos en el destino. Acordar quién firma el resultado y quién autoriza la liberación. Si algunas páginas requieren inicio de sesión, configure autenticación de sitio protegido con una cuenta de solo lectura dedicada. Si el origen bloquea los visitantes automatizados, organice el acceso con su administrador antes de catalogar. Ver Sitios Source con protección para bots.
Registro:
La importación de páginas copia el contenido y el diseño de cada página. Las integraciones y funciones de CMS se ejecutan en los servidores de origen, como la búsqueda, el procesamiento de formularios, las reglas de personalización y la herencia de contenido, de modo que la importación copia únicamente su salida en cada página. Enumérelos en Comportamiento y decida cómo funciona cada uno en el nuevo sitio. Ver limitaciones.
Un espacio de trabajo de la consola funciona en un sitio a la vez. En un programa con varios sitios, acepte su pedido y envíe y cargue el trabajo de cada sitio antes de abrir el siguiente con Cambiar sitio.
Volver a iniciar un sitio que se ejecute en Experience Manager relaunch-aem-site
Una vez que el equipo haya decidido el relanzamiento, el flujo de trabajo es el mismo que para cualquier otra fuente. Estos puntos son específicos de una fuente de Experience Manager:
- Sus otros sitios: El agente lee las páginas del sitio de origen y no cambia el origen. Solo escribe en el repositorio Git del nuevo sitio y en el destino de contenido que elija, de modo que los demás sitios de Experience Manager de su organización se siguen ejecutando tal cual, al igual que el sitio de origen hasta que cambie su dominio a release. Con la creación de Experience Manager, la carga escribe páginas en
/content/{site-name}e imágenes en la carpeta Assets del sitio y reemplaza cualquier página que ya esté en esa ruta, por lo que debe ponerse de acuerdo con el administrador de la instancia de autor. Ver Cargar contenido. - Cómo lee el agente el origen: El agente lee cada página cuando un explorador la procesa, no los componentes, plantillas o repositorio del origen. Por lo tanto, los componentes, los fragmentos de experiencias y la herencia de contenido no se transmiten como tales: su salida aparece en cada página. Decida qué contenido compartido desea conservar una vez en el nuevo sitio. Ver Lo Que Queda De Trabajo En El Proyecto.
- Adónde va el contenido: El destino es su elección, como para cualquier fuente; consulte Dónde se almacena el contenido y cómo lo editan los autores. La creación de Experience Manager necesita una instancia de autor de as a Cloud Service de Experience Manager, por lo que una instancia de autor que se ejecute en otra parte no puede ser el destino.
- Repositorios: Si su código está en un repositorio conectado a través de Cloud Manager, la consola también funciona con él. Ver Usar otro host Git.
- Decisiones para su equipo: Los idiomas, la herencia entre mercados y los flujos de trabajo de aprobación son decisiones de su equipo. La importación le proporciona las páginas en sus rutas de origen, no estas estructuras. Registre estos datos con las demás decisiones de ámbito antes de catalogarlos.
Preparar y catalogar prepare
- Siga la configuración de la consola compartida o la configuración de creación de Experience Manager si el contenido va a la creación de Experience Manager. Reutilice la configuración de un proyecto existente en lugar de volver a crearla.
- Pida al agente que capture el sitio autorizado:
Scope site https://www.example.com. El catálogo de sitios detecta páginas y las agrupa en plantillas (páginas que comparten un diseño) y variantes de bloque. - Revise el catálogo en la vista de Planning. Corrija las agrupaciones de plantillas y bloques e investigue las direcciones URL fallidas.
- Compare las direcciones URL descubiertas con la lista de páginas acordada. Añada páginas que no haya pasado por alto en la detección y decida explícitamente si las direcciones URL han fallado, se han omitido, se han duplicado o están excluidas.
- Elija una página de muestra para cada plantilla y variante importante. Cubra contenido largo, imágenes inusuales, configuraciones regionales y páginas con mucha interacción.
La catalogación lee el origen y no importa nada. Una ejecución con el estado completado puede seguir teniendo páginas con errores; consulte Resultados y estado. Antes de continuar, asigne a cada URL de ámbito una plantilla o una exclusión aprobada.
Cómo migra el agente a escala migration-at-scale
El agente no envía todas las páginas a través del modelo de IA. Interpretar cada página por separado no se escalaría a miles de páginas, y el modelo podría tratar páginas similares de manera ligeramente diferente cada vez. En su lugar, el modelo de IA procesa la asignación en una página de muestra por plantilla y el agente convierte esa asignación en código que se ejecuta en las demás páginas de la plantilla:
- Agrupar páginas en plantillas. El catálogo de sitios agrupa las páginas del sitio de origen en plantillas, que son páginas que comparten un diseño. Si migra páginas sin catálogo, cada página que asigne inicia una plantilla propia.
- Migrar una página de muestra. Para cada plantilla, el agente primero migra una página real que muestra el diseño típico de la plantilla y, preferiblemente, la mayoría de sus bloques y variantes. El catálogo del sitio propone uno para cada plantilla. Si otra página de la plantilla muestra más bloques, elija esa página en su lugar: los bloques de los que carece la página de muestra solo se añaden más adelante, cuando una página importada los necesita. El modelo de IA asigna el contenido de la página de muestra al contenido y los bloques predeterminados, y crea los bloques que necesita o reutiliza los existentes.
- Generar un script de importación. El agente escribe un script de importación para la plantilla: una parte, el analizador, extrae el contenido de cada bloque del HTML de origen y otra, el transformador, limpia la página en su totalidad. Los scripts son archivos JavaScript en la carpeta
tools/importer/del proyecto, con versiones en Git con el resto del código. - Refine el patrón, no la página. Cuando solicita una corrección, el agente cambia el bloque o el script de importación que produjo el resultado en lugar de editar el resultado de una página. A continuación, la corrección se aplica a todas las páginas de la plantilla y, posteriormente, las plantillas reutilizan los bloques que ya existen.
- Importar las páginas restantes de forma masiva. La importación masiva ejecuta el script de importación en las demás páginas de la plantilla sin que el modelo de IA interprete cada una de ellas. A continuación, el agente compara las páginas importadas con sus páginas de origen, corrige el script de importación para páginas que difieren demasiado y vuelve a importar esas páginas.
Valide algunas páginas de cada plantilla antes de importarlas todas. Ver Importar en lotes.
Lo mismo se aplica a los cambios en la estructura del contenido, como qué contenido se convierte en un bloque o dónde una página se divide en secciones: cambie el script de importación. Es un código que se revisa y combina como el resto y la siguiente importación lo aplica a todas las páginas de la plantilla. Una edición en una página importada permanece local y la importación de la plantilla de nuevo la sobrescribe.
Para cambiar las plantillas y los propios bloques, como mover páginas a otra plantilla o hacer que un bloque sea una variante de otro, usa la vista de Planning o pregunta en el chat. El agente sigue estos cambios la próxima vez que genera bloques o importa páginas, y las páginas que ya importó no cambian. Para consolidar el diseño, consulte Rediseñar sitios. Para consolidar el código de bloque, consulte Refactorizar sin cambiar el resultado.
template los que agregan una clase al elemento body de la página para que el código del proyecto pueda aplicar un estilo diferente a esas páginas. Para alinear ambos, pídale al agente que defina los metadatos en el script de importación, de modo que todas las páginas de la plantilla los obtengan en la importación, por ejemplo: "Para la plantilla de artículo, establezca los metadatos de página template en article en el script de importación, y dé a las páginas de artículo una columna principal más estrecha".Validar páginas de muestra representatives
El posible cliente, los diseñadores y los autores de la migración establecen la primera plantilla juntos. Comience con algunas de sus páginas. Por ejemplo:
Migrar solo estas páginas de productos:
https://www.example.com/products/tents,https://www.example.com/products/backpacksyhttps://www.example.com/products/boots. Almacene el contenido como contenido basado en documentos en/products. Conservar el texto, los vínculos, los metadatos y el significado de la imagen aprobados. Reutilice los bloques del proyecto y las convenciones de contenido. Notificar el contenido y las interacciones que faltan y que la importación no se reproduce. No cargue, inserte ni publique.
Reemplace las direcciones URL y rutas de ejemplo por las suyas propias y, para la creación de Experience Manager, diga que el contenido se almacena en el JCR.
-
Revise la estructura de contenido: las secciones, el contenido predeterminado, los bloques, las variantes y los estilos de sección que eligió el agente. Los autores editarán todas las páginas migradas en esta estructura, por lo que se establecerán en las páginas de muestra. Ver Dar forma a la estructura de contenido.
-
Comparar texto, vínculos, imágenes, metadatos y orden de sección importados con el origen. Cuando un patrón es incorrecto, corrija el script de importación, no la página. Ver Cómo migra el agente a escala.
-
Aplicar estilo de origen o seguir flujo de trabajo de rediseño. Compruebe los estilos globales antes de refinar los bloques individuales.
-
Rellene el encabezado, la navegación y el pie de página compartidos de forma independiente de la importación de páginas. El agente los migra, incluidas las imágenes de pie de página, una vez para todo el sitio, de modo que cada página comparta un encabezado y un pie de página.
-
Cargue una página de muestra al destino de contenido y, a continuación, edítela, guárdela, vuelva a abrirla y obtenga una vista previa de la misma:
- Carga y vista previa basadas en documentos.
- Conversión, carga de paquetes y comprobaciones en el editor universal para la creación de Experience Manager.
-
Registre la asignación acordada del origen a la salida, los modelos de bloque, las decisiones de diseño y las excepciones conocidas antes de importar más páginas.
Una página con aspecto correcto sigue fallando si los autores no pueden editarla. Para la creación de Experience Manager, compruebe también los modelos de bloques, la configuración de componentes generada, los errores de conversión y dónde se almacenan las imágenes antes de importar más.
Dar forma a la estructura de contenido content-structure
Los autores editan todas las páginas migradas en la estructura que el agente elige al importar y la importación masiva repite esa estructura en todas las páginas de una plantilla. Las páginas de Edge Delivery Services están formadas por secciones que contienen contenido y bloques predeterminados; consulte Marcado, secciones, bloques y bloqueo automático. El agente sigue el modelo de David y mantiene la estructura tan simple como el diseño lo permite, porque cada bloque y variante es una cosa más que los autores deben aprender.
cards-compact, para obtener una pequeña diferencia en la apariencia que eligen los autores. El contenido con diferentes campos o un trabajo diferente obtiene un bloque propio. El contenido opcional y un número diferente de elementos no constituyen una variante.dark, light-grey o centered. El texto y los botones de la sección toman su color del estilo, por lo que un color por sí solo nunca crea un bloque ni una variante.Para dirigir la estructura:
- Antes de migrar, revise el catálogo en la vista Planning y corrija allí los nombres de bloque y las agrupaciones. Consulte Refinamiento del catálogo.
- Registre los bloques, variantes y estilos de sección del proyecto en
AGENTS.md, de modo que el agente los vuelva a utilizar en páginas posteriores y en sesiones posteriores. Ver Convenciones de contenido de documento. - Compruebe cada página de muestra en la vista de documento del panel de vista previa, que muestra sus secciones, bloques y contenido predeterminado. Ver Vistas de contenido.
- Corrija un patrón incorrecto en el script de importación para que la importación masiva repita la corrección en todas las páginas. Ver Cómo migra el agente a escala.
- Pida a un autor que edite una página de muestra. Si dudan sobre qué bloque, variante o estilo utilizar, hay demasiadas opciones.
Conservar las opciones que los autores toman pocas. El sistema de diseño debe tomar las decisiones que los autores no deben tener que tomar: cuando un bloque necesita más que un puñado de variantes u opciones, pregúntele si algunas de ellas pertenecen al diseño.
Estimar antes de comprometer estimate
El catálogo y las primeras páginas de muestra le proporcionan una estimación basada en el trabajo que necesita el sitio, no en su recuento de páginas:
- Catalogar el sitio. El catálogo enumera las plantillas, las variantes de bloque y las configuraciones regionales, así como las direcciones URL que han fallado. Ver Preparar y catálogo.
- Validar páginas de muestra de las plantillas principales. Registre lo que cada uno necesitaba: nuevos bloques, correcciones para importar scripts, estilo y cambios en la estructura de contenido.
- Cambie el tamaño de las plantillas restantes según lo que necesiten las páginas de muestra. Las plantillas posteriores reutilizan los bloques que ya existen, por lo que cuenta los bloques que cada uno añade. Una página con un diseño propio cuenta como plantilla propia.
- Agregue los elementos que la importación no cubre: el comportamiento que registró en Comportamiento en el ámbito y el trabajo del proyecto que su equipo decide y genera.
Compare la estimación con el registro por URL del primer lote.
Trabajar como un equipo collaboration
Varias personas pueden trabajar en el mismo proyecto con el agente, cada una en su espacio de trabajo de la consola. Comparten código a través de Git y contenido a través del destino de contenido. La consola no muestra quién está trabajando en qué, y no combina los cambios de dos personas en la misma página, así que acuerden quién trabaja en qué y sigan hablando entre sí.
El ámbito importa más con un agente que sin uno. Una sola solicitud puede cambiar muchos archivos, por lo que cuando dos personas cambian los mismos bloques o estilos al mismo tiempo, alguien tiene que resolver los conflictos en muchos archivos a mano.
Liderar la migración phases
Una migración se ejecuta por fases. El agente realiza la mayor parte del trabajo repetitivo en cada una de ellas, y su equipo toma las decisiones y firma el resultado. Deje que una persona, como el jefe de la migración, ejecute las primeras fases; otras se unan una vez que se hayan resuelto los bloques y los scripts de importación. Ver Trabajar como un equipo.
Los colaboradores visuales pueden trabajar en el estilo desde la fase de páginas de muestra en adelante. Consulte Realizar cambios visuales.
Comience con una persona y luego divida el trabajo divide-work
Los primeros pasos sientan las bases sobre las que se basa todo lo demás: los estilos globales, los primeros bloques y los scripts de importación de las primeras plantillas. Deja que una persona los prepare. Antes de dividir el trabajo, compruebe que los bloques se ajusten al contenido real y que sean fáciles de usar para los autores. Ver Dar forma a la estructura de contenido.
Una vez que el equipo esté de acuerdo en los bloques, divida el trabajo para que la gente cambie diferentes archivos:
- Por bloque: Una persona refina el bloque de tarjetas mientras otra crea un carrusel.
- Por plantilla: Cada persona perfecciona el script de importación de una plantilla diferente. Ver Cómo migra el agente a escala.
- Por experiencia: Un diseñador perfecciona el estilo de los bloques existentes mientras un desarrollador crea una integración.
No asigne a dos personas el mismo bloque, los estilos globales o el mismo script de importación al mismo tiempo a menos que estén de acuerdo en cómo coordinarse.
Compartir código en pasos pequeños share-code
- Acordar una rama compartida, como
maino una rama de desarrollo. Cada persona cambia su área de trabajo a ella con Cambiar rama en la vista Código. - Mantenga cada solicitud al agente centrada en un bloque, plantilla o tarea. Inserte el resultado en cuanto funcione, con Crear nueva PR: la consola inserta los cambios en una nueva rama, abre una solicitud de extracción en la rama compartida y deja el área de trabajo en la nueva rama.
- Revise y fusione solicitudes de extracción con frecuencia. Los cambios pequeños entran en conflicto menos y se revisan más rápido, y una solicitud de extracción que permanece abierta durante días recopila conflictos.
- Antes de iniciar una tarea nueva, vuelve a la rama compartida con Cambiar rama y jálala con Sincronizar > Jalar > Código, para poder aprovechar el trabajo combinado de todos.
Si una extracción no está disponible o informa de un conflicto, consulte Si alguien más ha cambiado la rama.
Los pequeños y frecuentes empujones también le dan al equipo un historial legible de lo que el agente cambió y por qué. Para obtener una confirmación por solicitud, vea Dejar un registro de cada solicitud.
Coordinar cambios de contenido share-content
El contenido no tiene combinación. El espacio de trabajo contiene copias de las páginas y una carga de reemplaza la página del destino de contenido por su copia de. Si dos personas cambian la misma página, la última carga gana y los cambios de la otra persona se pierden. Asigne cada página o conjunto de páginas a una persona a la vez.
Para obtener páginas que otros usuarios hayan cargado en el espacio de trabajo:
- Abra una página que muestre un icono en la nube en la vista de contenido. La consola lo descarga en el espacio de trabajo.
- En proyectos basados en documentos, seleccione Sincronizar > Extraer > Contenido para descargar todas las páginas de Experience Workspace. Sustituye a las copias locales, incluidas las ediciones que no haya cargado, por lo que cargue primero las ediciones que desee conservar.
Importar en lotes batches
Use flujo de trabajo de importación masiva de catálogos y mensajes de importación masiva después de validar las páginas de muestra.
- Importe un pequeño lote con el script de importación de la plantilla.
- Compruebe las páginas normales y los casos extremos. Si el script de importación es incorrecto, corríjalo e importe de nuevo las páginas afectadas antes de continuar.
- Mantenga un registro para cada URL de origen: destino, estado de importación, errores, firma y cualquier exclusión aprobada.
- Continuar plantilla por plantilla. Recuento de páginas descubiertas, analizadas, importadas, fallidas, omitidas y cerradas por separado.
- Vuelva a comprobar las páginas de muestra anteriores al cambiar estilos compartidos, importar scripts, modelos de bloque o código de bloque.
Una vez que los autores empiezan a editar las páginas migradas en el destino de contenido, sus páginas se convierten en la fuente fiable. Volver a importar o cargar esas páginas sobrescribe el trabajo de los autores y un script de importación corregido no lo combina, por lo que debe ponerse de acuerdo primero con los autores.
Completar el sitio complete-site
La importación automatizada es una parte del envío. Implementar y verificar los requisitos acordados, incluyendo:
- Encabezado, pie de página, navegación, vínculos internos y páginas de error.
- Imágenes, descargas, fuentes, permisos de recursos y cualquier referencia de Dynamic Media conservada.
- Títulos, descripciones, URL canónicas, datos estructurados, redirecciones, mapas del sitio y relaciones de configuración regional cuando sea necesario.
- Forms, búsqueda, comercio, funciones de cuenta, análisis, consentimiento y otras integraciones.
- Guía del autor, propiedad operativa, acceso y configuración de implementación.
El agente implementa el lado del código de estos, por ejemplo bloques que llaman a la API de búsqueda o comercio, formularios y el código que carga Analytics y el consentimiento. No puede configurar sistemas fuera del repositorio y el contenido, como el servicio de búsqueda, la CDN o la cuenta de análisis, y no decide sus necesidades. Asigne la documentación de la API y el comportamiento acordado, y nombre un propietario para cada sistema externo que firme el resultado. Consulte Servicios y aplicaciones de Connect para obtener formularios, Envíos de formularios y para páginas de productos Páginas de Commerce.
Imágenes y documentos assets
La forma en que las imágenes llegan al nuevo sitio depende del destino del contenido:
- Experience Workspace: Mientras trabaja en la consola, una página importada puede seguir haciendo referencia a imágenes en el sitio de origen. Al cargar la página, la consola carga sus imágenes con ella, incluidas las imágenes que descarga desde el origen, en una carpeta denominada así por la página con un punto inicial. A continuación, dirige la página a las copias cargadas. Si falta una imagen, en un formato no compatible o ambigua, la consola lo informa y no carga la página. Después de la carga, comprueba que todas las imágenes han llegado. Ver Cargar contenido.
- Creación en Experience Manager: Seleccione Cargar imágenes al cargar el paquete de contenido y elija una carpeta en
/content/dam/. El valor predeterminado es/content/dam/site. Ver Cargar contenido. - Adobe Dynamic Media: Las imágenes que el origen proporciona desde Dynamic Media, incluidos Scene7 y Dynamic Media con direcciones URL de OpenAPI, permanecen allí. La página importada hace referencia a ellos y el código del proyecto los procesa.
Edge Delivery Services proporciona imágenes en tamaños y formatos que se ajustan a cada pantalla. Compruebe los archivos, vídeos e imágenes de SVG grandes con los límites para los tipos y tamaños de archivo.
Compruebe los vínculos a documentos, como PDF, en las páginas de ejemplo. Cada vínculo debe apuntar a una copia en el nuevo sitio, no al sitio de origen que va a retirar.
URL, redirecciones y metadatos de búsqueda urls-seo
El agente toma la ruta de cada página de su URL de origen. Utiliza minúsculas en la ruta de acceso, quita .html, convierte un(a) / final en index y reemplaza otros caracteres con guiones, como espacios y guiones bajos. /About_Us.html se convierte en /about-us. Cada URL que cambie de esta manera o que cambie a propósito necesita un redireccionamiento.
El agente no crea redirecciones, mapas del sitio ni alternativas de idioma por sí solo. Pídale que lo haga como una tarea y revise el resultado:
- Redirecciones: Una hoja de cálculo de
redirectscon Source y Destino columnas, una fila por URL, sin comodines. Pida al agente que indique las direcciones URL de origen cuya ruta ha cambiado, como filas para la hoja. Ver Redirecciones. - Metadatos de página: La importación mantiene el título, la descripción y la imagen social de cada página en su bloque de metadatos. Para establecer los metadatos de muchas páginas a la vez, use una hoja de cálculo de
metadata. Ver metadatos en lotes. - Mapa del sitio e idiomas: Un archivo de
helix-sitemap.yamlen el repositorio, que puede incluir las alternativas de idioma (hreflang) de cada página. Ver Mapas del sitio. - Motores de búsqueda: La vista previa y los sitios activos,
*.aem.pagey*.aem.live, están ocultos en los motores de búsqueda; su dominio de producción no lo está. Comprueberobots.txtantes del corte. Consulte robots.txt. - Índice de consultas: Listas de páginas, como listados de artículos y búsqueda de sitios, leídas desde un índice de consultas que incluye solamente páginas publicadas. Consulte Indexación.
Comprobar y cerrar sesión acceptance
Acuerde con el propietario del sitio lo que debe funcionar antes del lanzamiento y pruébelo en la vista previa y en los sitios activos. El propietario del sitio firma el resultado con los probadores y los autores.
Cada señal automatizada comprueba una cosa: un estado del importador que ejecutó la secuencia de comandos, un paquete generado que indicaba que el contenido se había convertido, una puntuación de similitud visual que indica que una página se parece a su origen y una puntuación de Lighthouse que indica cómo se carga una página en una prueba de laboratorio. La preparación para la producción necesita todas las áreas de la tabla.
Liberar, recuperar y entregar handoff
El propietario de la versión coordina la combinación de código, la publicación de contenido y la migración de dominios, y luego confirma que los propietarios actuales del sitio se han hecho cargo.
- Inserte el código firmado y haga que se revise según lo requiera la política del repositorio. Al combinar en
main, se actualiza inmediatamente el código del sitio activo, por lo que debe planificarse la combinación con el lanzamiento del contenido. Ver Cómo se activan los cambios. - Cargue solo el contenido y las imágenes desconectados al destino confirmado. Revise los errores de cada página e imagen.
- Compruebe el contenido guardado con la revisión de código deseada en el sitio de vista previa,
*.aem.page. - Obtenga la aprobación de la versión del sitio y siga el proceso de migración de publicación y dominio configurado. La publicación hace que las páginas estén disponibles en
*.aem.live; el cambio es lo que les sirve en su propio dominio, a través de la CDN administrada por Adobe o su propia CDN. Revise la lista de comprobación de lanzamiento antes de la migración. - Compruebe las direcciones URL, redirecciones, recorridos clave y monitorización activos después del lanzamiento. Telemetría operativa muestra cómo los visitantes reales experimentan el rendimiento del sitio.
- Proporcione el traspaso del proyecto, el registro por dirección URL, ejemplos de autores, resultados de aprobación, excepciones y contactos de recuperación.
Cuando algo falla, mantenga la dirección URL o ruta exacta, la operación y el registro de errores. Vuelva a intentar el ámbito afectado más pequeño después de corregir la causa. No reinicie un lote correcto porque una página ha fallado.
La inserción de código, la carga de documentos, la importación de un paquete de contenido en Experience Manager y la publicación son operaciones independientes en sistemas independientes. Un error parcial puede dejar sólo algunos cambios aplicados y ninguna reversión individual los deshace todos. Recupere código a través de Git y contenido e imágenes a través del historial de versiones del destino del contenido o del proceso acordado.