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, sowie einige Überlegungen, die Sie beachten sollten, um das ganze Potenzial dieses Prozesses zu auszuschöpfen.
TIPP
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 implementieren und ihr Design ganz unabhängig von der Backend-Entwicklung anpassen können.
Front-End-Build-Vertrag
Ähnlich wie bei Vollstapel-Build-Umgebung, Die Frontend-Pipeline verfügt über eine eigene Umgebung. Entwickler haben eine gewisse Flexibilität in 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. Beispiel: Cloud Manager verwendet den Befehl npm run build , um das bereitstellbare Projekt für die dist Ordner.
Der Inhalt der dist -Ordner ist das Element, das letztendlich in der Cloud Manager-Pipeline as a Cloud Service AEM wird.
Knotenversionen
Standardmäßig verwendet die Front-End-Pipeline Node 14, aber auch Node 12 und 16 sind verfügbar.
Sie können die CM_CUSTOM_VAR_NODE_VERSION Umgebungsvariable, um die gewünschte Version festzulegen.
Zentrale Datenquelle
Ein allgemein bewährtes Verfahren besteht darin, für das, was in AEM implementiert 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 implementiert werden.
Aus diesem Grund und insbesondere bei der Erstellung mehrerer Frontend-Pipelines wird empfohlen, eine systematische Benennungskonvention wie die folgende beizubehalten:
Der Name des Frontend-Moduls, der durch die 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.
Wenn ein Frontend-Modul dasselbe Git-Repository mit anderen Modulen teilt, sollte der Name seines Ordners mit dem Namen des Frontend-Moduls übereinstimmen oder denselben Namen enthalten. Wenn beispielsweise das Frontend-Modul wknd-theme heißt, würde der umschließende Ordnername in etwa wknd-theme-sources lauten.
Der Name der Frontend-Pipeline von Cloud Manager sollte ebenfalls den Namen des Frontend-Moduls enthalten und die Umgebung hinzufügen, in der es implementiert wird (Produktion oder Entwicklung). Für das Frontend-Modul mit dem Namen wknd-theme kann die Pipeline beispielsweise wknd-theme-prod benannt werden.
Eine solche Konvention sollte die folgenden Implementierungsfehler wirksam verhindern:
Anwenden eines Frontend-Moduls auf die falsche Site
Erstellen mehrerer Frontend-Module, die dieselbe Site anwenden und sich gegenseitig überschreiben
Erstellen mehrerer Frontend-Pipelines für dieselben Quellen, was zu Race-Bedingungen führen kann, ohne die Reihenfolge der Implementierungen zu garantieren
Trennung der Zuständigkeiten
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.
Das Backend-Team richtet zunächst eine Entwicklungsumgebung mit der neuen HTML- und/oder JSON-Ausgabe ein.
Über die Full-Stack-Pipeline stellen sie den Code bereit, der zum Rendern der gewünschten neuen HTML- und/oder JSON-Ausgabe erforderlich ist.
Wenn dies eine Umgebung ist, auf die das Frontend-Team zuvor keinen Zugriff hatte, müssen die folgenden Schritte ausgeführt werden.
URL: Das Frontend-Team muss die URL dieser Entwicklungsumgebung kennen.
ACL: Dem Frontend-Team muss ein lokaler AEM-Benutzer mit Berechtigungen wie „Mitwirkende“ zugewiesen werden.
Git: Das Frontend-Team muss über einen separaten Git-Speicherort für das Frontend-Modul verfügen, der speziell auf diese Entwicklungsumgebung ausgerichtet ist.
Üblicherweise wird eine 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.
Pipeline: Das Frontend-Team muss über eine Frontend-Pipeline verfügen, die in der Entwicklungsumgebung bereitgestellt wird. Diese Pipeline stellt das Frontend-Modul bereit, das sich normalerweise in der dev-Verzweigung befindet, wie im vorherigen Punkt beschrieben.
Das Frontend-Team sorgt dann dafür, dass der CSS- und JS-Code sowohl mit der alten als auch mit der neuen Ausgabe funktioniert.
Wie üblich zur lokalen Entwicklung:
Der Befehl 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.
Wenn Sie die Variable AEM_URL in der ausgeblendeten Datei .env konfigurieren, können Sie kontrollieren, von welcher AEM-Umgebung der lokale Proxy-Server den Inhalt verwendet.
Das Ändern des Werts AEM_URL ermöglicht daher den Wechsel zwischen der Produktions- und Entwicklungsumgebung, um CSS und JS so anzupassen, dass sie zu beiden Umgebungen passen.
Dies muss mit der Entwicklungsumgebung, die die neue Ausgabe rendert, und mit der Produktionsumgebung funktionieren, die die alte Ausgabe rendert.
Die Frontend-Arbeit ist abgeschlossen, wenn das aktualisierte Frontend-Modul für beide Umgebungen funktioniert und bereitgestellt wird.
Das Backend-Team kann dann die Produktionsumgebung aktualisieren, indem es den Code bereitstellt, der die neue HTML- und/oder JSON-Ausgabe über die Full-Stack-Pipeline rendert.
Das Frontend-Team kann dann seine CSS- und JS-Dateien bereinigen und das entfernen, was nur von der alten Ausgabe benötigt wurde, und dieses letzte Update über die Frontend-Pipeline in der Produktion bereitstellen.
Zusätzliche Ressourcen
Site-Designs - Erfahren Sie, wie AEM-Site-Designs verwendet werden können, um den Stil und das Design Ihrer Site anzupassen.
AEM-Site-Design-Builder: Adobe bietet einen AEM-Site-Design-Builder als Skriptsatz zum Erstellen neuer Site-Designs.
