DocumentaciónAEMGuía del usuario

Implementación en AEM as a Cloud Service deploying-to-aem-as-a-cloud-service

Última actualización: 11 de octubre de 2026
  • Se aplica a:
  • Experience Manager as a Cloud Service

Creado para:

  • Administrador

Introducción introduction

Los fundamentos del desarrollo de código son similares en AEM as a Cloud Service en comparación con las soluciones AEM On Premise y Managed Services. Los desarrolladores escriben el código y lo prueban localmente, para a continuación enviarlo a entornos de AEM as a Cloud Service remotos. Se requiere Cloud Manager, que era una herramienta de entrega de contenido opcional para Managed Services. Esta herramienta de envío es ahora el único mecanismo para implementar código en entornos de desarrollo, ensayo y producción de AEM as a Cloud Service. Para ejecutar una validación y una depuración rápidas de las funcionalidades antes de implementar los entornos mencionados, el código se puede sincronizar de un entorno local a un Entorno de desarrollo rápido.

La actualización de la versión de AEM siempre es un evento de implementación independiente de la inserción de código personalizado. Alternativamente, las versiones de código personalizado deben probarse con la versión de AEM que está en producción porque es en la que está implementado. Las actualizaciones de versión de AEM que se producen posteriormente (que son frecuentes y se aplican automáticamente) están pensadas para ser compatibles con versiones anteriores del código de cliente ya implementado.

El resto de este documento describe cómo los desarrolladores adaptan sus prácticas para trabajar tanto con las actualizaciones de la versión de AEM as a Cloud Service como con las actualizaciones de los clientes.

Versiones de clientes customer-releases

Codificación con la versión de AEM correcta coding-against-the-right-aem-version

Para las soluciones de AEM anteriores, la versión de AEM cambiaba con poca frecuencia y los clientes actualizaban las instancias de producción al inicio rápido más reciente, haciendo referencia al Jar de API. Sin embargo, las aplicaciones de AEM as a Cloud Service se actualizan automáticamente a la última versión de AEM con mayor frecuencia, por lo que el código personalizado para versiones internas debe crearse con la última versión de AEM.

Al igual que con las versiones existentes de AEM que no son en la nube, se admite el desarrollo local sin conexión basado en un inicio rápido específico y, por lo general, se espera que sea la herramienta principal para la depuración.

NOTE
Existen sutiles diferencias operativas entre el comportamiento de la aplicación en un equipo local y la infraestructura en la nube de Adobe. Estas diferencias arquitectónicas requieren consideración durante el desarrollo local y conducen a un comportamiento diferente al implementarlas en la infraestructura en la nube. Debido a estas diferencias, es importante realizar pruebas exhaustivas en los entornos de desarrollo y ensayo antes de implementar un nuevo código personalizado en producción.

Para desarrollar un código personalizado para una versión interna, debe descargarse e instalarse la versión correspondiente del SDK de AEM as a Cloud Service. Para obtener información adicional acerca del uso de las herramientas de Dispatcher de AEM as a Cloud Service, consulte Dispatcher en la nube.

El siguiente vídeo proporciona información general de alto nivel sobre cómo implementar los códigos en AEM as a Cloud Service:

https://video.tv.adobe.com/v/34039?captions=spa&quality=9&learn=on

Implementación de paquetes de contenido mediante Cloud Manager y el Administrador de paquetes deploying-content-packages-via-cloud-manager-and-package-manager

Implementaciones a través de Cloud Manager deployments-via-cloud-manager

Los clientes implementan código personalizado en entornos de nube a través de Cloud Manager. Cloud Manager transforma los paquetes de contenido montados localmente en un artefacto que se ajusta al modelo de funciones de Sling. Este modelo describe una aplicación en AEM as a Cloud Service cuando se ejecuta en un entorno de nube. Como resultado, al consultar los paquetes en Administrador de paquetes en entornos de Cloud, el nombre incluye “cp2fm” y los paquetes transformados tienen todos los metadatos eliminados. No se puede interactuar con ellos, lo que significa que no se pueden descargar, replicar ni abrir. Para obtener documentación detallada sobre el convertidor, consulte sling-org-apache-sling-feature-cpconverter en GitHub.

Los paquetes de contenido para AEM as a Cloud Service deben separar el contenido inmutable del mutable. Cloud Manager solo instala el contenido mutable y genera un mensaje como el siguiente:

