Seks bedste praksisser til hjemmesideprojekter med Adobe Experience Manager

Men som det er tilfældet med alle produkter i denne størrelse, er det også meget nemt at træffe de forkerte beslutninger. AEM er et meget fleksibelt produkt, der kan tilpasses dine specifikke behov. Det betyder, at alle krav kan omsættes og realiseres på forskellige måder med alt fra en skræddersyet løsning til en løsning, der er nøje afstemt med produktets kerneprincipper.

Med vores brede erfaring med implementering af AEM og med systemer til administration af indhold til hjemmesider i almindelighed kender vi de faldgruber, der kan være ved at vælge en af de forskellige løsningsretninger. Ud over løsningsarkitektur og potentiel teknisk dybde er det vigtigt også at tænke i omkostningseffektivitet og vedligeholdelsesmuligheder samt muligheden for at fremtidssikre dit system.

I dette blogindlæg vil vi fremhæve nogle af de vigtigste faktorer, du bør overveje, når du implementerer AEM.

#1 Design og arkitektur

Når det kommer til din hjemmesides design og arkitektur, bør du først grundigt overveje, hvilke krav du har til det. Derudover bør du så vidt muligt tænke i allerede eksisterende løsninger, hvad angår software og værktøjer. Prototyper kan bruges til at gå kommunikere alternative løsninger til erhvervsbrugere og til at demonstrere visse såkaldte "out of the box"-funktioner. I de fleste tilfælde kan der opnås en betydelig grad af effektivitet ved at tilpasse de oprindelige krav en smule.

Eksempler:

• Udnyt den kontekstbevidste konfigurationsramme til at få hjemmesidens underelementer til at se anderledes ud og opføre sig anderledes.
• Gengiv dokumentlister, der ved hjælp af Sling Dynamic Include-rammen hentes fra eksterne systemer, for at gøre det muligt at cache de sider, der indeholder dem.
• Brug Sling Resource Merger, der skal forhindre duplikering af "out of the box"-komponenter.
• Fjern responsiv CSS og udnyt funktionaliteter i AEM til det.
• Implementer visse krav uden for AEM, for eksempel ved at integrere med eksterne (mikro)services. Dette er vigtigt for at forebygge "misbrug" af AEM som et WCMS.
• Gør det muligt at cache mere end 95 % af anmodningerne for at sikre høj ydeevne.

#2 Kernekomponenter

For et par år siden startede Adobe et initiativ, de kaldte WCM Core Components. Tanken var at bevæge sig væk fra de gamle og forældede "Foundation Components" og i stedet levere et solidt bibliotek med komponenter, som alle projekter kunne bygge videre på.

Biblioteket af kernekomponenter giver brugere et sæt byggeklodser til at lave avancerede hjemmesider. Ud fra disse principper har vi også udviklet vores eget sæt af (projektspecifikke) komponenter. Dette betyder samtidigt, at vi aktivt bidrager med kernekomponenter og løbende hjælper dem med at blive bedre.

Ved at bruge disse komponenter og udnytte tankerne bag dem er vi i stand til at opsætte ekstremt fleksible kodebaser og få mulighed for at opgradere komponenter én for én, uden at bryde bagudkompatibiliteten.

#3 Redigerbare skabeloner

Tidligere var det udvikleren, der skulle gøre et sæt sideskabeloner klar til brugerne. Før en indholdsforfatter kunne bruge en specifik skabelon, skulle en udvikler først implementere skabelonen og indsætte den i AEM. Dette betød ofte øget lanceringstid.

Men inden for de seneste få år har vi fået en funktion i AEM kaldet "Editable Templates" (redigerbare skabeloner), der mindsker afhængigheden af IT, når der skal oprettes nye sider. "Editable Templates" giver indholdsforfatteren mulighed for selv at sammensætte skabeloner ved hjælp af grænsefladen AEM Touch UI.

#4 Responsivt gitter- og stilsystem

