Con la canalización front-end, se da más independencia a los desarrolladores de front-end y el proceso de desarrollo puede ganar velocidad sustancial. En este documento se describe cómo funciona este proceso, así como algunas consideraciones que hay que tener en cuenta para aprovechar todo el potencial de este proceso.
Si todavía no está familiarizado con cómo utilizar la canalización front-end y las ventajas que puede aportar, consulte la Recorrido de creación rápida de sitios para ver un ejemplo de cómo implementar rápidamente un nuevo sitio y personalizar su tema completamente independientemente del desarrollo del back-end.
Similar a la entorno de compilación de pila completa, la canalización front-end tiene su propio entorno. Los desarrolladores tienen cierta flexibilidad en esta canalización siempre y cuando se observe el siguiente contrato de versión del front-end.
La canalización front-end requiere que el proyecto front-end Node.js utilice el build
directiva de script para generar la compilación que implementa la canalización front-end. Es decir, Cloud Manager utiliza el comando npm run build
para generar el proyecto implementable en dist
carpeta.
El contenido del dist
AEM Esta carpeta es lo que se implementa finalmente para que se ejecute en as a Cloud Service desde la canalización de Cloud Manager.
De forma predeterminada, la canalización front-end utiliza el nodo 14, pero 12 y 16 también están disponibles.
Puede usar el complemento NODE_VERSION
para establecer la versión deseada.
AEM Una buena práctica general es mantener una única fuente de datos para lo que se implementa en el sistema de informes de la aplicación de la plataforma de datos de la plataforma de datos de la plataforma de datos de la plataforma de datos de la red de. El objetivo de Cloud Manager es hacer obvia esa única fuente de verdad. Sin embargo, como la canalización front-end permite desacoplar la ubicación de partes del código, parte de la responsabilidad adicional reside en la configuración correcta de las canalizaciones front-end. Se debe tener cuidado de no crear varias canalizaciones front-end que se implementen en el mismo sitio en el mismo entorno.
Por este motivo, y especialmente cuando se crean varias canalizaciones front-end, se recomienda mantener una convención de nombres sistemática como la siguiente:
name
propiedad del package.json
debe contener el nombre del sitio al que se aplica. Por ejemplo, para un sitio ubicado en /content/wknd
, el nombre del módulo front-end sería algo así como wknd-theme
.wknd-theme
, el nombre de la carpeta adjunta sería algo así como wknd-theme-sources
.wknd-theme
, la canalización podría tener el siguiente nombre wknd-theme-prod
.Una convención de este tipo debería evitar de manera eficiente los siguientes errores de implementación:
Otra buena práctica que se aplica a toda separación de intereses es poner especial cuidado en la forma en que se concibe y gestiona el contrato que separa los intereses. En el caso de la canalización front-end, el contrato que separa ese código del resto es el HTML y el JSON procesados por el sitio. Si ese HTML y JSON se mantienen estables, la canalización front-end ofrece su valor máximo al hacer que el equipo front-end sea totalmente independiente.
Actualmente no hay ninguna capacidad específica para ejecutar la canalización de pila completa sincrónicamente con las canalizaciones front-end. Por esta razón, al desacoplar el desarrollo front-end de la canalización full-stack, se debe poner un cuidado adicional en el contrato que separa estas dos áreas de preocupación. Ese contrato suele ser el HTML o JSON que Experience Manager procesa. Por lo tanto, los cambios en ese contrato deben estar bien planificados entre los equipos que operan las diferentes canalizaciones para que acuerden cómo secuenciar los cambios correspondientes.
En general, se recomiendan los siguientes pasos cuando es necesario realizar cambios en el HTML o en la salida JSON que afecten a ambas áreas de interés.
dev
, para que los cambios realizados en el entorno de desarrollo se puedan volver a fusionar fácilmente con el main
rama que se va a implementar en el entorno de producción.dev
rama, tal como se describe en el punto anterior.npx aem-site-theme-builder proxy
AEM El comando ejecutado en el módulo front-end inicia un servidor proxy que solicita el contenido de un entorno de, al tiempo que reemplaza los archivos CSS y JS del módulo front-end por los del entorno local dist
carpeta.AEM_URL
en la variable oculta .env
AEM permite controlar desde qué entorno consume el contenido el servidor proxy local.AEM_URL
por lo tanto, permite cambiar entre los entornos de producción y desarrollo para ajustar CSS y JS de modo que se adapte a ambos entornos.