Zes beste praktijken voor websiteprojecten in Adobe Experience Manager

Net zoals bij alle producten met een dergelijke omvang is het echter ook heel makkelijk om de verkeerde beslissingen te nemen. AEM is een heel flexibel product met diverse personalisatie-opties. Dit houdt in dat elke vereiste omgezet kan worden naar verschillende soorten implementaties, gaande van een op maat gemaakte oplossing tot een oplossing die nauwgezet aansluit op de basisprincipes van het product.

Dankzij onze ruime ervaring met de implementatie van AEM en webcontentbeheersystemen voor bedrijven in het algemeen kennen wij de valkuilen die gepaard gaan met het kiezen van een van de verschillende oplossingen. Naast oplossingsarchitectuur en potentiële technische diepte is het ook belangrijk om te denken aan rendabiliteit en handhaafbaarheid dan wel om te waarborgen dat jouw systeem toekomstbestendig is.

In deze post gaan wij dieper in op een aantal belangrijke factoren die jij tijdens de implementatie van AEM niet uit het oog mag verliezen.

#1 Design & architectuur

Bij design en websitearchitectuur bestaat de eerste stap steeds uit een grondige evaluatie van elke vereiste en een zo snel mogelijke afstemming op kant-en-klare capaciteiten. Prototyping kan worden gebruikt om alternatieve oplossingen te bespreken met businessgebruikers en een aantal kant-en-klare mogelijkheden voor te stellen. In de meeste gevallen kan heel wat effectiviteit worden gewonnen door de oorspronkelijke vereisten enigszins aan te passen.

Enkele voorbeelden:

• Gebruik het framework Context-Aware Configuration om ervoor te zorgen dat subdelen van de website er anders uitzien en zich anders gedragen;
• Genereer documentlijsten die voortkomen uit externe systemen via het framework Sling Dynamic Include om ervoor te zorgen dat pagina's die deze bevatten, nog steeds cachebaar zijn;
• Gebruik Sling Resource Merger om te vermijden dat kant-en-klare componenten gedupliceerd worden;
• Verwijder responsieve CSS en gebruik hiervoor functies binnen AEM;
• Implementeer bepaalde vereisten buiten AEM, bijv. door een integratie met externe (micro)diensten. Dit is essentieel om te vermijden dat AEM "verkeerd gebruikt" wordt als WCMS;
• Zorg ervoor dat meer dan 95% van de verzoeken cachebaar zijn om een hoge prestatie te waarborgen.

#2 Core Components

Een aantal jaren geleden begon Adobe met het initiatief "WCM Core Components". Het idee was om afstand te nemen van de oude "Foundation Components" die verouderd waren en om in de plaats daarvan te voorzien in een degelijke bibliotheek van componenten op basis waarvan elk project kon uitbreiden.

In deze bibliotheek van Core Components vinden businessgebruikers een reeks kwalitatief hoogstaande bouwblokken waarmee zij geavanceerde webpagina's kunnen creëren. Op basis van dezelfde principes hebben wij onze eigen reeks van (projectspecifieke) componenten ontwikkeld. Dit betekent ook dat wij actief bijdragen aan Core Components, zodat zij in verloop van tijd verbeteren.

Door deze componenten te gebruiken en de ideeën erachter toe te passen, kunnen wij uiterst flexibele codebases opstellen en de mogelijkheid bieden om componenten één voor één te upgraden zonder dat de achterwaartse compatibiliteit in het gedrang komt.

#3 Editable Templates

Voorheen was het de taak van de developer om een reeks paginatemplates ter beschikking te stellen van businessgebruikers: vooraleer een contentauteur een specifieke template kon gebruiken, moest een developer de template eerst implementeren en vervolgens toekennen aan AEM. Dit zorgde vaak voor een langere time-to-market.

De laatste jaren kreeg AEM evenwel een nieuwe feature met de naam "Editable Templates". Hierdoor was het minder vaak nodig om een beroep te doen op IT bij het bouwen van pagina's. Dankzij "Editable Templates" kunnen contentauteurs zelf templates opstellen met behulp van de Touch UI-interface van AEM.

#4 Responsive Grid & Style System

Via Responsive Grids kunnen businessgebruikers op een flexibele wijze omgaan met paginalay-outs en componentengedrag. Vooraf vastgelegde styling kan in combinatie met het Style System van AEM worden toegepast zonder dat de consistentie op de pagina's in het gedrang komt.

