Grosse Sitecore Solutions in wartbare Module herunterbrechen

In diesem Artikel möchten wir (Matthias Gmür und Mark Lowe) ein Thema beleuchten, welches uns in den letzten Jahren bei einigen unserer Kunden beschäftigt hat: Die Architektur von grossen Sitecore Solutions.

Typischerweise arbeiten an solchen Solutions mehrere Entwicklerteams – teils im Auftrag von unterschiedlichen Firmen und teils sogar in verschiedenen Zeitzonen. In der Regel konzentriert sich ein Team auf ein Feature oder Featureset z.B. eine spezifische Website innerhalb von vielen Sites, die zur betroffenen Solution gehören.

Traditionell Monolithisch

Traditionellerweise werden Sitecore Projekte in einer einzelnen Visual Studio Solution entwickelt d.h. Assemblies, Config-Dateien, Views, Assets und weitere Dateien sind alle in einem einzelnen Projekt vom Typ ASP.NET Web Application enthalten. Code wird meistens in weitere Class Library Projekte ausgelagert, die durch das Web Application Projekt referenziert werden.

solution-example

Mit einem solchen Aufbau können viele Projekte gut gestemmt werden. In einem Szenario wie anfangs erwähnt wird es hingegen schwieriger. Der Koordinationsaufwand ist hoch, das Durchsetzen von gemeinsamen Coding Guidelines ist aufwändig und Code Reuse in anderen Solutions ist nicht ohne weiteres möglich. Auch wird die gesamte Codebasis über die Zeit tendenziell grösser und damit aufwändiger zu warten. Von Mergekonflikten und zu grossen VCS Repositories ganz zu schweigen.

Grundlagen für Modularisierung sind gegeben

Mit Sitecore ist man nicht auf den oben beschriebenen Solution Aufbau limitiert. Von Haus aus werden verschiedene Mittel geliefert, um die Codebasis in kleinere, übersichtlichere Stücke zu schneiden und in der Community existieren starke Tools, die diesen Aufbau weiter unterstützen. Beispiele davon sind

– Erweiterbare Konfigurationen (Config Includes)
– Serialisierung von Items, Benutzern und Rollen aufs Dateisystem
– „Einklinken“ in Sitecore Funktionalität via Pipelines

Ende 2015 hat Sitecore mit Sitecore Habitat selbst einen eindrücklichen Solution Entwurf veröffentlicht, der unter anderem den Einsatz einer modularisierten Architektur aufzeigt.

Wie funktioniert Modularisierung?

Die Grundidee hinter Modularisierung ist die Aufteilung von Code, Config, Serialisierten Items und Assets – kurz gesagt allen Bestandteilen eines Features oder Featuresets in einzelne ASP.NET Web Applikationen. Diese werden dann beim Deployment zusammengeführt und in eine vorkonfigurierte Sitecore-Instanz installiert.

Als Ablageort von kompilierten Modulen bieten sich Repositories wie NuGet oder Artifactory an.

Build und Publish eines Moduls:

Build und Publish eines Moduls

Resolve von Modulen und Deploy auf eine Sitecore Instanz:

Resolve von Modulen und Deploy auf eine Sitecore Instanz

Diese vereinfachten Schaubilder zeigen das Grundprinzip auf. Es wird ersichtlich, dass im Gegensatz zu einer Single-Module-Architektur ein Mechanismus benötigt wird, der Module einzeln kompiliert und die entstandenen Artefakte bei einem Deployment zusammenführt.

Dies kann mit Msbuilds Tasks, Powershell oder anderen Scriptsprachen realisiert werden. Bei Sitecore Habitat wird dazu Gulp verwendet.

Mögliche Modul Aufteilungen

Es gibt viele Möglichkeiten, wie Code in Module unterteilt werden kann. Die Unterteilung hängt sehr stark von den Anforderungen an die Solution ab.

Beispiel 1: Modularisierung auf Site-Ebene

Einfache Modularisierung auf Site-Ebene mit gemeinsamen Basiskomponenten, die auf allen Sites verwendet werden können.

simple-modularization

Vorteile:

  • Mehrere Entwicklerteams können die einzelnen Sites unabhängig voneinander entwickeln.
  • Die Websites können auf beliebige Sitecore Instanzen ausgespielt werden und müssen nicht zwingend gemeinsam auf der gleichen Instanz ausgeführt werden. Dies vereinfacht die Skalierung. Wenn z.B. Website B viel Leistung benötigt, kann dieses Modul zusammen mit Shared Components auch auf eine dedizierte Sitecore Instanz verschoben werden.

