AEM-Produktions-Code-Rollback-Verfahren für Cloud Manager-Bereitstellungen

Letzte Aktualisierung: 30. Juni 2026

Produktionsbereitstellungen von Adobe Experience Manager (AEM) erfordern je nach Bereitstellungstyp, Bereitstellungsalter und Hosting-Modell unterschiedliche Rollback-Methoden. Dieses Problem tritt auf, weil Cloud Manager Rollback nur für geeignete Full-Stack-Bereitstellungen unterstützt, während für Nur-Frontend-Bereitstellungen, ältere Bereitstellungen und bestimmte AMS-Szenarien alternative Wiederherstellungsmethoden erforderlich sind. Um das Problem zu beheben, identifizieren Sie die Rollback-Eignung, stellen Sie den Code wieder her und validieren Sie die Bereitstellung.

Beschreibung description

Umgebung

Adobe Experience Manager as a Cloud Service (AEMaaCS)

Problem/Symptome

Eine Produktionsbereitstellung führt zu Regressionen und erfordert ein sofortiges Rollback.
Die Option Vorherigen Code bereitgestellt ist nicht verfügbar, da die vorherige erfolgreiche Bereitstellung älter als 30 Tage ist.
Eine reine Frontend-Bereitstellung führt zu fehlerhaften CSS- oder JavaScript-Änderungen und kann nicht über die Cloud Manager-Wiederherstellungsfunktion zurückgesetzt werden.
Probleme mit der Git-Synchronisierung oder Verzweigung verhindern die erneute Bereitstellung eines vorherigen Commits.
Eine Wiederherstellung der AMS-Umgebung führt zu längeren Ausfallzeiten während der Wiederherstellung.

Grundursache

Das Problem tritt auf, weil AEM Plattformcode, benutzerspezifischen Kundencode und veränderliche Inhalte trennt. Nur Full-Stack-Bereitstellungen generieren Artefakte, die Cloud Manager wiederherstellen kann. Frontend-basierte Bereitstellungen erstellen keine wiederherstellbaren AEM-Images, und Bereitstellungen, die älter als 30 Tage sind, werden für Wiederherstellungsvorgänge nicht beibehalten. AMS-Umgebungen ohne Blau/Grün-Bereitstellungsfunktionen sind auf eine erneute Bereitstellung oder Wiederherstellung der Umgebung angewiesen, was zu Ausfallzeiten führen kann.

Lösung resolution

Führen Sie die folgenden Schritte aus, um die richtige Rollback-Strategie zu bestimmen und die Produktionsstabilität wiederherzustellen:

Identifizieren Sie das Rollback-Szenario, indem Sie bestimmen, ob es sich bei der Bereitstellung um eine Full-Stack-Bereitstellung, eine Nur-Frontend-Bereitstellung, eine AMS-Bereitstellung oder eine ältere Bereitstellung außerhalb des unterstützten Wiederherstellungsfensters handelt.
Stellen Sie eine zulässige AEM as a Cloud Service-Full-Stack-Bereitstellung wieder her, indem Sie zu Cloud Manager navigieren > Umgebungen > Produktionsumgebung > Wiederherstellen > Vorheriger Code bereitgestellt wenn die vorherige erfolgreiche Bereitstellung innerhalb der unterstützten Aufbewahrungsfrist erfolgt.
Führen Sie ein Git-basiertes Rollback durch, indem Sie zu einem zweifelsfrei funktionierenden Commit zurückkehren und den zurückgesetzten Code über die Produktions-Pipeline bereitstellen, wenn die Option Wiederherstellen nicht verfügbar ist.
Setzen Sie eine Nur-Frontend-Bereitstellung zurück, indem Sie den Frontend-Code in Git zurücksetzen und die Frontend-Implementierungs-Pipeline erneut ausführen, da Cloud Manager Restore keine Nur-Frontend-Bereitstellungen unterstützt.
Stellen Sie eine AEM Managed Services-Bereitstellung wieder her, indem Sie die vorherige Code-Version erneut bereitstellen oder bei Bedarf eine Wiederherstellung der Umgebung anfordern.
Überprüfen Sie den Abschluss der Bereitstellung, indem Sie bestätigen, dass die Pipeline erfolgreich abgeschlossen wurde und die erwartete Commit-Version als aktiv angezeigt wird.
Validieren Sie die Auflösung, indem Sie Produktions-Smoke-Tests durchführen, die Anwendungsstabilität bestätigen und überprüfen, ob sich der wiederhergestellte Code wie erwartet verhält.

Wann eskalieren

Die Option „Wiederherstellen“ ist weiterhin nicht verfügbar, obwohl die Bereitstellung die Anforderungen für die Wiederherstellungsberechtigung erfüllt.
Die Bereitstellung schlägt nach der Wiederherstellung zum vorherigen Commit wiederholt fehl.
Das Rollback stellt eine falsche Code-Version wieder her oder führt zu zusätzlicher Instabilität.
Probleme mit der Repository-Synchronisierung verhindern ein Rollback oder eine erneute Bereitstellung von Git.