Erfahren Sie, wie Adobe Experience Manager (AEM) as a Cloud Service fortlaufende Integration und Bereitstellung (CI/CD) verwendet, um Ihre Projekte auf dem neuesten Stand zu halten.
AEM as a Cloud Service verwendet die kontinuierliche Integration und Bereitstellung (Continuous Integration und Continuous Delivery, CI/CD), um sicherzustellen, dass Ihre Projekte auf der aktuellen AEM-Version basieren. Dieser Prozess aktualisiert Ihre Produktions-, Staging- und Entwicklungsinstanzen nahtlos, ohne dass Ihre Benutzer beeinträchtigt werden.
Bevor Ihre Instanzen automatisch aktualisiert werden, wird 3-5 Tage im Voraus ein neues AEM Maintenance Release veröffentlicht. Während dieses Zeitraums können Sie optional Manuelle Aktualisierungen von Trigger für Ihre Entwicklungsinstanzen. Nach diesem Zeitpunkt werden zuerst automatisch Versionsupdates auf Ihre Entwicklungsumgebungen angewendet. Wenn die Aktualisierung erfolgreich ist, wird der Aktualisierungsprozess zu Ihren Staging- und Produktionsinstanzen fortgesetzt. Die Entwicklungs- und Staging-Instanzen fungieren als automatisiertes Qualitäts-Gate, bei dem Ihre benutzerdefinierten Tests ausgeführt werden, bevor die Aktualisierung auf Ihre Produktionsumgebung angewendet wird.
Hinweis: Die automatischen Aktualisierungen für Entwicklungsumgebungen werden 2023 schrittweise für alle Kunden aktiviert. Wenn Ihre Entwicklungsumgebungen nicht automatisch aktualisiert werden, können Sie manuelle Aktualisierungen verwenden, um sie mit Ihren Staging- und Produktionsumgebungen synchron zu halten.
Es gibt zwei Arten von AEM-Versionsaktualisierungen:
Neue Funktionsaktualisierungen
Wichtige Daten für monatliche Versionen auf der Seite Roadmap für Experience Manager veröffentlicht und markieren Sie Ihre Kalender, um sich auf die wichtigsten Aktivitäten vorzubereiten und sich auf die Veröffentlichung vorzubereiten.
AEM-Aktualisierungen durchlaufen eine intensive und vollautomatisierte Produktvalidierungs-Pipeline, die mehrere Schritte umfasst, um sicherzustellen, dass keine Unterbrechung des Services für in Produktion befindliche Systeme auftritt. Konsistenzprüfungen erlauben eine Überwachung des Zustands der Anwendung. Wenn diese Prüfungen bei einer AEM as a Cloud Service Aktualisierung fehlschlagen, wird die Veröffentlichung nicht fortgesetzt und Adobe untersucht, warum die Aktualisierung dieses unerwartete Verhalten verursacht hat.
Wenn Sie eine neue Version von benutzerdefiniertem Code in Ihrer Umgebung bereitstellen, Produkt- und benutzerdefinierte Funktionstests eine entscheidende Rolle spielen. Sie gewährleisten, dass die Produktionssysteme auch nach einer Änderung stabil und funktionsfähig bleiben. Diese Tests werden auch im Aktualisierungsprozess AEM Version angewendet.
Wenn die Aktualisierung der Produktionsumgebung fehlschlägt, setzt Cloud Manager die Staging-Umgebung automatisch zurück. Dies geschieht automatisch, um sicherzustellen, dass nach Abschluss der Aktualisierung die Staging- und Produktionsumgebungen dieselbe AEM Version aufweisen.
Wenn eine automatische Aktualisierung einer Entwicklungsumgebung fehlschlägt, werden Staging- und Produktionsumgebungen ebenfalls nicht aktualisiert.
Wenn benutzerdefinierter Code in die Staging- und nicht in die Produktion verschoben wurde, werden diese Änderungen beim nächsten AEM-Update entfernt, um das Git-Tag der letzten erfolgreichen Kundenversion in der Produktion widerzuspiegeln. Daher muss der benutzerspezifische Code, der nur für das Staging verfügbar war, erneut bereitgestellt werden.
Nutzung der Staging-Umgebung
Produktions-Pipeline
Produktionsfremde Pipeline
Inhaltskopie
Automatisierte Funktionstests
Wenn ein Regressionsfehler auftritt, senden Sie über die Admin Console einen Support-Fall. Wenn es sich bei dem Problem um einen Blocker handelt und sich auf die Produktion auswirkt, sollte ein P1-Fehler gemeldet werden. Geben Sie alle Details an, die zum Reproduzieren des Regressionsproblems erforderlich sind.
Aktualisierungen verursachen normalerweise keine Ausfallzeiten, auch nicht für die Autoreninstanz, bei der es sich um einen Cluster von Knoten handelt. Rollierende Aktualisierungen sind aufgrund der Composite Node Store-Funktion in Oak möglich.
Mithilfe dieser Funktion kann AEM auf mehrere Repositorys gleichzeitig verweisen. In rollierende Implementierung, enthält die neue AEM eine eigene /libs
(das auf TarMK basierende, unveränderliche Repository). Sie unterscheidet sich von der älteren AEM, obwohl beide auf ein gemeinsames, auf DocumentMK basierendes veränderliches Repository verweisen, das Bereiche wie /content
, /conf
, /etc
und andere.
Da sowohl die alte als auch die neue Version über eigene Versionen von verfügen, /libs
, können sie beide während der rollierenden Aktualisierung aktiv sein. Und beide können Traffic aufnehmen, bis das alte vollständig durch das neue ersetzt wird.