Developing Sites with the Front-End Pipeline

Med den främre rörledningen fler oberoende ges till gränssnittsutvecklare och utvecklingsprocessen kan gå mycket snabbare. I det här dokumentet beskrivs hur den här processen fungerar tillsammans med vissa överväganden som du bör vara medveten om för att få ut mesta möjliga av processen.

Front-End Build Contract

Liknar byggmiljö i full hög, den främre rörledningen har en egen miljö. Utvecklarna har viss flexibilitet i den här pipeline så länge som följande frontavtal gäller.

För frontendpipeline krävs att front-end-Node.js-projektet använder build skriptdirektiv för att generera det bygge som ska distribueras av frontendpipeline. I.e.e. Cloud Manager använder kommandot npm run build för att generera ett driftsättningsbart projekt till dist mapp.

Innehållet i dist är den mapp som distribueras till AEM as a Cloud Service från molnhanterarens pipeline.

Nodversioner

Som standard används nod 14 i den främre pipelinen, men 12 och 16 är också tillgängliga.

Du kan använda CM_CUSTOM_VAR_NODE_VERSION systemvariabel för att ange önskad version.

En källa för sanning

Ett allmänt bra tillvägagångssätt är att behålla en enda sanningskälla för det som används för AEM. Cloud Managers mål är att göra den enda källan till sanning uppenbar. Eftersom frontdelsrörledningen tillåter avkoppling av platsen för delar av koden ligger dock ett visst extra ansvar i den korrekta konfigurationen av frontdelsrörledningarna. Man måste vara försiktig så att man inte skapar flera rörledningar som kan användas på samma plats i samma miljö.

Av denna anledning, och särskilt när flera rörledningar för framände skapas, rekommenderas att en systematisk namnkonvention upprätthålls, som följande:

• Namnet på frontmodulen, som definieras av name egenskapen för package.json filen, ska innehålla namnet på den plats den gäller för. För en plats som finns på /content/wknd, namnet på frontmodulen skulle vara ungefär som wknd-theme.
• När en frontendmodul delar samma Git-databas med andra moduler bör namnet på dess mapp vara lika med, eller innehålla samma namn för, frontendmodulen. Om till exempel front end-modulen har ett namn wknd-theme, skulle namnet på den omslutande mappen vara något som wknd-theme-sources.
• Namnet på Cloud Managers frontendpipeline bör även innehålla namnet på den främre slutmodulen och även lägga till miljön som den distribuerar till (produktion eller utveckling). Till exempel för frontmodulen med namnet wknd-themekan rörledningen heta något som wknd-theme-prod.

En sådan konvention bör effektivt förhindra följande misstag i samband med driftsättningen:

• Använda en frontendmodul på fel plats
• Skapa flera frontendmoduler som använder samma plats, vilket skulle skriva över varandra
• Skapa flera rörledningar för samma källor, vilket kan orsaka konkurrensförhållanden, utan att garantera ordningen för driftsättningar

Separation av oro

En annan bra metod som gäller för varje separation av frågor är att lägga särskild vikt vid hur det kontrakt som avskiljer bekymren utformas och hanteras. När det gäller front end-rörledningen är det kontrakt som skiljer koden från resten HTML och JSON som renderas av anläggningen. Om HTML och JSON förblir stabila ger frontlinjen maximalt värde genom att göra front-end-teamet helt oberoende.

Det finns för närvarande ingen specifik funktion för att köra helstackspipeline synkront med frontendspipeline(en). Därför måste man vid frikopplingen av frontdelsutvecklingen från rörledningen i full hög lägga in extra omsorg i kontraktet som avgränsar dessa två problemområden. Kontraktet är i allmänhet det HTML och/eller JSON som Experience Manager återger. Förändringar av detta avtal måste därför vara välplanerade mellan de grupper som driver de olika rörledningarna så att de är överens om hur de ska sekvensera motsvarande ändringar.

Följande steg rekommenderas i allmänhet när det är nödvändigt att ändra HTML och/eller JSON-utdata som påverkar båda problemområdena.

1. Back-end-teamet skapar först en utvecklingsmiljö med nya HTML och/eller JSON-utdata.
   1. Via rörledningen för hela stacken distribuerar de den kod som krävs för att återge de nya HTML- och/eller JSON-utdata som önskas.
   2. Om det är i en miljö som front-end-teamet inte tidigare har åtkomst till måste följande steg utföras.
      1. URL: Utvecklingsteamet måste känna till URL:en för den utvecklingsmiljön.
      2. ACL: front-end-teamet måste få en lokal AEM med rättigheter som liknar"Medarbetare".
      3. Git: front-end-teamet måste ha en separat Git-plats för front-end-modulen som är särskilt inriktad på den utvecklingsmiljön.
         • Ett vanligt tillvägagångssätt är att skapa en dev så att de ändringar som gjorts för utvecklingsmiljön sedan enkelt kan sammanfogas i main filial som ska distribueras till produktionsmiljön.
      4. Rörledning: front-end-teamet måste ha en front-end-pipeline som distribueras till utvecklingsmiljön. Den rörledningen distribuerar den frontdelsmodul som vanligtvis finns i dev gren, enligt beskrivningen i föregående punkt.
2. Det ledande teamet får sedan CSS- och JS-koden att fungera med både gamla och nya utdata.
   1. Som vanligt för att utveckla lokalt:
      1. The npx aem-site-theme-builder proxy -kommandot som körs i front end-modulen startar en proxyserver som begär innehållet från en AEM-miljö och ersätter CSS- och JS-filerna för front end-modulen med de som finns i den lokala dist mapp.
      2. Konfigurera AEM_URL variabeln i det dolda .env kan styra från vilken AEM som den lokala proxyservern använder innehållet.
      3. Ändra värdet för detta AEM_URL gör det därför möjligt att växla mellan produktions- och utvecklingsmiljöer för att justera CSS och JS så att den passar båda miljöerna.
      4. Det måste fungera med den utvecklingsmiljö som återger det nya resultatet och med den produktionsmiljö som återger det gamla resultatet.
   2. Det färdiga arbetet slutförs när den uppdaterade frontmodulen fungerar för båda miljöerna och distribueras till båda.
3. Back-end-teamet kan sedan uppdatera produktionsmiljön genom att distribuera koden som återger de nya HTML- och/eller JSON-utdata via hela stacken.
4. front-end-teamet kan sedan rensa upp sin CSS och JS och ta bort det som bara behövdes för den gamla versionen, och driftsätta den senaste uppdateringen till produktionen via front-end-flödet.

Ytterligare resurser

• Webbplatsteman - Lär dig hur AEM teman kan användas för att anpassa webbplatsens stil och design.
• AEM Site Theme Builder - Adobe tillhandahåller en AEM Site Theme Builder som en uppsättning skript för att skapa nya webbplatsteman.

Resurser för Business.Adobe.com