Sex exempel på bästa praxis för webbplatsprojekt med Adobe Experience Manager

Men precis som med alla produkter i så stor skala är det också lätt hänt att fel beslut fattas. AEM är en mycket flexibel produkt som möjliggör många anpassningar. Det innebär att eventuella krav kan översättas till olika implementeringar, från en specialbyggd lösning till en lösning som nära följer produktens grundprinciper.

Eftersom vi har bred erfarenhet av att implementera AEM och företagssystem för webbinnehållshantering i allmänhet, känner vi till fallgroparna när du ska välja någon av de olika lösningsinriktningarna. Förutom lösningsarkitektur och potentiellt tekniskt djup är det viktigt att även tänka på kostnadseffektivitet och underhåll, samt att säkerställa att systemet är framtidssäkrat.

I detta inlägg vill vi belysa några av de viktigaste faktorerna du bör tänka på när du implementerar AEM.

1. Design och arkitektur

När det gäller design och webbplatsarkitektur, bör det första steget vara att grundligt utvärdera alla krav och i ett så tidigt skede som möjligt och kontrollera om de omfattas av standardfunktionerna. Prototyper kan användas för att kommunicera alternativa lösningar till affärsanvändare och demonstrera vissa standardfunktioner. I de flesta fall kan du göra stora effektivitetsvinster genom små anpassningar av de inledande kraven.

Några exempel:

• Utnyttja Context-Aware Configuration-ramverket för att ge olika delar av webbplatsen olika funktioner och utseende.
• Rendera dokumentlistor från externa system via Sling Dynamic Include-ramverket så att de sidor som innehåller listorna fortfarande går att cachelagra.
• Använda Sling Resource Merger för att undvika att skapa nya komponenter med samma funktioner som standardkomponenterna.
• Undvika responsiv CSS och utnyttja funktioner inbyggda i AEM istället.
• Implementera vissa krav utanför AEM, till exempel genom att integrera med externa (mikro)tjänster. Detta är viktigt för att undvika att ”missbruka” AEM som ett WCMS.
• Göra mer än 95 % av förfrågningarna möjliga att cachelagra, vilket säkerställer hög prestanda.

2. Kärnkomponenter

För ett par år sedan inledde Adobe ett initiativ med namnet WCM Core Components. Tanken var att övergå från de gamla ”grundkomponenterna”, som blivit omoderna, och istället tillhandahålla ett stabilt bibliotek av komponenter på vilka varje projekt kan byggas.

Detta bibliotek med kärnkomponenter ger företagsanvändare tillgång till en uppsättning högkvalitativa byggstenar för att skapa avancerade webbsidor. Enligt samma principer har vi även utvecklat vår egen uppsättning (projektspecifika) komponenter. Det innebär också att vi aktivt bidrar till att kärnkomponenterna förbättras över tid.

Genom att använda dessa komponenter och utnyttja tankarna bakom dem, kan vi skapa extremt flexibla kodbaser och skaffa möjlighet att uppgradera komponenterna en i taget, utan att skada bakåtkompatibiliteten.

3. Redigerbara mallar

Tidigare var det utvecklarnas uppgift att skapa en uppsättning sidmallar tillgängliga för företagsanvändare: för att en innehållsskapare skulle kunna använda en specifik mall behövde utvecklaren först implementera mallen i AEM. Detta resulterade ofta i ökad tid till marknaden.

Under de senaste åren har en funktion som heter ”Redigerbara mallar” gjorts tillgänglig i AEM för att minska beroendet av IT när sidorna skapas. ”Redigerbara mallar” gör att innehållsskapare själva kan sammanställa mallar med hjälp av AEM Touch UI-gränssnittet.

4. Responsivt system med rutnät och stilar

Med hjälp av responsiva rutnät kan företagsanvändare hantera sidlayouter och komponenternas funktioner på ett flexibelt sätt. I kombination med AEM-stilsystemet kan fördefinierade stilar användas utan att ge avkall på enhetligheten mellan sidorna.

Tidigare krävde arbetsflödet för att göra innehållet responsivt att en designer skapade modeller för de olika brytpunkterna, att utvecklaren implementerade dem för en specifik mall och att innehållsskaparen valde mallen och fyllde i innehållet. Med responsiva rutnät har detta arbetsflöde förenklats dramatiskt: innehållsskaparen fyller i innehållet och kan anpassa layouten på egen hand, utan behov av att samverka med en utvecklare avseende responsivitet eller vänta på nya implementeringar. Den här funktionen, som infördes i AEM 6.3, ger företagsanvändare mer flexibilitet, samtidigt som den inte kräver att utvecklare utför dessa uppgifter. Avslutningsvis krävs heller inget arbete med utveckling (eller implementering) för att ändra en mall.

Den här flexibiliteten har dock ett pris: företagsanvändarna måste nu hantera layoutinställningarna för komponenter på sidorna, och det kan kräva mycket arbete. Det är oftast bättre att hitta ett mellanläge där vissa layoutinställningar är fasta och andra lämnas flexibla. Vi kan hjälpa dig att hitta rätt balans.

5. Bästa praxis för webbutveckling

Det finns också bästa praxis för utveckling i allmänhet samt specifika tekniska AEM-standarder som vi tillämpar för alla AEM-projekt. För att nämna några:

• Den som skadar en version, reparerar versionen.
• Enhetstester och integreringstester krävs för varje ny funktion.
• En begäran om sammanslagning måste skickas när en funktion är färdig.
• En inbördes granskning måste utföras av en teknisk chef.
• Slingmodeller måste användas för komponentutveckling, även om komponenten är mycket enkel.
• Använd Proxy Component Pattern.
• Användardokumentation och teknisk dokumentation måste alltid vara uppdaterad.
• Koden måste testas på AEM, samt via Dispatcher.
• Kod får inte dupliceras, SonarQube-regler måste konfigureras och varje version ska utlösa en SonarQube-skanning osv.

6. Full automatisering

För att öka kvaliteten på vårt arbete strävar vi efter att maximera automationen. För installation av AEM 6.5 på plats använder vi infrastruktur som kod för att automatisera konfigurationen av servrar, tillsammans med våra lokala miljöer. Det innebär att alla utvecklare kan komma igång på bara några minuter och arbeta i en lokal miljö som ligger så nära produktionen som möjligt. Denna konfiguration innehåller även en lokal Dispatcher-instans för att säkerställa att vi även fångar upp problem med cachelagring omedelbart.

För installationer med AEM som molntjänst får vi mycket hjälp från Adobes Cloud Manager, som fullt ut automatiserar uppgraderingar, säkerhetskorrigeringar och nya versioner, i kombination med fördefinierade och anpassade kvalitetsgrindar.

Varje gång en kodändring checkas in i versionskontrollen skapas en ny version och utvecklarna meddelas direkt när något går fel. Beroende på den specifika grenen sker en implementering i tillämplig miljö, så att förändringarna omedelbart visas i rätt system.

I enlighet med dessa principer är vi flexibla när det gäller att hantera våra versioner på ett helt automatiserat sätt. Implementeringen i produktionen kan ske med en enkel knapptryckning.

Slutsats

Det är avgörande att känna till senaste bästa praxis specifik för utveckling av webbplatser i den WCMS du arbetar med. För att ditt digitala upplevelseprojekt ska lyckas är det kanske ännu viktigare att ha en partner som känner till bästa praxis och ser till att den följs i projektteamet. Dessa riktlinjer är inte bara värdefulla när du skapar nya webbplatser, utan också vid planering av uppgraderingar eller en utökning av en befintlig Adobe-plattform.