With the front-end pipeline, more independence is given to the front-end developers and the development process can gain substantial velocity. This document describes how this process works along with some considerations to be aware of in order to get the full potential out of this process.
If you are not yet familiar with how to use the front-end pipeline and the benefits it can bring, check out the Quick Site Creation Journey for an example of how to quickly deploy a new site and customize its theme completely independent of back-end development.
A general good practice is to maintain a single source of truth for what’s deployed to AEM. Cloud Manager’s objective is to make that single source of truth obvious. However, as the front-end pipeline allows decoupling the location for parts of the code, some additional responsibility lies in the correct setup of the front-end pipelines. Some care must be taken to not create multiple front-end pipelines that deploy to the same site on the same environment.
For this reason, and especially when several front-end pipelines are created, it is recommended to maintain a systematic naming convention such as the following:
nameproperty of the
package.jsonfile, should contain the name of the site it applies to. For example, for a site located at
/content/wknd, the name of the front-end module would be something like
wknd-theme, the enclosing folder name would be something like
wknd-theme, the pipeline could be named something like
Such a convention should efficiently prevent the following deployment mistakes:
Another good practice that applies to any separation of concerns is to put special care in how the contract that separates the concerns is designed and managed. In the case of the front-end pipeline, the contract separating that code from the rest is the HTML and JSON rendered by the site. If that HTML and JSON remains stable, then the front-end pipeline delivers its maximal value by making the front-end team fully independent.
There’s currently no specific capability to run the full-stack pipeline synchronously with the front-end pipeline(s). For this reason, when decoupling the front-end development from the full-stack pipeline, extra care must be put into the contract that separates these two areas of concerns. That contract generally is the HTML and/or JSON that Experience Manager renders. Changes to that contract must therefore be well-planned between the teams operating the different pipelines so that they agree on how to sequence the corresponding changes.
The following steps are generally recommended when it’s necessary to perform changes to the HTML and/or JSON output that impact both areas of concerns.
devbranch, so that the changes done for the development environment can then easily be merged back into the
mainbranch that is to be deployed to the production environment.
devbranch, as described in the previous point.
npx aem-site-theme-builder proxycommand executed within the front-end module starts a proxy server that requests the content from an AEM environment, while replacing the CSS and JS files of the front-end module with the ones from the local
AEM_URLvariable in the hidden
.envfile allows to control from which AEM environment the local proxy server consumes the content.
AEM_URLtherefore allows to switch between the production and development environments in order to adjust the CSS and JS so that it fits to both environments.