Obige Szenarien wären mit Single-Module-Architekturen nur mit erheblichem Aufwand realisierbar.

Beispiel 2: Granluare Modularisierung von Sitecore Habitat

Das folgende Beispiel zeigt die Sitecore Habitat Layers mit einem Auszug der darin enthaltenen Module.

habitat-modularization

Bei Sitecore Habitat werden die Module sehr granular definiert (Navigation, News,…). Sie sind in Layers unterteilt, die zusätzlich auch die Änderungshäufigkeit definieren. Module im Project Layer ändern sich häufig, im Feature Layer weniger häufig und im Foundation Layer sollen selten Änderungen nötig sein. Abhängigkeiten sind nur von oben nach unten erlaubt d.h. ein Modul im Foundation Layer darf kein Modul vom Feature Layer referenzieren etc. Vorteil einer so fein-granularen Architektur ist die erhöhte Wiederverwendbarkeit.

Von einer einfachen Unterteilung in Basiskomponenten und Websites bis hin zu einer granularen Unterteilung bis auf Komponentenebene ist alles möglich. Zu beachten ist einfach: Jedes Modul bringt Overhead mit sich. Dies bei Erstellung, Kompilierung, Deployment und Verwaltung. Je mehr Module gebaut und publiziert werden müssen, desto länger dauert dieser Prozess. Dies spielt vor Allem im Entwicklungsalltag eine Rolle.

Mix-And-Match

Mit dem Einsatz eines Repositories wird es möglich, die einzelnen Module fast beliebig zusammenzustellen. Nuget zum Besipiel übernimmt auch das dependency management.
Beispiel: Nuget packages.config

nuge-package-config

 

Es wäre auch möglich, die Sitecore Basisinstallation ebenfalls als Nuget Package verfügbar zu machen. Damit liessen sich komplette Instanzen in der packages.config konfigurieren.

Voraussetzungen für Modularisierung

Eine modulare Architektur hat folgende Voraussetzungen

  • Build Tools für Publish und Deploy sind nötig
  • Alle Items und Dateien müssen zwingend in modulspezifischen Ordnern erstellt werden zur Verhinderung von Kollisionen.
  • Config Anpassungen ausschliesslich via Include-Mechanismus
  • Einzelne Anpassungen an der Sitecore Basisinstallation nötg (Multisite Datasource Locations, Lookup fields, Rich Text Profiles, Bucketing Strategies,…)

Vor- und Nachteile

Vorteile:

  • Steigerung der Wiederverwendbarkeit
  • Steigerung der Wartbarkeit
  • Multi-Team / Multi-Agency Setups möglich
  • Vereinfachung von Sitecore Upgrades
  • Durchsetzung von Qualitätsstandards wird einfacher
  • Versionierung von Modulen möglich
  • Dependency Management wird vereinfacht

Nachteile:

  • Initialer Setup-Aufwand Build Tools
  • Initiale Anpassungen an Sitecore Basisinstallation
  • Overhead bei Erstellung, Build und Deploy von Modulen
  • Lernkurve für Entwickler

Fazit

Eine Modulare Sitecore-Architektur bietet viele Vorteile. Schlüsselpunkt ist die Entscheidung, wie man die Codebasis in Module schneiden möchte. Hier gilt es, Wiederverwendbarkeit gegen Overhead abzuwägen. Vorgängig ist es nötig, ein entsprechendes Tooling aufzusetzen und einzelne Anpassungen an der Sitecore Basisinstallation müssen vorgenommen werden, die sich jedoch dank der erweiterbaren Architektur von Sitecore gut umsetzen lassen. Mit dem Einsatz eines Repositories wird die Konfiguration von Instanzen und das Dependency Management vereinfacht.

Ein vertiefter Blick in die von Sitecore erarbeiteten Unterlagen im Zusammenhang mit der Habitat Solution ist sehr zu empfehlen. Wichtig ist aber zu verstehen, dass die Habitat Solution als Inspiration dienen soll für den Aufbau einer eigenen, modularisierten Architektur und nicht als copy-and-paste-Vorlage gedacht ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>