Generated content-package <PACKAGE_ID> located in file <PATH> is of MIXED type

El resto de esta sección describe la composición y las implicaciones de los paquetes inmutables y mutables.

Paquetes de contenido inmutables immutabe-content-packages

Todo el contenido y el código que persiste en el repositorio inmutable deben registrarse en Git e implementarse mediante Cloud Manager. En otras palabras, a diferencia de las soluciones AEM actuales, el código nunca se implementa directamente en una instancia de AEM en ejecución. Este flujo de trabajo garantiza que el código que se ejecuta para una versión determinada en cualquier entorno de Cloud sea idéntico, lo que elimina el riesgo de variación no intencional del código en la producción. Por ejemplo, la configuración de OSGI debe confirmarse con el control de código fuente en lugar de administrarse durante la ejecución a través del administrador de configuración de la consola web de AEM.

Un modificador habilita los cambios de la aplicación debido al patrón de implementación, por lo que no pueden depender de los cambios en el repositorio mutable excepto para los usuarios de servicio, sus ACL, tipos de nodo y cambios en la definición de índice.

Para los clientes con bases de código existentes, es fundamental pasar por el ejercicio de reestructuración de repositorios descrito en la documentación de AEM para garantizar que el contenido que anteriormente estaba bajo /etc se mueva a la ubicación correcta.

Se aplican algunas restricciones adicionales a estos paquetes de código; por ejemplo, los enlaces de instalación no son compatibles.

Configuración de OSGI osgi-configuration

Como se ha mencionado anteriormente, la configuración OSGI debe confirmarse en el control de código fuente en lugar de a través de la consola web. Las técnicas para hacerlo incluyen las siguientes:

  • Realizar los cambios necesarios en el entorno de AEM local del desarrollador con el administrador de configuración de la consola web de AEM y a continuación exportar los resultados al proyecto de AEM en el sistema de archivos local
  • Crear manualmente la configuración de OSGI en el proyecto de AEM en el sistema de archivos local y, a continuación, hacer referencia al administrador de configuración de la consola de AEM para los nombres de propiedad.

Obtenga más información sobre la configuración OSGI en Configuración de OSGi para AEM as a Cloud Service.

Contenido mutable mutable-content

A veces, es útil preparar los cambios de contenido en el control de código fuente para que Cloud Manager los implemente cada vez que se actualiza un entorno. Por ejemplo, es razonable inicializar ciertas estructuras de carpetas raíz. Para habilitar los componentes de directivas que actualiza la implementación de la aplicación, alinee los cambios en las plantillas editables.

Cloud Manager implementa contenido en el repositorio mutable mediante dos estrategias: paquetes de contenido mutable e instrucciones repoinit.

Paquetes de contenido mutables mutable-content-packages

El contenido, como las jerarquías de rutas de carpetas, los usuarios de servicios y los controles de acceso (ACL), se suelen confirmar en un proyecto de AEM basado en arquetipos Maven. Las técnicas incluyen la exportación desde AEM o la escritura directamente como XML. Durante el proceso de compilación e implementación, Cloud Manager empaqueta el paquete de contenido mutable resultante. El contenido mutable se instala en tres momentos diferentes durante la fase de implementación de la canalización:

Antes del inicio de la nueva versión de la aplicación:

  • Definiciones de índice (agregar, modificar, eliminar)

Durante el inicio de la nueva versión de la aplicación, pero antes del cambio:

  • Usuarios de servicio (agregar)
  • ACL de usuario de servicio (agregar)
  • Tipos de nodo (agregar)

Después de cambiar a una nueva versión de la aplicación:

  • El resto del contenido se puede definir mediante el almacén Jackrabbit. Por ejemplo:

    • Carpetas (agregar, modificar, quitar)
    • Plantillas editables (agregar, modificar, quitar)
    • Configuración según el contexto (cualquier elemento en /conf) (agregar, modificar, eliminar)
    • Scripts (los paquetes pueden almacenar en déclencheur los ganchos de instalación). Consulte Documentación de Jackrabbit filevault).

Es posible limitar la instalación de contenido mutable a la creación o publicación incrustando paquetes en una carpeta install.author o install.publish en /apps. La reestructuración para reflejar esta separación se realizó en AEM 6.5 y los detalles sobre la reestructuración recomendada del proyecto se encuentran en la documentación de AEM 6.5.

