Sites ontwikkelen met behulp van de voorste pijplijn developing-site-with-front-end-pipeline
met de front-end pijpleiding,meer onafhankelijkheid wordt gegeven aan de front-end ontwikkelaars en het ontwikkelingsproces kan aanzienlijke snelheid bereiken. In dit document wordt beschreven hoe dit proces werkt, samen met een aantal overwegingen, zodat u optimaal kunt profiteren van dit proces.
Front-end bouwcontract front-end-build-contract
Gelijkaardig aan volledig-stapel bouwt milieu,de front-end pijpleiding heeft zijn eigen milieu. De ontwikkelaars hebben wat flexibiliteit gebruikend deze pijpleiding zolang het volgende front-end bouwcontract wordt waargenomen.
De front-end pijpleiding vereist het front-end project Node.js om de build manuscriptrichtlijn te gebruiken om de bouwstijl te produceren die het opstelt. Dit komt doordat Cloud Manager de opdracht npm run build gebruikt om het implementeerbare project voor de front-end build te genereren.
De resulterende inhoud van de map dist is de inhoud die uiteindelijk door Cloud Manager wordt geïmplementeerd en die als statische bestanden fungeert. Deze bestanden worden extern naar AEM gehost, maar worden via een /content/... URL beschikbaar gesteld in de geïmplementeerde omgeving.
Node-versies node-versions
De front-end bouwt milieu steunt de volgende versies Node.js.
- 12
- 14 (standaard)
- 16
- 18
U kunt de NODE_VERSION milieuvariabelegebruiken om de gewenste versie te plaatsen.
Single Source of Truth single-source-of-truth
Een algemene goede praktijk is één enkele bron van waarheid te handhaven voor wat wordt ingezet aan AEM. Het doel van Cloud Manager is die ene bron van waarheid voor de hand te leggen. Aangezien de front-end pijplijn echter de ontkoppeling van de locatie voor delen van de code mogelijk maakt, ligt een extra verantwoordelijkheid in de correcte installatie van de front-end pijpleidingen. Er moet voorzichtig worden omgesprongen met het aanmaken van meerdere front-end pijpleidingen die op dezelfde locatie in dezelfde omgeving worden geïmplementeerd.
Daarom, en met name wanneer meerdere voorste pijpleidingen worden aangelegd, wordt aanbevolen een conventie voor systematische naamgeving te handhaven, zoals:
- De naam van de front-end module, die wordt gedefinieerd door de eigenschap
namevan hetpackage.json-bestand, moet de naam bevatten van de site waarop deze van toepassing is. Voor een site in/content/wkndzou de naam van de front-end module bijvoorbeeld ongeveer gelijk zijn aanwknd-theme. - Als een front-end module dezelfde Git-opslagplaats deelt met andere modules, moet de naam van de bijbehorende map gelijk zijn aan of dezelfde naam van de front-end module bevatten. Als de front-end module bijvoorbeeld de naam
wknd-themeheeft, zou de omsluitende mapnaam ongeveerwknd-theme-sourceszijn. - De naam van de Cloud Manager front-end pijpleiding zou ook de naam van de front-end module moeten bevatten en ook het milieu toevoegen waarop het (productie of ontwikkeling) opstelt. Voor de front-end module met de naam
wknd-themezou de pijpleiding bijvoorbeeld een naam kunnen krijgen zoalswknd-theme-prod.
Een dergelijke conventie moet op efficiënte wijze de volgende implementatiefouten voorkomen:
- Een front-end module toepassen op de verkeerde site
- Het creëren van veelvoudige front-end modules die de zelfde plaats toepassen, die elkaar zouden beschrijven
- Het creëren van veelvoudige front-end pijpleidingen voor de zelfde bronnen, die rasvoorwaarden kunnen veroorzaken, die de orde van plaatsingen niet waarborgen
Scheiding van bezorgdheid separation-of-concerns
Een andere goede praktijk die van toepassing is op elke scheiding van zorgen, is speciale aandacht te besteden aan de wijze waarop het contract dat de zorgen scheidt, wordt ontworpen en beheerd. In het geval van de front-end pijpleiding is het contract dat deze code scheidt van de rest de HTML en JSON die door de locatie worden weergegeven. Als die HTML en JSON stabiel blijven, dan levert de front-end pijpleiding zijn maximumwaarde door het front-end team volledig onafhankelijk te maken.
Er is momenteel geen specifiek vermogen om de full-stack pijpleiding synchroon met de front-end pijpleiding(en) in werking te stellen. Daarom moet bij de ontkoppeling van de ontwikkeling aan de voorzijde van de volledige stapelleiding extra aandacht worden besteed aan het contract dat deze twee aandachtsgebieden van elkaar scheidt. Dat contract is doorgaans de HTML en/of JSON die de Experience Manager afgeeft. Wijzigingen in dat contract moeten daarom goed worden gepland tussen de teams die de verschillende pijpleidingen exploiteren, zodat zij het eens worden over de wijze waarop de overeenkomstige wijzigingen moeten worden gesequenceerd.
De volgende stappen worden over het algemeen aanbevolen wanneer het nodig is om wijzigingen in de HTML en/of JSON-uitvoer uit te voeren die van invloed zijn op beide aandachtsgebieden.
-
Het back-end team stelt eerst een ontwikkelomgeving in met de nieuwe HTML en/of JSON-uitvoer.
-
Via de full-stack pijplijn, voeren zij de code op die wordt vereist om de nieuwe HTML en/of output terug te geven JSON die gewenst is.
-
Als dat aan een milieu is dat het front-end team niet eerder toegang tot had, dan moeten de volgende stappen worden uitgevoerd.
- URL: Het front-end team moet URL van die ontwikkelomgeving kennen.
- ACL: Het front-end team moet een lokale AEM gebruiker met iets gelijkend op "Medewerkers"rechten worden gegeven.
- Git: Het front-end team moet een afzonderlijke plaats van het Git voor de front-end module hebben die specifiek die ontwikkelomgeving richt.
- Een gebruikelijke werkwijze is het maken van een
dev-vertakking, zodat de wijzigingen die voor de ontwikkelomgeving zijn aangebracht, vervolgens eenvoudig weer kunnen worden samengevoegd met demain-vertakking die moet worden geïmplementeerd in de productieomgeving.
- Een gebruikelijke werkwijze is het maken van een
- Pijpleiding: Het front-end team moet een front-end pijpleiding hebben die aan de ontwikkelomgeving opstelt. Die pijpleiding zou de front-end module opstellen die typisch in de
devtak, zoals die in het vorige punt wordt beschreven wordt gevestigd.
-
-
Het front-end team maakt dan CSS en JS code werk met zowel oude als nieuwe output.
-
Zoals gebruikelijk, om plaatselijk te ontwikkelen:
- Met de opdracht
npx aem-site-theme-builder proxydie wordt uitgevoerd in de front-end module, wordt een proxyserver gestart die de inhoud opvraagt vanuit een AEM omgeving, terwijl de CSS- en JS-bestanden van de front-end module worden vervangen door de bestanden van de lokaledist-map. - Wanneer u de variabele
AEM_URLin het verborgen.env-bestand configureert, kunt u bepalen vanuit welke AEM omgeving de lokale proxyserver de inhoud gebruikt. - Als u de waarde van deze
AEM_URLwijzigt, kunt u daarom schakelen tussen de productie- en ontwikkelomgevingen om de CSS en JS aan te passen aan beide omgevingen. - Het moet met de ontwikkelomgeving werken die de nieuwe output teruggeeft en met het productiemilieu dat de oude output teruggeeft.
- Met de opdracht
-
Het front-end werk wordt voltooid wanneer de bijgewerkte front-end module voor beide milieu's werkt, en aan allebei wordt opgesteld.
-
-
Het back-end team kan de productieomgeving dan bijwerken door de code in te voeren die de nieuwe HTML en/of JSON-uitvoer via de full-stack pijplijn rendert.
-
Het front-end team kan dan hun CSS en JS opschonen en verwijderen wat slechts door de oude output nodig was, die laatste update aan productie via de front-end pijpleiding opstelt.
Aanvullende bronnen additional-resources
- Thema's van de Plaats- leer hoe AEM plaatsthema's kunnen worden gebruikt om de stijl en het ontwerp van uw plaats aan te passen.
- AEM de Bouwer van het Thema van de Plaats- de Adobe verstrekt een AEM Bouwer van het Thema van de Plaats als reeks manuscripten voor het creëren van nieuwe plaatsthema's.