Bij de traditionele workflow om content responsief te maken, was het noodzakelijk dat een ontwerper modellen creëerde voor de verschillende breakpoints, dat de developer deze implementeerde voor een specifieke template en dat de auteur die template selecteerde en de content invoerde. Responsive Grids zorgden voor een aanzienlijke vereenvoudiging van deze workflow: de auteur vult de content in en kan de lay-out zelf aanpassen, zonder dat het nodig is om een developer te raadplegen over responsiviteitskwesties of te wachten op nieuwe toekenningen. Deze feature die geïntroduceerd is in AEM 6.3, biedt businessgebruikers flexibiliteit en zorgt ervoor dat developers deze taken niet langer hoeven uit te voeren. Bovendien is er geen enkele ontwikkelings- (en toekennings)inspanning nodig om een template te veranderen.

Deze flexibiliteit heeft evenwel zijn prijs: de businessgebruikers moeten nu de lay-outsettings van componenten op pagina's beheren en dit kan heel wat inspanning vergen. Het is vaak beter om een middenweg te zoeken waarbij sommige lay-outsettings vastliggen en andere flexibel zijn. Wij kunnen jou helpen om het juiste evenwicht te zoeken.

#5 Beste praktijken op het gebied van webontwikkeling

In al onze AEM-projecten passen wij ook algemene beste praktijken voor ontwikkeling en specifieke technische AEM-normen toe. Zoals:

• Help je de creatie om zeep, dan moet jij deze opnieuw maken;
• Voor elke nieuwe feature moeten unittests en integratietests worden uitgevoerd;
• Samenvoegverzoeken moeten worden verzonden wanneer een feature klaar is;
• Een technisch verantwoordelijke moet een peerreview uitvoeren;
• Sling Models moeten worden gebruikt voor de ontwikkeling van componenten, zelfs als de component heel eenvoudig is;
• Gebruik Proxy Component Pattern;
• Gebruikers- & technische documentatie moet steeds bijgewerkt zijn;
• Code moet worden getest op AEM en via de Dispatcher;
• Duplicatie van code niet toegelaten, SonarQube-regels geconfigureerd, bij elke creatie wordt automatisch een SonarQube-scan uitgevoerd, enz.

#6 Volledige automatisering

Wij streven naar maximale automatisering om de kwaliteit van ons werk te verhogen. Voor installaties van AEM 6.5 ter plaatse maken wij gebruik van infrastructuur-als-code om de set-up van servers en onze lokale omgevingen te automatiseren. Dit betekent dat elke developer binnen enkele minuten kan beginnen werken aan een lokale omgeving die zo dicht mogelijk bij de productie staat. Deze setup omvat zelfs een onderdeel lokale Dispatcher, zodat cachingvalkuilen onmiddellijk worden opgespoord.

Voor installaties op basis van AEM-as-a-Cloud-Service krijgen wij heel wat hulp van de Cloud Manager van Adobe. Hierbij worden veiligheidsoplossingen en -releases volledig geautomatiseerd en geüpgraded in combinatie met vooraf vastgelegde en gepersonaliseerde kwaliteitspoorten.

Elke keer dat een codewijziging geregistreerd wordt in de versiecontrole, wordt een build uitgevoerd en worden developers onmiddellijk op de hoogte gebracht als er iets misgaat. Afhankelijk van de specifieke sector moet de toekenning worden doorgevoerd in de toepasselijke omgeving, zodat wijzigingen onmiddellijk aanwezig zijn in het juiste systeem.

Als wij deze principes naleven, zijn wij flexibel genoeg om onze releases helemaal automatisch uit te voeren. Een toekenning aan productie vereist slechts een druk op een knop.

Conclusie

Het is essentieel dat jij op de hoogte bent van de laatste beste praktijken op het gebied van websiteontwikkeling in het WCMS waarmee jij werkt. Maar het is mogelijk nog belangrijker dat jij beschikt over een partner die deze beste praktijken kent en toepast binnen het projectteam, want dit is cruciaal voor het succes van jouw project voor digitale ervaring. Deze richtsnoeren zijn niet alleen waardevol bij de opstelling van nieuwe websites, maar ook bij de planning van upgrades of een uitbreiding van jouw bestaande Adobe-platform.