Push-Button Deployments für Adobe Experience Manager

Wir wissen alle, repetitive Aufgaben in der Software-Entwicklung sind nicht akzeptabel. Alles, was regelmässig gemacht werden muss, sollte automatisiert werden.

Der Grund dafür ist nicht Faulheit, sondern die Fehleranfälligkeit des manuellen Ausführens von komplexen Aufgaben, wie zum Beispiel beim Releasen von Software. Je mehr manuelle Schritte in den Release-Prozess involviert sind, desto mehr potenzielle Schwachstellen gibt es.

«Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen.»

Edward A. Murphy

Man kann natürlich versuchen das Risiko über restriktive Regeln, detaillierte Dokumentation und endlos lange Checklisten zu minimieren. Aber sind wir mal ehrlich, das ist nur Symptombekämpfung. Die Ursache des Problems bleibt bestehen.

 Automatisierte Deployment Pipeline als Grundlage für Push-Button Deployments mit Adobe Experience Manager

Das Push-Button Deployment als Teil einer automatisierten Deployment Pipeline erlaubt es dagegen, schnelles Feedback zur Qualität des Codes zu erhalten und beliebige Versionen einer Software per Knopfdruck zu deployen.

Als Reaktion (Trigger) auf eine Änderung im Code-Repository wird der Prozess gestartet und läuft automatisiert bis in die Produktion durch.

Ok, fast bis in die Produktion.

Üblicherweise wird vor dem finalen Übergang in die Produktion eine Genehmigung vom Auftraggeber der Änderung benötigt und deshalb ein manueller Schritt in die Deployment Pipeline eingebaut. Dazu später mehr.

Für Adobe Experience Manager (AEM) gibt es einige Best Practices bezüglich dem Releasen und Deployen von Code. Bis jetzt habe ich aber noch keinen Artikel entdeckt, der dies alles zusammenfasst und eine ausführliche Übersicht mit Verweisen auf weiterführende Dokumentation liefert. Dieser Artikel soll das ändern.

Anhand der folgenden Illustration werden Sie Schritt für Schritt durch die Stufen einer auf Adobe Experience Manager zugeschnittenen Deployment-Pipeline geführt, welche Push-Button Deployments ermöglicht.

1. Commit/Push

Der initiale Trigger für den Start der Deployment-Pipeline ist der Push ins Code-Repository. Dieser startet die Deployment-Pipeline.

Eine leider viel zu selten beachtete Best Practice zum Code Repository ist es, ein einziges Repository für alle AEM-Projekte auf der gleichen Installation zu haben. Das reduziert vor allem Probleme mit Refactorings über mehrere Repositories und bei der Versionierung und dem Management von Abhängigkeiten. Auch der Einstieg für neue Entwickler ist wesentlich leichter, wenn es nur ein Repository gibt.

Wenn Sie denken: «Bei uns geht das aber nicht!», empfehle ich Ihnen die Publikation Why Google Stores Billions of Lines of Code in a single Repository zu lesen.

2. Schnelle Tests (Fail Fast)

Die Qualitätssicherung startet hier. Auf dieser ersten Stufe soll schnellstmöglich eine rudimentäre Analyse zur Funktionalität und Qualität des Codes durchgeführt werden. Geschwindigkeit ist hier der Schlüssel. Der Entwickler soll innerhalb von wenigen Minuten Feedback zu seinen Änderungen erhalten.

Die einzelnen Streams 2a, 2b und 2c sollen so konfiguriert werden, dass jeder Fehler zu einem Abbruch führt. Dadurch müssen Probleme umgehend gelöst werden und können nicht mehr länger nach hinten geschoben werden, im schlimmsten Fall bis in die Produktion.

Dieses Prinzip, genannt Jidōka, ist auf das Toyota Production System zurückzuführen.

Jidōka bedeutet soviel wie «Automation mit menschlichem Touch». Sobald Anomalien festgestellt werden, stoppt die Maschine von selbst und ein Mensch kümmert sich um die Problemlösung.