NOTE
Los paquetes de contenido se implementan en todos los tipos de entorno (des., fase, prod.). No es posible limitar la implementación a un entorno específico. Esta limitación se aplica para garantizar la opción de una ejecución de prueba de ejecución automatizada. El contenido específico de un entorno requiere una instalación manual mediante el administrador de paquetes.

Además, no hay mecanismo para revertir los cambios del paquete de contenido mutable después de aplicarlos. Si los clientes detectan un problema, pueden optar por solucionarlo en su próxima versión de código o, como último recurso, restaurar todo el sistema a un punto en el tiempo antes de la implementación.

Cualquier paquete de terceros incluido debe validarse como compatible con AEM as a Cloud Service; de lo contrario, su inclusión provoca un error de implementación.

Como se mencionó anteriormente, los clientes con bases de código existentes cumplen con el ejercicio de reestructuración de repositorios necesario por los cambios de repositorio de 6.5 descritos en la documentación de AEM 6.5.

RepoInit repoinit

En los casos siguientes, es preferible utilizar el método de codificación manual para las instrucciones de creación de contenido explícito repoinit en las configuraciones de fábrica de OSGI:

  • Crear/eliminar/deshabilitar usuarios de servicios

  • Crear/eliminar grupos

  • Crear/eliminar usuarios

  • Agregar ACL

    note
    NOTE
    La definición de ACL requiere que las estructuras de nodos ya estén presentes. Por lo tanto, son necesarias las instrucciones de ruta de creación anteriores.

  • Agregar ruta (por ejemplo, para estructuras de carpetas raíz)

  • Agregar CND (definiciones de tipos de nodos)

Es preferible un informe para estos casos de uso de modificación de contenido compatibles debido a las ventajas siguientes:

  • Repoinit crea recursos al inicio para que la lógica pueda dar por sentada la existencia de esos recursos. En el enfoque de paquete de contenido mutable, los recursos se crean después del inicio, por lo que falla el código de la aplicación que depende de ellos.
  • Repoinit es un conjunto de instrucciones relativamente seguro, ya que controla explícitamente la acción que se va a llevar a cabo. Además, las únicas operaciones admitidas son aditivas, a excepción de algunos casos relacionados con la seguridad que permiten eliminar usuarios, usuarios de servicios y grupos. Por el contrario, la eliminación de algo en el enfoque del paquete de contenido mutable es explícita; al definir un filtro, se elimina cualquier elemento presente cubierto por un filtro. Sin embargo, hay que tener cuidado porque con cualquier contenido hay escenarios en los que la presencia de contenido nuevo puede alterar el comportamiento de la aplicación.
  • Repoinit realiza operaciones atómicas y rápidas. Por el contrario, los paquetes de contenido mutables pueden depender en gran medida del rendimiento según las estructuras cubiertas por un filtro. Incluso si actualiza un solo nodo, se crea una instantánea de un árbol grande.
  • Es posible validar las instrucciones repoinit en un entorno de desarrollo local durante la ejecución, ya que se ejecutan cuando se registre la configuración de OSGi.
  • Las instrucciones Repoinit son atómicas y explícitas y se omitirán si el estado ya coincide.

Cuando Cloud Manager implementa la aplicación, ejecuta estas instrucciones, independientemente de la instalación de cualquier paquete de contenido.

Para crear repoinit instrucciones:

  1. Agregar la configuración OSGi para el PID de fábrica org.apache.sling.jcr.repoinit.RepositoryInitializer en una carpeta de configuración del proyecto. Utilice un nombre descriptivo para la configuración como org.apache.sling.jcr.repoinit.RepositoryInitializer~initstructure.
  2. Agregue instrucciones repoinit a la propiedad script de la configuración. La sintaxis y las opciones están documentadas en la Documentación de Sling. Cree una carpeta principal explícitamente antes de sus carpetas secundarias. Por ejemplo, una creación explícita de /content antes de /content/myfolder y de /content/myfolder/mysubfolder. Para que las ACL se establezcan en estructuras de bajo nivel, se recomienda configurarlas en un nivel superior y trabajar con una restricción rep:glob. Por ejemplo, (allow jcr:read on /apps restriction(rep:glob,/msm/wcm/rolloutconfigs)).
  3. Valide en el entorno de desarrollo local durante la ejecución.
