Mit der Frontend-Pipeline erhalten Frontend-Entwickler mehr Unabhängigkeit und der Entwicklungsprozess kann erheblich an Geschwindigkeit gewinnen. In diesem Dokument wird beschrieben, wie dieser Prozess funktioniert, und es werden einige Überlegungen erläutert, die Sie beachten sollten, damit Sie das gesamte Potenzial dieses Prozesses ausschöpfen können.
Wenn Sie noch nicht mit der Verwendung der Frontend-Pipeline und den damit verbundenen Vorteilen vertraut sind, finden Sie im Abschnitt Weg zur schnellen Site-Erstellung ein Beispiel dafür, wie Sie eine neue Site schnell bereitstellen und ihr Design ganz unabhängig von der Backend-Entwicklung anpassen können.
Ähnlich wie die Full-Stack-Build-Umgebung verfügt die Frontend-Pipeline über eine eigene Umgebung. Entwickelnde haben eine gewisse Flexibilität bei dieser Pipeline, solange der folgende Frontend-Build-Vertrag eingehalten wird.
Für die Frontend-Pipeline muss das Frontend-Projekt Node.js die Variable build
Skriptanweisung zum Generieren des Builds, der von der Frontend-Pipeline bereitgestellt wird. Cloud Manager verwendet den Befehl npm run build
, um das bereitstellbare Projekt für den dist
-Ordner zu generieren.
Der Inhalt des Ordners dist
wird schließlich für AEM as a Cloud Service von der Cloud Manager-Pipeline bereitgestellt.
Standardmäßig verwendet die Frontend-Pipeline den Knoten 14, aber auch 12 und 16 sind verfügbar.
Mithilfe der Umgebungsvariable CM_CUSTOM_VAR_NODE_VERSION
können Sie die gewünschte Version festlegen.
Ein allgemein bewährtes Verfahren besteht darin, für das, was in AEM bereitgestellt ist, eine zentrale Datenquelle zu haben. Das Ziel von Cloud Manager besteht darin, diese zentrale Datenquelle offensichtlich zu machen. Da die Frontend-Pipeline jedoch die Entkopplung des Speicherorts für Teile des Codes ermöglicht, liegt eine zusätzliche Verantwortung in der korrekten Einrichtung der Frontend-Pipelines. Es muss darauf geachtet werden, dass nicht mehrere Frontend-Pipelines erstellt werden, die auf derselben Site in derselben Umgebung bereitgestellt werden.
Aus diesem Grund und insbesondere bei der Erstellung mehrerer Frontend-Pipelines wird empfohlen, eine systematische Benennungskonvention wie die folgende beizubehalten:
name
-Eigenschaft der Datei package.json
definiert ist, sollte den Namen der Site enthalten, für die es gilt. Für eine Site, die sich in /content/wknd
befindet, würde der Name des Frontend-Moduls zum Beispiel wknd-theme
lauten.wknd-theme
heißt, würde der umschließende Ordnername in etwa wknd-theme-sources
lauten.wknd-theme
kann die Pipeline beispielsweise wknd-theme-prod
benannt werden.Eine solche Konvention sollte die folgenden Bereitstellungsfehler wirksam verhindern:
Eine weitere bewährte Methode, die sich auf die Trennung der Zuständigkeiten bezieht, ist die besondere Sorgfalt bei der Gestaltung und der Verwaltung der Richtlinien zu den getrennten Zuständigkeiten. Bei der Frontend-Pipeline handelt es sich bei den Richtlinien, die diesen Code vom Rest trennen, um die von der Site gerenderte HTML und JSON. Wenn diese HTML und JSON stabil bleiben, liefert die Frontend-Pipeline ihren maximalen Wert, indem sie das Frontend-Team komplett unabhängig macht.
Es gibt derzeit keine spezielle Funktion, um die Full-Stack-Pipeline synchron mit der/den Frontend-Pipeline(s) auszuführen. Aus diesem Grund muss bei der Entkopplung der Frontend-Entwicklung von der Full-Stack-Pipeline besondere Sorgfalt in den Richtlinien, die die beiden Problembereiche trennen, angewendet werden. Diese Richtlinien sind im Allgemeinen die HTML und/oder JSON, die Experience Manager rendert. Änderungen an diesen Richtlinien müssen daher zwischen den Teams, die die verschiedenen Pipelines betreiben, gut geplant werden, damit sie sich über die Reihenfolge der entsprechenden Änderungen einigen können.
Die folgenden Schritte werden im Allgemeinen empfohlen, wenn es notwendig ist, Änderungen an der HTML- und/oder JSON-Ausgabe vorzunehmen, die beide Zuständigkeiten betreffen.
dev
-Verzweigung erstellt, damit die für die Entwicklungsumgebung vorgenommenen Änderungen wieder problemlos in die main
-Verzweigung zurückgeführt werden können, die in der Produktionsumgebung bereitgestellt werden soll.dev
-Verzweigung befindet, wie im vorherigen Punkt beschrieben.npx aem-site-theme-builder proxy
, der innerhalb des Frontend-Moduls ausgeführt wird, startet einen Proxy-Server, der den Inhalt von einer AEM-Umgebung anfordert, während die CSS- und JS-Dateien des Frontend-Moduls durch die Dateien des lokalen Ordners dist
ersetzt werden.AEM_URL
in der ausgeblendeten Datei .env
konfigurieren, können Sie kontrollieren, von welcher AEM-Umgebung der lokale Proxy-Server den Inhalt verwendet.AEM_URL
ermöglicht es Ihnen daher, zwischen der Produktions- und Entwicklungsumgebung zu wechseln, um CSS und JS so anzupassen, dass sie zu beiden Umgebungen passen.