Der Adobe Experience Manager (AEM) ist ein gewaltiges Web-Content-Management-System für Unternehmen. Es strotzt nur so von Funktionen, die den Content-Autor dazu befähigen, im digitalen Bereich einiges umzusetzen zu können.
Wie bei jedem anderen Produkt dieser Größenordnung, passiert es sehr schnell, dass falsche Entscheidungen getroffen werden. AEM ist ein äußerst vielseitiges Produkt, das dem Benutzer eine Reihe an Anpassungsmöglichkeiten bietet. Daher können jegliche Anforderungen in mehrstufigen Implementierungen umgesetzt werden – von einer vom Kern des AEM aus autarken, zugeschnittenen Lösung, bis hin zu einer mit dem Kern des Produkts dicht verwobenen Lösung.
Adobe Experience Manager ist keine gewöhnliche, standardmäßige Website-Plattform
Durch unserer jahrelangen Erfahrung in Sachen Web-Content-Management für Unternehmen und AEM kennen wir alle Fehlerquellen, die aus der Auswahl verschiedener Lösungen resultieren kann. Wir wissen auch bestens über den Grundgedanken hinter dem Produkt Bescheid und können so die kostengünstigste, am Besten zu wartende und zukunftssicherste Lösungen aussuchen.
In diesem Artikel, werde ich die Schlüsselfaktoren hervorheben, die zum Erfolg von Projekten in der Website-Entwicklung in AEM 6.3 führen.
#1 Das Design und die Architektur
Wägen Sie jegliche Anforderung sorgfältig ab und verifizieren Sie diese mit den Funktionen des Produkts. Es kann vorkommen, dass Sie die ursprünglichen Anforderungen anpassen müssen, damit die Möglichkeiten von AEM dem gewünschten Ergebnis vollkommen entsprechen. Hierzu folgen einige Beispiele:
- Machen Sie sich das „Context-Aware Configuration”-Framework zunutze und verändern Sie die Darstellung und das Verhalten von Unterteilen der Website;
- Rendern von Dokumentenlisten, die aus externen Systemen stammen über das „Sling Dynamic Include“-Framework. Dadurch können Seiten, die diese beinhalten, immer noch zwischengespeichert werden;
- Verwendung des „Sling Resource Merger“, um die Duplizierung von direkt aufstellbaren Komponenten zu vermeiden;
- Entfernung von responsive CSS und Nutzung von Funktionalitäten innerhalb des AEM an dessen Stelle;
- Vollständige Entfernung von Anforderungen, da diese nicht dem AEM-Produkt entsprechen;
- Die Möglichkeit, 95+% der Anfragen zwischenzuspeichern, um eine Spitzenleistung zu gewährleisten.
#2 Nutzung der WCM-Core-Komponenten
Endes des Jahres 2015, startete Adobe eine Initiave mit dem Namen „WCM Core Components“. Die Idee dahinter bestand aus der Abrückung von den alten „Foundation“-Komponenten, die in Bezug auf die entstandenen Erfolgsmethoden nicht mehr zeitgemäß waren und ebenso, um ein zuverlässiges Fundament bereitzustellen, aus der sich alle Projekte heraus entwickeln konnten.
Die Nutzung dieser Komponenten ohne jeglicher Anpassung liefert dem Content-Autor zuverlässige, Single-Responsibility-Datenblöcke. Auf der Grundlage der Idee hinter diesen Kernkomponenten, haben wir ebenfalls unsere eigenen (projektbezogenen) Kernkomponenten entwickelt. Während unserer Projekte im digitalen Bereich tragen wir aktiv zu den WCM-Kernkomponenten bei, um dieser weiter zu verbessern.
By using these components and leveraging the idea behind them, we are able to setup a very flexible code-base and gain the possibility to upgrade the components one-by-one, without breaking functionality.
#3 Editierbare Templates
Zuvor lag es am Entwickler, den Content-Autoren Templates zur Verfügung zu stellen. Ein Entwickler erstellte (codierte) ein Template, und stellte diesen dann in AEM zur Verfügung. Daraufhin konnte ein Content-Autor diesen verwenden, um eine Seite auf dessen Grundlage zu erstellen.
In AEM 6.2 wurde eine neue Funktion namens „Editable Templates” eingeführt. Diese Funktion ermöglicht den Content-Autoren, selbst ein Template unter Verwendung der Touch UI zusammenzufügen. Es wird kein Entwickler mehr benötigt, um den Konfigurationsschritt auszuführen.
#4 AEM Responsive Grid und Style System
Unter Verwendung des neuen AEM Responsive Grid in Kombination mit dem brandneuen Style System, können Autoren direkt im Content selbst spezifizieren, wie sich deren Komponenten auf verschiedene Bildschirmgrößen verhalten.
In der Vergangenheit lag es am Designer, ein Abbild der verschiedenen Breakpoints zu erschaffen, um den Content anpassungsfähiger zu gestalten. Daraufhin musste ein Entwickler diese dann für ein spezielles Template implementieren. Erst dann konnte der Content-Autor das Template auswählen und es mit Content ergänzen. Mit der neuen anpassungsfähigen Layoutaufbereitung wurde der Workflow wesentlich vereinfacht: Der Autor fügt nun Content ein und kann das Layout in Bezug auf Anpassungsfähigkeit und neuen Bereitstellungen komplett selbständig anpassen, und das ohne Unterstützung der Entwickler. Diese neue AEM 6.3-Funktion verschafft dem Autor eine große Flexibilität, ohne dass Entwickler vonnöten sind, die sonst diese Aufgaben hätten übernehmen müssen. Es ist also keine Entwicklung- und Bereitstellungsaufwand mehr nötig, um ein Template zu verändern.
#5 Erfolgsmethoden für die Webentwicklung
Es bestehen sowohl globale Erfolgsmethoden für die Entwicklung, wie auch spezielle technische AEM-Standards, die wir über alle AEM-Projekte hinweg durchsetzen. Zusammenfassend hier ein paar Beispiele:
- Wer den Build zerstört, repariert ihn auch;
- Für jede neue Funktionalität werden Modul- und Integrationstests benötigt;
- Die Verwendung von Feature-Branches;
- Es müssen Zusammenlegungen von Anfragen verschickt werden, wenn ein Feature-Branch abgeschlossen wurde;
- Ein Peer-Review muss von einem technischen Leiter ausgeführt werden;
- Für die Komponentenentwicklung muss „Sling Models“ verwendet werden, auch wenn eine Komponente sehr einfach gestaltet ist;
- Der neue „resourceType-Parameter“ muss im „Sling Model“ verwendet werden;
- Verwendung des „Proxy Component Pattern“;
- Das Benutzerhandbuch und technische Dokumentation müssen stets auf dem neuesten Stand sein;
- Der Code muss sowohl auf AEM getestet werden, wie auch durch den Dispatcher laufen;
- Die Code-Duplizierung ist nicht gestattet, SonarQube-Regeln sind konfiguriert, jeder Build leitet einen SonarQube-Scan ein, usw.
#6 Volle Automatisierung
Wir streben im Allgemeinen nach der vollständigen Automatisierung. Wir verwenden Puppet (Software-Konfigurations-Management-Tool), sowie unsere lokalen Umgebungen, um die Aufstellung der Server zu automatisieren. Das bedeutet, dass jeder Entwickler in ein paar Minuten in einer lokalen produktionsnahen Umgebung einsatzbereit sein kann. Diese Aufstellung beinhaltet ebenfalls einen lokalen Dispatcher, der Fehlerquellen beim Zwischenspeichern sofort erfassen kann.
Jedes Mal, wenn eine Veränderung des Codes im Versionskontrollsystem überprüft wird, wird ein Build auf Jenkins ausgeführt (durchgehendes Integrationstool), um die Entwickler sofort zu benachrichtigen, wenn etwas falsch läuft. Je nachdem, welche Programmverzweigung den neuen Code erhält, wird eine Bereitstellung auf der anwendbaren Umgebung ausgeführt, sodass die Veränderung direkt auf dieses System umgesetzt wird.
Durch Anwendung des „Git Flow“-Prinzips, sind wir sehr flexibel, was unsere Releases angeht – und das vollkommen automatisiert. Lediglich die Bereitstellung in der Produktumgebung verlangt das Betätigen einer Schaltfläche, mehr nicht.
Fazit
Der Schlüssel liegt darin, sich mit den aktuellsten Erfolgsmethoden auszukennen, die speziell für die Website-Entwicklung im WCMS gelten, in der Sie arbeiten. Noch wichtiger ist es wahrscheinlich, jemanden an Ihrer Seite zu haben, der diese Erfolgsmethoden anwenden kann und diese auch innerhalb des Projektteams für den Erfolg Ihres Projektes im digitalen Bereich durchsetzen kann. Diese Guidelines sind äußerst wertvoll, wenn eine neue Website in AEM aufgestellt wird. Sie können aber bereits anfangen, diese bei der Planung von Upgrades oder einer Erweiterung Ihrer bestehenden Adobe-Plattform anzuwenden – es sollte kein Problem darstellen, diese Lösung stabil und auf dem neuesten Stand zu halten.
Updated