2a. Statische Code-Analyse

Coding Best Practices gibt es für alle Programmiersprachen. Ebenso Tools für die Analyse. Tools zur statischen Code-Analyse helfen unter anderem dabei, doppelten Code zu erkennen, Komplexität sichtbar zu machen und Kodierrichtlinien zu erzwingen.

Um nicht bei Null starten zu müssen, empfiehlt sich hier das Tool SonarQube zusammen mit dem Plugin AEM-Rules-for-SonarQube.

Damit hat man einen guten Basissatz an Checks und Analysen für den Java-Code und die HTML Template Language (HTL).

Bei der Analyse von Content-Paketen hilft ein Maven Plugin namens OakPAL .

2b. Unit Tests

Unit Tests haben die kleinste Granularität aller Tests in der Deployment Pipeline. Sie interessieren sich nicht für das grosse Ganze, sondern stellen sicher, dass einzelne Methoden und Code-Abschnitte korrekt funktionieren. Durch die kleine Granularität können sie unabhängig von einer voll konfigurierten Umgebung ausgeführt werden und brauchen keine Anbindung an externe Systeme.

Damit sind sie perfekt geeignet, um schnelles Feedback zur Qualität der Änderungen zu geben.

Eine gute Einführung ins Unit Testing mit AEM gibt das Kapitel 6 des Tutorials Getting started with AEM Sites.

2c. Build

Der Build beinhaltet das Kompilieren des Codes, die Versionierung und das Paketisieren für ein späteres Deployment. Jeder weitere Schritt wird mit diesen Paketen durchgeführt.

Die Pakete werden in ein Software Repository übertragen und archiviert. Die weitere Verwendung für das Deployment auf die verschiedenen Umgebungen erfolgt anschliessend direkt aus dem Software Repository.

3. Deployment auf Staging

Der nächste Schritt ist das Deployment auf die Staging-Umgebung. Deployments sollten auf höheren Umgebungen niemals manuell durchgeführt werden. Stattdessen verwendet man Tools zur automatisierten Installation (z.B. Jenkins) und Konfiguration (z.B. Chef, Puppet).

4. Ausführliche Tests

Die zweite Stufe enthält komplexere und zeitaufwändigere Tests. Unter anderem wird hier getestet, ob die aktuelle Änderung einen negativen Einfluss auf früher entwickelte Features hat, die sogenannte Regression.

Der Fokus liegt hier auf der Sicherstellung der Produktionsbereitschaft der kompletten Software und nicht auf Geschwindigkeit und schnellem Feedback. Deshalb kann diese Stufe durchaus um einige Faktoren langsamer sein als die erste.

4a. Sicherheitstests

Kurz vor dem Go Live wird üblicherweise ein externes Penetrationstesting-Team beauftragt, die Web-Applikation auf Herz und Nieren zu prüfen. Zusätzlich sollten allerdings bereits während der Entwicklung automatisierte Sicherheitstests durch die Deployment Pipeline ausgeführt werden.

Für die grundlegenden Sicherheitslücken in Webanwendungen kann zum Beispiel der OWASP Zed Attack Proxy (ZAP) verwendet werden, ein kostenloses Sicherheitstool, dass nahtlos in die Deployment-Pipeline integriert werden kann.

Darüber hinaus sollte unbedingt die AEM-spezifische Security-Checkliste von Adobe beachtet werden.

4b. Last- und Performancetests

Last- und Performance-Testing ist nie eine perfekte Replikation der Realität. Aber es deshalb zu unterlassen, wäre fahrlässig. Auch hier gibt es eine Best Practice. Dazu gibt es das Adobe-Tool Though Day, welches hilft, die Systeme mit Content zu bestücken, um möglichst realitätsnahe Last- und Performance Tests durchzuführen.

4c. Regressionstests