WARNING
Para las ACL definidas para los nodos por debajo de /apps o /libs, la ejecución de repoinit se inicia en un repositorio en blanco. Los paquetes se instalan después de repoinit, por lo que las instrucciones no pueden depender en nada de lo definido en los paquetes, sino que se deben definir las condiciones previas como las estructuras principales que hay debajo.
TIP
Para las ACL, la creación de estructuras profundas es compleja. Por lo tanto, es más razonable definir una ACL en un nivel superior y restringir donde se supone que actúa a través de una restricción rep:glob.

Puede encontrar más información sobre repoinit en la Documentación de Sling

Instalaciones únicas en el Administrador de paquetes para paquetes de contenido mutable package-manager-oneoffs-for-mutable-content-packages

Hay casos de uso en los que un paquete de contenido debe instalarse como una instalación única. Por ejemplo, importar contenido específico de la producción a ensayo para depurar un problema de producción. Para estos escenarios, el Administrador de paquetes se puede utilizar en entornos de AEM as a Cloud Service.

El Administrador de paquetes es un concepto de tiempo de ejecución; no es posible instalar contenido o código en el repositorio inmutable y estos paquetes de contenido constan de contenido mutable (principalmente /content o /conf). Si el paquete de contenido incluye contenido mixto (tanto mutable como inmutable), solo se instalará el contenido mutable.

IMPORTANT
La interfaz de usuario del Administrador de paquetes devuelve un mensaje de error undefined si un paquete tarda más de diez minutos en instalarse.
Esto no se debe a un error en la instalación, sino a un tiempo de espera que Cloud Service tiene para todas las solicitudes.
No vuelva a intentar realizar la instalación si aparece un error de este tipo. La instalación continúa correctamente en el fondo. Si se reinicia la instalación, aparecen varios conflictos en varios procesos de importación simultáneos.

Cualquier paquete de contenido que instale Cloud Manager (mutable e inmutable) aparece bloqueado en la interfaz de usuario del Administrador de paquetes de AEM. Estos paquetes no se pueden reinstalar, reconstruir ni descargar, y se muestran con el sufijo “cp2fm”, lo que indica que Cloud Manager realizó su instalación.

Inclusión de paquetes de terceros including-third-party

Es habitual que los clientes incluyan paquetes generados previamente de fuentes de terceros, como proveedores de software, tales como los socios de traducción de Adobe. La recomendación es alojar estos paquetes en un repositorio remoto y hacer referencia a ellos en pom.xml. Este método es posible para repositorios públicos y también para repositorios privados con protección por contraseña, tal como se describe en los repositorios Maven protegidos por contraseña.

Si no es posible almacenar el paquete en un repositorio remoto, los clientes pueden ubicarlo en un repositorio Maven local, basado en el sistema de archivos, que se asigna a SCM como parte del proyecto y al que hace referencia todo lo que dependa de él. Lo que depende de él hace referencia a él. El repositorio se declararía en el elemento POM del proyecto, como se ilustra a continuación:

<repository>
    <id>project.local</id>
    <name>project</name>
    <url>file:${maven.multiModuleProjectDirectory}/repository</url>
</repository>

Todos los paquetes de terceros incluidos deben cumplir las directrices de codificación y empaquetado de AEM as a Cloud Service descritas en este artículo; de lo contrario, su inclusión provoca un error de implementación.

El siguiente fragmento POM.xml de Maven muestra cómo los paquetes de terceros pueden integrarse en el paquete “Contenedor” del proyecto, normalmente denominado ‘all’, a través de la configuración del complemento filevault-package-maven-plugin de Maven.

...
<plugin>
  <groupId>org.apache.jackrabbit</groupId>
  <artifactId>filevault-package-maven-plugin</artifactId>
  <extensions>true</extensions>
  <configuration>
      ...
      <embeddeds>

          ...

          <!-- Include any other extra packages  -->
          <embedded>
              <groupId>com.vendor.x</groupId>
              <artifactId>vendor.plug-in.all</artifactId>
              <type>zip</type>
              <target>/apps/vendor-packages/container/install</target>
          </embedded>
      <embeddeds>
  </configuration>
</plugin>
...

Funcionamiento de las implementaciones móviles how-rolling-deployments-work

Al igual que las actualizaciones de AEM, las versiones de los clientes se implementan mediante una estrategia de implementación dinámica para eliminar el tiempo de inactividad del clúster de creación en las circunstancias adecuadas. A continuación se describe la secuencia general de eventos, en la que los nodos con las versiones antigua y nueva del código de cliente ejecutan la misma versión del código de la AEM.

