Con la canalización frontal, se da más independencia a los desarrolladores de front-end y el proceso de desarrollo puede ganar una velocidad sustancial. Este documento describe cómo funciona este proceso junto con algunas consideraciones que hay que tener en cuenta para aprovechar todo el potencial de este proceso.
Si todavía no conoce cómo utilizar la canalización front-end y los beneficios que puede reportar, 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 independiente del desarrollo del back-end.
Similar a la variable 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 construcción front-end.
La canalización front-end requiere que el proyecto front-end Node.js use el build
directiva script para generar la compilación que implementará la canalización front-end. Es decir, Cloud Manager utiliza el comando npm run build
para generar el proyecto implementable en el dist
carpeta.
El contenido de la variable dist
carpeta es lo que se implementa finalmente en AEM as a Cloud Service desde la canalización de Cloud Manager.
De forma predeterminada, la canalización de front-end utiliza el nodo 14, pero también están disponibles los nodos 12 y 16.
Puede usar la variable CM_CUSTOM_VAR_NODE_VERSION
para establecer la versión deseada.
Una buena práctica general es mantener una única fuente de verdad para lo que se ha implementado en AEM. El objetivo de Cloud Manager es hacer que esa única fuente de verdad sea obvia. Sin embargo, como la canalización frontal permite desacoplar la ubicación de las partes del código, algunas responsabilidades adicionales radican 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 nomenclatura sistemática como la siguiente:
name
propiedad de la variable 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 que la rodea sería algo así wknd-theme-sources
.wknd-theme
, la canalización podría llamarse algo así como wknd-theme-prod
.Una convención de este tipo debería evitar de forma eficaz los siguientes errores de implementación:
Otra buena práctica que se aplica a toda separación de preocupaciones es la de poner especial cuidado en la forma en que se diseña y gestiona el contrato que separa las preocupaciones. En el caso de la canalización front-end, el contrato que separa ese código del resto es el HTML y JSON procesados por el sitio. Si ese HTML y JSON permanecen estables, entonces la canalización front-end ofrece su máximo valor 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 desvincular el desarrollo front-end de la canalización de toda la pila, se debe tener cuidado adicional en el contrato que separa estas dos áreas de preocupación. Ese contrato suele ser el HTML o JSON que el Experience Manager procesa. Por lo tanto, los cambios en dicho contrato deben planificarse bien entre los equipos que gestionen las diferentes canalizaciones, de modo que acuerden cómo secuenciar los cambios correspondientes.
Por lo 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 preocupación.
dev
para que los cambios realizados para el entorno de desarrollo se puedan volver a fusionar fácilmente en la main
que se va a implementar en el entorno de producción.dev
como se describe en el punto anterior.npx aem-site-theme-builder proxy
ejecutar en el módulo front-end inicia un servidor proxy que solicita el contenido desde un entorno AEM, mientras reemplaza los archivos CSS y JS del módulo front-end por los del servidor local dist
carpeta.AEM_URL
en la variable oculta .env
permite controlar desde qué entorno AEM el servidor proxy local consume el contenido.AEM_URL
por lo tanto, permite cambiar entre los entornos de producción y desarrollo para ajustar CSS y JS de modo que se ajuste a ambos entornos.