Das eine neue Funktionalität getestet werden muss, ist jedem klar. Doch wer stellt sicher, dass sie auch in Zukunft funktioniert, nachdem weitere Änderungen gemacht und weitere Releases deployed wurden?

Anstatt manuell alle Funktionen mit jedem Release von Hand erneut durchzutesten, wird die bestehende Funktionalität durch automatisierte Browsertests, auch Regressionstests genannt, abgesichert.

Nach jedem Lauf der automatisierten Tests können wir zuversichtlich sein, dass der neue Code keine der bestehenden Funktionalitäten beeinträchtigt hat, vorausgesetzt die Testabdeckung ist hoch genug.

Ein weit verbreitetes Werkzeug für diese Art von Tests ist Selenium. Darüber hinaus kann das Authoring in AEM mit einem Tool namens Bobcat ebenfalls automatisiert getestet werden.

Durch das eliminieren der manuellen Regressionstests bleibt dem hochspezialisierten und teuren Entwickler-Team mehr Zeit, um neue Funktionalität zu implementieren.

4d. Explorative Tests

Da wir einen manuellen Schritt in unserer Deployment Pipeline haben bevor es in die Produktion geht, können wir auf Wunsch auch explorative Tests in der Staging-Umgebung durchführen. Bei komplexen neuen Funktionalitäten und Features kann es sinnvoll sein, dass ein erfahrener Tester diese von Hand auf Herz und Nieren prüft. Bei kleineren Verbesserungen und Bugfixes würden wir diesen manuellen Schritt aber überspringen.

5. Go/No-Go Entscheidung

AEM-Projekte laufen in der Regel in mittleren und grossen Unternehmen, welche für ein Release in die Produktion eine Art formelle Genehmigung durch die Business Stakeholder und/oder ein Change Advisory Board (CAB) voraussetzen. Deshalb wird hier die Deployment Pipeline pausiert. Erst nach der Aktivierung durch eine berechtigte Person, geht’s zur letzten Stufe, dem Deployment in die Produktionsumgebung.

6. Deployment auf Produktion

Nach all den Checks und Tests sollte das Deployment in die Produktion eigentlich eine Kleinigkeit sein. Allerdings gilt es auch hier noch etwas zu beachten. Denn nach einem Deployment sollten unbedingt die folgenden Caches geleert werden:

• Dispatcher Cache
• Content Delivery Network (CDN)

7. Produktion

7a. Smoke Tests

Nach erfolgreichem Go Live wird ein kurzer Smoke Test durchgeführt. Dabei wird manuell durch die wichtigsten Seiten geklickt und geschaut, ob alles noch wie gewünscht funktioniert und ob die neuen Features angekommen sind.

7b. Monitoring

Die wichtigsten Seiten Ihres Webauftrittes sollten durch ein Monitoring-Tool abgesichert werden. Dieses prüft in Minuten-Intervallen, ob die wichtigsten Seiten verfügbar sind und den korrekten Inhalt anzeigen. Falls das nicht der Fall ist, wird eine Meldung via Email oder SMS verschickt, damit jemand manuell das Problem beurteilen und lösen kann.

Fazit

Wie Sie sehen, gibt es jede Menge zu beachten und einiges an Aufwand, wenn man eine Deployment Pipeline aufbauen möchte. Das zahlt sich über lange Sicht aber aus. Denn durch eine gute Deployment Pipeline werden aus den stressigen Produktions-Releases aus der Vergangenheit plötzlich ganz normale Arbeitstage.

Falls Ihnen das Ganze zu aufwändig ist oder Sie einfach nicht die nötigen Ressourcen oder Skills haben, um eine Deployment Pipeline selbst aufzubauen, gibt es nun von Adobe einen Service namens Cloud Manager. Dieser deckt die meisten Schritte aus dem Artikel bereits ab.

Der einzige Nachteil: man kann die Deployment Pipeline nicht mehr von A-Z selbst kontrollieren.