TIP
Como alternativa a una implementación móvil estándar, puede utilizar una implementación canaria para validar una nueva compilación en la infraestructura de producción antes de enrutar el tráfico en directo a ella. Consulte Usar implementaciones canarias para validar el código.
  • Los nodos con la versión antigua están activos y se crea una versión candidata para la nueva versión, que está disponible.
  • Si hay definiciones de índice nuevas o actualizadas, se procesan los índices correspondientes. Tenga en cuenta que los nodos con la versión antigua siempre utilizarán los índices antiguos, mientras que los nodos con la nueva versión siempre utilizarán los índices nuevos.
  • Los nodos con la nueva versión se inician, mientras que las versiones anteriores siguen sirviendo tráfico.
  • Los nodos con la versión antigua se siguen ejecutando y sirviendo mientras se comprueba la preparación de los nodos con la nueva versión mediante comprobaciones de estado.
  • Los nodos con la versión nueva que estén listos aceptarán tráfico y reemplazarán los nodos con la versión antigua, los cuales se desactivan.
  • Con el tiempo, los nodos con la nueva versión reemplazan a los nodos con la versión antigua hasta que solo quedan nodos con versiones nuevas, lo que completa la implementación.
  • Se implementa cualquier contenido mutable nuevo o modificado.

Índices indexes

Los índices nuevos o modificados provocarán un paso adicional de indexación o reindexación antes de que la versión nueva pueda entrar en el tráfico. Encontrará detalles sobre la administración de índices en AEM as a Cloud Service en Búsqueda de contenido e indexación. Puede comprobar el estado de indexación de las páginas de compilación en Cloud Manager y recibir una notificación cuando la nueva versión esté lista para admitir tráfico.

NOTE
El tiempo necesario para una implementación móvil varía según el tamaño del índice. El motivo es que la nueva versión no puede aceptar tráfico hasta que se genere el nuevo índice.

En este momento, AEM as a Cloud Service no funciona con herramientas de administración de índices como la herramienta ACS Commons Ensure Oak Index.

Replicación replication

El mecanismo de publicación es compatible con versiones anteriores de las API de Java de replicación de AEM.

Para desarrollar y probar la replicación mediante el inicio rápido de AEM listo para la nube, utilice las capacidades de replicación clásicas con la configuración Autor/Publicación. Si el punto de entrada de la interfaz de usuario de AEM Author se elimina de la nube, los usuarios acceden a http://localhost:4502/etc/replication para la configuración.

Código compatible con versiones anteriores para implementaciones móviles backwards-compatible-code-for-rolling-deployments

Como se ha detallado anteriormente, la estrategia de implementación móvil de AEM as a Cloud Service implica que tanto las versiones antiguas como las nuevas funcionan al mismo tiempo. Por lo tanto, tenga cuidado con los cambios en el código que no sean compatibles con la versión anterior de AEM que aún esté operativa.

Además, la versión antigua debe probarse para verificar la compatibilidad con cualquier estructura de contenido mutable nueva aplicada por la nueva versión en caso de revertir, ya que el contenido mutable no se elimina.

Usuarios de servicio y cambios de ACL service-users-and-acl-changes

El cambio de usuarios de servicio o ACL que acceden al contenido o al código provoca errores en las versiones de AEM anteriores, lo que da como resultado el acceso a ese contenido o código con usuarios de servicio obsoletos. Para solucionar este comportamiento, la recomendación es hacer cambios distribuidos en al menos dos versiones, y la primera versión actúa como vínculo antes de limpiarla en la versión siguiente.

Cambios de índice index-changes

Si se realizan cambios en los índices, es importante que la versión antigua siga utilizando sus índices hasta que finalice, mientras que la nueva versión utiliza su propio conjunto modificado de índices. El desarrollador sigue las técnicas de administración de índices descritas en Búsqueda de contenido e indexación.

Programación conservadora para reversiones conservative-coding-for-rollbacks

Si se informa o se detecta un error después de la implementación, es posible que se requiera una reversión a la versión antigua. Asegúrese de que el código nuevo sea compatible con cualquier estructura nueva creada por esa versión nueva, ya que las nuevas estructuras (cualquier contenido mutable) no se revierten. Si el código antiguo no es compatible, es necesario aplicar correcciones en las versiones posteriores del cliente.