Ved at bruge responsive gitre kan brugeren håndtere sidelayouts og komponenter på en fleksibel måde. Kombineret med AEM's stilsystem kan der anvendes foruddefineret styling uden at give køb på sidernes ensartede præg.

For at gøre indholdet responsivt har det traditionelt set været nødvendigt at involvere en designer til at lave mockups til de forskellige brudpunkter, en udvikler til at implementere dem til en specifik skabelon og en forfatter til at vælge skabelonen og fylde indhold på. Med responsive gitre er denne proces blevet meget mere simpel. Forfatteren fylder indholdet på og kan selv tilpasse layoutet, uden at det er nødvendigt at rådføre sig med en udvikler om responsivitet eller vente på nye softwaremuligheder. Denne funktion, der blev introduceret med AEM 6.3, giver brugere fleksibilitet uden behovet for at involvere udviklere til at løse disse opgaver. Endelig slipper man for at rådføre sig med en udvikler (og investere i ny software) for at ændre en skabelon.

Men fleksibilitet koster. Brugerne skal nu administrere layout-indstillingerne for sidekomponenter, og det kan være en større opgave. Det er ofte bedre at vælge en mellemting, hvor nogle layout-indstillinger er faste, og andre er gjort fleksible. Vi kan hjælpe dig med at finde den rigtige balance.

#5 Bedste praksisser til hjemmesideudvikling

Vi arbejder også ud fra en række generelle bedste praksisser til udvikling samt specifikke tekniske AEM-standarder i alle AEM-projekter. Lad os rekapitulere nogle af dem:

• Den, der ødelægger et build, skal fikse det igen.
• Alle nye funktioner skal udsættes for komponenttests og integrationstests.
• Merge-anmodninger skal sendes, når en funktion er klar.
• Den tekniske leder skal udføre en peer-review.
• Der skal bruges Sling Models til komponentudvikling, selvom komponenten er meget enkel.
• Der skal bruges Proxy Component Pattern.
• Brugerdokumentation og teknisk dokumentation skal altid være opdateret.
• Koden skal testes på AEM, såvel som gennem Dispatcher.
• Duplikering af kode er ikke tilladt, SonarQube-regler skal være konfigureret, hvert build skal udløse en SonarQube-scanning osv.

#6 Komplet automatisering

For at øge kvaliteten i vores arbejde bliver vi nødt til at gå all in på automatisering. Når vi skal installere AEM 6.5 hos kunder, bruger vi eksempelvis infrastruktur-som-kode til at automatisere opsætningen af servere såvel som vores lokale miljøer. Det betyder, at enhver udvikler kan være oppe i omdrejninger på få minutter og arbejde på et lokalt miljø, der er så tæt på den endelige produktion som muligt. Denne opsætning inkluderer endda en lokal Dispatcher-instans, der skal sikre, at vi også fanger caching-fælder med det samme.

Til installationer af AEM-as-a-Cloud-Service får vi stor hjælp fra Adobes Cloud Manager, der fuldt du automatiserer, opgraderer, lukker sikkerhedshuller og udgiver, kombineret med foruddefinerede og tilpassede gates i høj kvalitet.

Hver gang en kodeændring tjekkes i versionskontrol, udføres et build, og udvikleren får øjeblikkeligt besked, hvis noget går galt. Alt afhængig af den specifikke afdeling vil der blive foretaget en udrulning til det relevante miljø, så ændringer straks vises i det rigtige system.

Ved at følge disse principper opnår vi den nødvendige fleksibilitet til at foretage fuldautomatisk udgivelse. Det betyder, at en udrulning til produktion sker ved et simpelt tryk på en knap.

Konklusion

Det er vigtigt at kende de seneste bedste praksisser, der er specifikke for hjemmesideudvikling i det WCMS, du arbejder med. Men det er måske endnu vigtigere at have en partner, der kender dem og også bruger dem i projektteamet, for at få succes med dit projekt. Disse retningslinjer er ikke kun gode at følge, når du opretter nye hjemmesider, men også når du planlægger opgraderinger eller en udvidelse af din eksisterende Adobe-platform.