AEM DevOps Performance-Abnahme in der Cloud-Manager-Pipeline und nach dem Release, gegen Felddaten statt Punktwerte
Der Cloud Manager prüft Deployments über die Full-Stack-Pipeline von AEM as a Cloud Service mit Code-Scan, Tests und einem Lighthouse-Lauf. Eine Abnahme der Ladezeit ist das nicht: Die Prüfungen laufen im Labor, auf wenigen Seiten der Stage-Umgebung, und der Lighthouse-Wert hält die Pipeline nicht an. Diese Seite beschreibt, was die Qualitäts-Gates des Cloud Manager leisten, wo sie enden und wie Budgets je Seitentyp, Release-Marker im Real User Monitoring und vorab festgelegte Rollback-Kriterien die Lücke schließen.
Cloud-Manager-Pipeline: Code-Scan, Funktionstests und Experience Audit vor der Produktion
Eine Produktions-Pipeline in AEM as a Cloud Service läuft in drei Phasen: Deployment auf Stage, Tests auf Stage, Deployment auf Produktion. Laut Adobe unterstützt nur die Full-Stack-Pipeline Code-Scan, Funktionstests, UI-Tests und Experience Audit (Deploy Your Code). Vor dem Deployment auf Produktion steht eine Freigabe durch einen Nutzer mit der Rolle Business Owner, Project Manager oder Deployment Manager, und auf Produktion geht dasselbe Build-Artefakt, das auf Stage geprüft wurde.
| Gate | Was geprüft wird | Wirkung |
|---|---|---|
| Code Quality | Regeln auf Basis von SonarQube, etwa Security Rating und Testabdeckung | kritische Befunde brechen ab, wichtige pausieren die Pipeline |
| Experience Audit | Median der Lighthouse-Werte für bis zu 25 konfigurierte Pfade, ohne Konfiguration nur die Startseite | informativ, hält die Pipeline nicht an |
| Performance Testing | Lasttest über 30 Minuten auf Stage gegen Kennzahlen zu Antwortzeit und Seitenaufrufen je Minute | Teil des Cloud Manager für Managed Services, kritische Befunde brechen ab |
Die Schwellen der Code-Qualität und des Lasttests beschreibt Adobe unter Code Quality Testing: Ein Security Rating unter B ist kritisch, eine Testabdeckung unter 50 Prozent wichtig. Im Lasttest gilt eine Fehlerquote ab 2 Prozent als kritisch, ein 95. Perzentil der Antwortzeit über der im Programm hinterlegten Kennzahl als wichtig. Die Angaben zur Experience Audit stehen im Experience Audit Dashboard.
Grenzen der Qualitäts-Gates: Lighthouse-Punktwert, 25 Seiten und Labor statt Feld
- Punktwert statt Kennzahl: Die Experience Audit meldet Lighthouse-Punktwerte und ihre Veränderung zum letzten Lauf. Eine Verschlechterung wird sichtbar, stoppt aber kein Deployment.
- Streuung: Lighthouse-Werte schwanken auch ohne Änderung am Code. Laut der Lighthouse-Dokumentation zur Variabilität ist der Median aus fünf Läufen etwa doppelt so stabil wie ein einzelner Lauf.
- Wenige Seiten: Bis zu 25 Pfade decken auf großen Plattformen nicht jeden Seitentyp in jedem Markt ab.
- Stage statt Produktion: Geprüft wird die Stage-Umgebung, ohne Einwilligung und ohne Interaktion. Tags, die nach der Zustimmung laden, und die Reaktionszeit bei echten Eingaben fehlen. Interaction to Next Paint lässt sich so nicht prüfen.
- Lasttest misst den Server: Antwortzeit und Fehlerquote unter Last sagen nichts darüber, was danach im Browser passiert.
Eine Plattform kann deshalb jede Prüfung im Cloud Manager bestehen und trotzdem schlechte Nutzerdaten haben. Was Adobes Werkzeug im Betrieb ergänzt, steht unter AEM Sites Optimizer, die Schichten der Plattform unter Adobe Experience Manager Performance.
Performance-Budgets je Seitentyp als zusätzliches Gate in der Pipeline
Ein Budget legt je Seitentyp fest, wie viel JavaScript, CSS und Bilddaten eine Seite laden darf und welche Laborwerte für Largest Contentful Paint und Total Blocking Time als Grenze gelten. Anders als ein Punktwert lässt es sich einem Team und einer Komponente zuordnen. Wie Budgets aufgebaut werden, beschreibt Performance-Budget.
In AEM as a Cloud Service gibt es zwei Wege, ein Budget prüfbar zu machen. Die eigenen UI-Tests des Cloud Manager laufen in einem Docker-Image und lassen neben Java auch Node und WebdriverIO zu; dort lässt sich ein Messlauf gegen Stage einbauen, der bei Überschreitung fehlschlägt. Alternativ prüft ein eigener Schritt in der Versionsverwaltung vor dem Merge. Die Rohdaten der Experience Audit lassen sich je Seite als JSON abrufen und eignen sich für eine eigene Zeitreihe über alle Releases.
Derselbe Prüfschritt kann technische SEO-Merkmale je Seitentyp abfragen: Statuscode, Canonical und den Header X-Robots-Tag. Welche das in AEM sind, beschreibt AEM SEO.
Abnahme nach dem Release: Felddaten je Seitentyp mit Release-Marker im RUM
Die eigentliche Abnahme findet nach dem Deployment statt, bei echten Besuchern. Dafür braucht das Real User Monitoring die Versionsnummer der Auslieferung als Merkmal jeder Messung. Erst damit lässt sich das 75. Perzentil je Seitentyp vor und nach einem Release vergleichen und eine Verschlechterung einem Deployment zuordnen.
Der Chrome User Experience Report, nach dem Google bewertet, mittelt über 28 Tage und zeigt die Wirkung eines Releases erst nach etwa vier Wochen vollständig. Für die Entscheidung am Tag nach dem Release taugt er nicht, für die abschließende Abnahme ist er der Maßstab. Die Operational Telemetry von AEM erfasst standardmäßig einen Seitenaufruf je hundert; auf Seitentypen mit wenig Verkehr reicht das für eine Aussage am nächsten Tag oft nicht.
Release-Marker gehören auch an Änderungen, die nicht durch den Cloud Manager laufen: neue Regeln in Adobe Experience Platform Tags, Aktivitäten in Adobe Target, ein geänderter Einwilligungsdialog. Viele Verschlechterungen bei Interaction to Next Paint stammen aus diesen Quellen und nicht aus dem Code-Deployment.
Rollback-Kriterien: Schwellen je Seitentyp vor dem Release festlegen
Ob ein Release zurückgenommen wird, sollte vor dem Deployment feststehen und nicht in einer Diskussion danach entschieden werden. Dafür reichen drei Angaben je Seitentyp:
- Schwelle: um wie viel das 75. Perzentil einer Kennzahl gegenüber dem Stand vor dem Release steigen darf, abgeleitet aus dem Budget und den Grenzwerten von Google.
- Mindestdaten: wie viele Messungen und welcher Zeitraum nötig sind, bevor die Schwelle gilt, damit Rauschen keinen Rollback auslöst.
- Maßnahme: Rücknahme über einen erneuten Pipeline-Lauf mit dem vorherigen Stand, Deaktivierung einer Tag-Regel oder Korrektur im nächsten Release, mit benannter Verantwortung.
Wie solche Kriterien als prüfbare Tickets formuliert werden, zeigen die Core Web Vitals Abnahmekriterien.
AEM On-Premises und Managed Services: Jenkins oder GitLab mit Lighthouse CI
Für AEM 6.5 im eigenen Betrieb fehlt der Cloud Manager; die Pipeline läuft in Jenkins, GitLab CI oder einem ähnlichen Werkzeug. Dort lässt sich Lighthouse CI als eigener Schritt einbinden: mehrere Läufe je Adresse über numberOfRuns, Grenzwerte als Assertions je Audit und die Aggregation über den Median statt über den besten Lauf. Die Liste der Adressen folgt den Seitentypen aus dem Budget, nicht der Startseite allein. Für die Abnahme nach dem Release gilt dasselbe wie in der Cloud: Release-Marker im RUM und Felddaten je Seitentyp. Zu Terminen und Wegen nach AEM 6.5 siehe AEM 6.5 Support-Ende.
Abnahmekriterien für die AEM-Pipeline: messbar je Release
- Für jeden Seitentyp ist ein Budget festgelegt und als Prüfschritt in der Pipeline eingebaut, der bei Überschreitung fehlschlägt.
- Die Pfade der Experience Audit decken die wichtigsten Seitentypen ab und nicht allein die Startseite.
- Jede Messung im Real User Monitoring trägt die Versionsnummer der Auslieferung, auch für Änderungen in Tags und Target.
- Rollback-Kriterien je Seitentyp sind vor dem Release dokumentiert.
- Vier Wochen nach dem Release wird gegen den Chrome User Experience Report abgenommen.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen die Google-Nutzerdaten Ihrer Plattform und welche Prüfungen Ihrer Pipeline fehlen.
Häufige Fragen zu AEM DevOps und Performance
Stoppt die Experience Audit im Cloud Manager ein Deployment bei schlechten Werten?
Nein. Adobe stellt die Experience Audit als Qualitäts-Gate bereit, das Deployments nicht blockiert. Sie zeigt den Median der Lighthouse-Werte für die konfigurierten Seiten und die Veränderung zum letzten Lauf. Wer eine Grenze erzwingen will, baut einen eigenen Prüfschritt, etwa in den UI-Tests oder vor dem Merge.
Wie viele Seiten prüft die Experience Audit?
Ohne Konfiguration die Startseite der Publish-Instanz, mit Konfiguration bis zu 25 eigene Pfade. Sinnvoll ist je wichtigem Seitentyp und Markt mindestens eine Adresse, ausgewählt nach Verkehr und Umsatz.
Reicht ein Lighthouse-Wert aus der Pipeline als Abnahme?
Nein. Lighthouse misst im Labor, ohne Einwilligung und ohne echte Eingaben, und der Wert streut zwischen Läufen. Google bewertet nach Felddaten über 28 Tage. Die Abnahme läuft deshalb nach dem Release gegen Real User Monitoring und Chrome User Experience Report, je Seitentyp.
Wer legt die Rollback-Kriterien fest?
Die Plattformverantwortung gemeinsam mit dem Team, das die Umsetzung verantwortet, vor dem Release. Geliefert werden können Schwellen je Seitentyp, Mindestdaten und die Prüfung nach dem Release; die Entscheidung über die Rücknahme und ihre Umsetzung liegt beim Kundenteam.