Entornos de desarrollo rápido (RDE) rde

Los Entornos de Desarrollo Rápido (o RDE) permiten a los desarrolladores implementar y revisar los cambios rápidamente. Esto reduce al mínimo el tiempo necesario para probar las características que ya se ha comprobado que funcionan en un entorno de desarrollo local.

A diferencia de los entornos de desarrollo normales, que implementan código mediante la canalización de Cloud Manager, estos utilizan herramientas de línea de comandos para sincronizar el código de un entorno de desarrollo local a un RDE. Una vez que los cambios se hayan probado correctamente en un RDE, impleméntelos en un entorno de desarrollo de nube normal a través de la canalización de Cloud Manager, que coloca el código a través de las puertas de calidad adecuadas.

Modos de ejecución runmodes

En las soluciones de AEM existentes, los clientes tienen la opción de ejecutar instancias con modos de ejecución arbitrarios y aplicar la configuración OSGI o instalar paquetes OSGI en esas instancias específicas. Los modos de ejecución definidos normalmente incluyen el servicio (creación y publicación) y el entorno (RDE, des., fase, prod.).

AEM as a Cloud Service, por otro lado, tiene más opiniones sobre qué modos de ejecución están disponibles y cómo se pueden asignar a ellos los paquetes OSGI y la configuración OSGI:

  • Los modos de ejecución de la configuración OSGI deben hacer referencia al RDE, al desarrollo, a la fase, la producción para el entorno o la creación, publicación del servicio. Se admite una combinación de <service>.<environment_type>, donde estos entornos deben usarse en este orden en particular (por ejemplo, author.dev o publish.prod). Se debe hacer referencia a los tokens OSGi directamente en el código en lugar de utilizar el método getRunModes, que ya no incluye el tipo de entorno en tiempo de ejecución. Para obtener más información, consulte Configuración de OSGi para AEM as a Cloud Service.
  • Los modos de ejecución de los paquetes OSGI están limitados al servicio (autor, publicación). Los paquetes OSGI en el modo previo a la ejecución deben instalarse en el paquete de contenido en install.author o install.publish.

AEM as a Cloud Service no permite utilizar modos de ejecución para instalar contenido para entornos o servicios específicos. Si un entorno de desarrollo debe estar preconfigurado con datos o HTML que no se encuentre en los entornos de ensayo o producción, se puede utilizar el administrador de paquetes.

Las configuraciones de modo de ejecución admitidas son las siguientes:

  • config (de forma predeterminada, se aplica a todos los servicios de AEM)
  • config.author (Se aplica a todos los servicios de AEM Author)
  • config.author.dev (Se aplica al servicio de creación AEM desarrollo)
  • config.author.rde (se aplica al servicio Creación de RDE de AEM)
  • config.author.stage (Se aplica al servicio de creación AEM ensayo)
  • config.author.prod (Se aplica al servicio de creación AEM producción)
  • config.publish (Se aplica al servicio AEM publicación)
  • config.publish.dev (Se aplica al servicio de publicación AEM desarrollo)
  • config.publish.rde (se aplica al servicio Publicación de RDE de AEM)
  • config.publish.stage (Se aplica al servicio de publicación AEM ensayo)
  • config.publish.prod (Se aplica al servicio de publicación de AEM producción)
  • config.dev (Se aplica al servicio de AEM desarrollo)
  • config.rde (se aplica a los servicios de RDE)
  • config.stage (Se aplica al servicio de AEM ensayo)
  • config.prod (Se aplica al servicio de AEM producción)

Se utiliza la configuración OSGI que tiene los modos de ejecución más coincidentes.

Al desarrollar localmente, el parámetro de inicio de modo de ejecución, -r, se utiliza para especificar la configuración OSGI del modo de ejecución.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Configuración de tareas de mantenimiento en el control de código fuente maintenance-tasks-configuration-in-source-control

Las configuraciones de la tarea de mantenimiento deben mantenerse en el control de origen, ya que la pantalla Herramientas > Operaciones no estará disponible en los entornos de Cloud. Esta ventaja garantiza la persistencia intencionada de los cambios en lugar de su aplicación reactiva y olvido. Consulte Tareas de mantenimiento en AEM as a Cloud Service para obtener más información.

recommendation-more-help
experience-manager-cloud-service-help-main-toc