Entwickeln von Sites mit der Frontend-Pipeline developing-site-with-front-end-pipeline
Die Frontend-Pipeline gibt Frontend-Entwicklern größere Unabhängigkeit und beschleunigt die Entwicklung erheblich. In diesem Artikel wird erläutert, wie der -Prozess funktioniert und welche wichtigen Aspekte es zu beachten gilt, damit Sie ihn optimal nutzen können.
Grundlegendes zum Einrichten und Erstellen von Frontend-Pipelines in AEM Cloud Manager front-end-build-contract
Ähnlich wie die Full-Stack-Build-Umgebung verfügt die Frontend-Pipeline über eine eigene Umgebung. Entwickler haben eine gewisse Flexibilität bei dieser Pipeline, vorausgesetzt, sie befolgen den Frontend-Build-Vertrag.
Die Frontend-Pipeline erfordert, dass das Frontend-Node.js
-Projekt die build
-Skriptanweisung verwendet, um den Build zu generieren, den es bereitstellt. Diese Anforderung besteht, weil Cloud Manager das bereitstellbare Projekt für den Frontend-Build mithilfe der npm run build
generiert.
Der resultierende Inhalt des dist
-Ordners wird schließlich von Cloud Manager bereitgestellt und dient als statische Dateien. Diese Dateien werden extern in AEM gehostet, aber über eine /content/...
URL in der bereitgestellten Umgebung bereitgestellt.
Unterstützte Node.js-Versionen node-versions
Die Frontend-Build-Umgebung unterstützt die folgenden Node.js
:
- 18
- 16
- 14 (Standard)
- 12
Mithilfe der NODE_VERSION
Umgebungsvariante können Sie die gewünschte Version festlegen.
Best Practices für die Benennung und Verwaltung von Frontend-Pipelines in AEM single-source-of-truth
Eine Best Practice für AEM-Bereitstellungen besteht darin, eine zentrale, eindeutige Datenquelle zu verwenden. Cloud Manager soll diesen Grundsatz bekräftigen. Da die Frontend-Pipeline jedoch die Entkopplung von Teilen des Codes ermöglicht, ist eine ordnungsgemäße Einrichtung unerlässlich. Um Konflikte zu vermeiden, stellen Sie sicher, dass nicht mehrere Frontend-Pipelines innerhalb derselben Umgebung auf derselben Site bereitgestellt werden.
Aus diesem Grund und insbesondere bei der Erstellung mehrerer Frontend-Pipelines empfiehlt Adobe die Beibehaltung einer systematischen Namenskonvention. Sie können die folgenden Empfehlungen verwenden:
- Der Name des Frontend-Moduls, der durch die
name
-Eigenschaft der Dateipackage.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 Beispielwknd-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 etwawknd-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 bereitgestellt wird (Produktion oder Entwicklung). Für das Frontend-Modul mit dem Namen
wknd-theme
kann die Pipeline beispielsweisewknd-theme-prod
benannt werden.
Eine solche Konvention verhindert die folgenden Bereitstellungsfehler:
- 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 Bereitstellungen zu garantieren.
Koordinieren der Frontend- und Backend-Entwicklung für Stabilität in AEM separation-of-concerns
Eine der wichtigsten Best Practices für jede Trennung von Belangen besteht darin, den Vertrag sorgfältig zu entwerfen und zu verwalten, der die Grenzen zwischen ihnen definiert. In der Frontend-Pipeline ist dieser Vertrag die HTML- und JSON-Ausgabe, die von der Site gerendert wird. Durch die Aufrechterhaltung der Stabilität dieser Ausgabe wird sichergestellt, dass die Frontend-Pipeline einen maximalen Wert liefert, sodass das Frontend-Team unabhängig arbeiten kann.
Es gibt derzeit keine integrierte Funktion, um die Full-Stack-Pipeline synchron mit den Frontend-Pipelines auszuführen. Daher ist es bei der Trennung der Frontend-Entwicklung von der Full-Stack-Pipeline wichtig, den Vertrag sorgfältig zu verwalten, der ihre Grenzen definiert. Dieser Vertrag besteht normalerweise aus der HTML oder JSON oder beiden, die von Experience Manager gerendert werden. Alle Änderungen an diesem Vertrag sollten zwischen den Teams, die verschiedene Pipelines verwalten, sorgfältig koordiniert werden, um einen reibungslosen Übergang und eine ordnungsgemäße Abfolge der Aktualisierungen sicherzustellen.
Die folgenden Schritte werden im Allgemeinen empfohlen, wenn Sie Änderungen an der HTML- oder JSON-Ausgabe vornehmen, insbesondere wenn beide Bereiche betroffen sind.
-
Das Backend-Team richtet zunächst eine Entwicklungsumgebung mit der neuen HTML- oder JSON-Ausgabe ein.
-
Über die Full-Stack-Pipeline stellen sie den Code bereit, der zum Rendern der gewünschten neuen HTML- oder JSON-Ausgabe oder beider Komponenten erforderlich ist.
-
Wenn es sich um eine Umgebung handelt, 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.
Eine gängige Praxis ist die Erstellung einer
dev
Verzweigung, um die in der Entwicklungsumgebung vorgenommenen Änderungen zu verwalten. Dies ermöglicht eine einfachere Zusammenführung zurück in diemain
Verzweigung, die für die Bereitstellung in der Produktionsumgebung verwendet wird. -
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.
-
Gehen Sie wie gewohnt zur lokalen Entwicklung wie folgt vor:
- Mit dem Befehl
npx aem-site-theme-builder proxy
wird ein Proxy-Server gestartet, der Inhalte aus einer AEM-Umgebung abruft. Es ersetzt die CSS- und JS-Dateien des Frontend-Moduls durch diese Dateien aus dem lokalendist
. - Durch das Konfigurieren der
AEM_URL
in der ausgeblendeten.env
können Sie steuern, von welcher AEM-Umgebung der lokale Proxy-Server den Inhalt verwendet. - Durch das Ändern des Werts für
AEM_URL
können Sie daher zwischen der Produktions- und Entwicklungsumgebung wechseln, 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.
- Mit dem Befehl
-
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- oder JSON-Ausgabe oder beides über die Full-Stack-Pipeline rendert.
-
Das Frontend-Team kann seine CSS- und JS-Dateien bereinigen, Elemente entfernen, die nur für die alte Ausgabe benötigt werden, und das endgültige Update mithilfe der Frontend-Pipeline für die Produktion bereitstellen.
Zusätzliche Ressourcen additional-resources
-
Erfahren Sie, wie Sie AEM-Site-Designs verwenden, um den Stil und das Design Ihrer Site anzupassen.
Siehe Site-.
-
Adobe bietet einen AEM-Site-Design-Assistenten als Satz von Skripten zum Erstellen neuer Site-Designs.
Siehe AEM-Site-Design-Builder