Mit der Front-End-Pipeline mehr Unabhängigkeit wird den Frontend-Entwicklern gegeben und der Entwicklungsprozess kann erheblich schneller werden. In diesem Dokument wird beschrieben, wie dieser Prozess funktioniert, sowie einige Überlegungen, die Sie beachten sollten, um das Potenzial dieses Prozesses voll auszuschöpfen.
Wenn Sie noch nicht wissen, wie die Front-End-Pipeline verwendet werden kann und welche Vorteile sie bringen kann, finden Sie im Abschnitt Journey zur schnellen Site-Erstellung ein Beispiel dafür, wie Sie eine neue Site schnell bereitstellen und ihr Design vollständig unabhängig von der Backend-Entwicklung anpassen können.
Eine allgemeine bewährte Praxis besteht darin, eine einzige Quelle der Wahrheit für das zu AEM bereitgestellte zu erhalten. Das Ziel von Cloud Manager besteht darin, diese einzige Quelle der Wahrheit deutlich zu machen. Da die Front-End-Pipeline jedoch die Entkopplung des Standorts für Teile des Codes ermöglicht, liegt eine zusätzliche Verantwortung in der korrekten Einrichtung der Front-End-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 Front-End-Pipelines wird empfohlen, eine systematische Benennungskonvention wie die folgende beizubehalten:
name
-Eigenschaft der package.json
sollte den Namen der Site enthalten, für die sie gilt. Beispiel: für eine Site unter /content/wknd
, lautet der Name des Front-End-Moduls ungefähr wknd-theme
.wknd-theme
, würde der umschließende Ordnername ungefähr so aussehen: wknd-theme-sources
.wknd-theme
kann die Pipeline etwa wie folgt benannt werden: wknd-theme-prod
.Ein solches Übereinkommen sollte wirksam die folgenden Implementierungsfehler verhindern:
Eine weitere bewährte Methode, die sich auf die Trennung von Anliegen bezieht, ist die besondere Sorgfalt bei der Gestaltung und der Verwaltung des Vertrags, der die Bedenken trennt. Bei der Frontend-Pipeline ist der Vertrag, der diesen Code vom Rest trennt, die von der Site gerenderte HTML und JSON. Wenn diese HTML und JSON stabil bleiben, liefert die Front-End-Pipeline ihren maximalen Wert, indem sie das Front-End-Team vollständig unabhängig macht.
Es gibt derzeit keine spezielle Funktion, um die Vollstapel-Pipeline synchron mit den Frontend-Pipeline(en) auszuführen. Aus diesem Grund muss bei der Entkopplung der Frontend-Entwicklung von der Vollstapelpipeline in den Vertrag, der diese beiden Problembereiche trennt, besondere Sorgfalt aufgenommen werden. Dieser Vertrag ist im Allgemeinen die HTML und/oder JSON, die der Experience Manager rendert. Änderungen an diesem Vertrag müssen daher zwischen den Teams, die die verschiedenen Pipelines betreiben, gut geplant werden, damit sie sich darauf einigen können, wie die entsprechenden Änderungen zu ordnen sind.
Die folgenden Schritte werden im Allgemeinen empfohlen, wenn es notwendig ist, Änderungen an der HTML- und/oder JSON-Ausgabe vorzunehmen, die beide Problembereiche betreffen.
dev
-Verzweigung, damit die für die Entwicklungsumgebung vorgenommenen Änderungen einfach wieder in die main
-Verzweigung, die in der Produktionsumgebung bereitgestellt werden soll.dev
-Verzweigung, wie im vorherigen Punkt beschrieben.npx aem-site-theme-builder proxy
-Befehl, der innerhalb des Front-End-Moduls ausgeführt wird, startet einen Proxy-Server, der den Inhalt von einer AEM Umgebung anfordert, während die CSS- und JS-Dateien des Front-End-Moduls durch die Dateien des lokalen ersetzt werden dist
Ordner.AEM_URL
-Variable in der ausgeblendeten .env
-Datei können steuern, von welcher AEM Umgebung der lokale Proxyserver den Inhalt verbraucht.AEM_URL
ermöglicht daher den Wechsel zwischen der Produktions- und Entwicklungsumgebung, um CSS und JS so anzupassen, dass sie zu beiden Umgebungen passen.