Upgrades von Code und Anpassungen upgrading-code-and-customizations

Bei der Planung eines Upgrades müssen die folgenden Bereiche einer Implementierung untersucht und berücksichtigt werden.

Übersicht overview

Bevor Sie mit dem Upgrade beginnen, benötigen Sie eine stabile Anwendungs-Code-Basis, die sorgfältig gegen die Zielversion von AEM getestet wurde. Basierend auf den im Rahmen der Tests gemachten Beobachtungen kann der benutzerdefinierte Code möglicherweise optimiert werden. Dies kann die Umstrukturierung des Codes betreffen, um das Durchlaufen des Repositorys zu vermeiden, die benutzerdefinierte Indizierung zur Optimierung der Suche oder die Verwendung ungeordneter Knoten in JCR, um nur einige Beispiele zu nennen.

Neben der optionalen Aktualisierung Ihrer Code-Basis und Anpassungen für die neue AEM-Version hilft 6.5 mit der Abwärtskompatibilitätsfunktion auch bei der effizienteren Verwaltung Ihrer Anpassungen, wie unter Abwärtskompatibilität in AEM 6.5 beschrieben.

Wie oben erwähnt und im Diagramm unten dargestellt, kann die Ausführung der Mustererkennung im ersten Schritt helfen, die Gesamtkomplexität des Upgrades zu beurteilen. Sie kann Ihnen auch bei der Entscheidung helfen, ob Sie im Kompatibilitätsmodus arbeiten oder Ihre Anpassungen aktualisieren möchten, um alle neuen Funktionen von AEM 6.5 zu nutzen. Weitere Informationen finden Sie auf der Seite Abwärtskompatibilität in AEM 6.5.

Upgrade der Code-Basis upgrade-code-base

Erstellen einer dedizierten Verzweigung für 6.5-Code in der Versionskontrolle create-a-dedicated-branch-for-6.5-code-in-version-control

Sämtlicher Code und alle Konfigurationen, die für Ihre AEM Implementierung erforderlich sind, sollten mit einer Versionskontrolle verwaltet werden. Es sollte eine dedizierte Verzweigung in der Versionskontrolle erstellt werden, um alle Änderungen zu verwalten, die für die Code-Basis in der Zielversion von AEM erforderlich sind. Iterative Tests der Code-Basis mit der Zielversion von AEM und nachfolgenden Fehlerbehebungen werden in dieser Verzweigung verwaltet.

Aktualisieren der UberJar-Version von AEM update-the-aem-uber-jar-version

AEM-UberJar beinhaltet alle AEM-APIs als einzelne Abhängigkeiten in der Datei pom.xml des Maven-Projekts. Es empfiehlt sich immer, das Uber Jar als einzelne Abhängigkeit einzubeziehen, anstatt einzelne AEM API-Abhängigkeiten einzubeziehen. Beim Upgrade der Code-Basis ändern Sie die Version des Uber Jar so, dass sie auf die Zielversion von AEM verweist. Wenn Ihr Projekt mit einer Version von AEM entwickelt wurde, die schon vor dem Uber Jar existierte, entfernen Sie alle einzelnen AEM-API-Abhängigkeiten. Ersetzen Sie sie durch eine einzelne Einbindung des Uber Jar für die Zielversion von AEM. Kompilieren Sie die Code-Basis erneut mit der neuen Version des Uber Jar. Aktualisieren Sie alle veralteten APIs oder Methoden, damit sie mit der Zielversion von AEM kompatibel sind.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.5.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Auslaufen der Verwendung des administrativen Ressourcen-Resolvers phase-out-use-of-administrative-resource-resolver

Die Verwendung einer administrativen Sitzung über SlingRepository.loginAdministrative() und ResourceResolverFactory.getAdministrativeResourceResolver() war in Code-Basen vor AEM 6.0 weit verbreitet. Diese Methoden sind aus Sicherheitsgründen veraltet, da sie einen zu umfassenden Zugriff ermöglichen. In zukünftigen Versionen von Sling werden diese Methoden entfernt. Es wird dringend empfohlen, jeden Code neu zu strukturieren, um stattdessen Service-Benutzende zu verwenden. Informationen zu Dienstbenutzenden und zum Auslaufen von Verwaltungssitzungen finden Sie unter Dienstbenutzende in Adobe Experience Manager (AEM).

Abfragen und Oak-Indizes queries-and-oak-indexes

Abfragen in der Code-Basis müssen im Rahmen deren Upgrades sorgfältig getestet werden. Für Kundinnen und Kunden, die ein Upgrade von Jackrabbit 2 (AEM-Versionen älter als 6.0) durchführen, ist dieser Test besonders wichtig, da Oak Inhalte nicht automatisch indiziert und benutzerdefinierte Indizes erstellt werden müssen. Falls Sie von einer AEM 6.x-Version aus ein Upgrade durchführen, haben sich die vorkonfigurierten Oak-Indexdefinitionen möglicherweise geändert, was sich auf vorhandene Abfragen auswirken kann.

Die folgenden Tools stehen zur Analyse und Überprüfung der Abfrageleistung zur Verfügung:

Klassisches Benutzeroberflächen-Authoring classic-ui-authoring

Das klassische Benutzeroberflächen-Authoring ist in AEM 6.5 weiterhin verfügbar, ist jedoch veraltet. Weitere Informationen finden Sie unter Veraltete und entfernte Funktionen. Falls Ihre Anwendung in einer Umgebung mit klassischem Benutzeroberflächen-Authoring ausgeführt wird, wird empfohlen, auf AEM 6.5 zu aktualisieren und die klassische Benutzeroberfläche weiterhin zu verwenden. Die Migration zur Touch-optimierten Benutzeroberfläche kann dann als separates Projekt geplant werden, das über mehrere Entwicklungszyklen hinweg durchgeführt wird. Um die klassische Benutzeroberfläche in AEM 6.5 zu verwenden, müssen mehrere OSGi-Konfigurationen in die Code-Basis aufgenommen werden. Weitere Informationen zur Konfiguration finden Sie unter Aktivieren des Zugriffs auf die klassische Benutzeroberfläche.

Anpassung an die 6.5-Repository-Struktur align-repository-structure

Um Upgrades zu vereinfachen und um sicherzustellen, dass Konfigurationen nicht bei einem Upgrade überschrieben werden, wurde das Repository in 6.4 neu strukturiert, damit Inhalte und Konfiguration voneinander getrennt sind.

Daher müssen mehrere Einstellungen verschoben werden, damit sie nicht mehr wie bisher unter /etc zu finden sind. Eine vollständige Aufstellung aller fraglichen Punkte zur Repository-Neustrukturierung, die bei der Aktualisierung auf AEM 6.4 überprüft und berücksichtigt werden müssen, finden Sie unter Repository-Neustrukturierung in AEM 6.4.

AEM-Anpassungen aem-customizations

Alle Anpassungen an die AEM-Authoring-Umgebung in der Quellversion von AEM müssen identifiziert werden. Nach der Identifizierung wird empfohlen, jede Anpassung in der Versionskontrolle zu speichern oder mindestens als Teil eines Inhaltspakets zu sichern. Vor einem Produktions-Upgrade müssen alle Anpassungen in einer QA- oder Staging-Umgebung bereitgestellt und validiert werden, die auf der Zielversion von AEM ausgeführt wird.

Allgemeines zu Überlagerungen overlays-in-general

Es ist eine gängige Praxis, eine von AEM vorkonfigurierte Funktionalität zu erweitern, indem Knoten und/oder Dateien unter „/libs“ mit zusätzlichen Knoten unter „/apps“ überlagert werden. Diese Überlagerungen sollten in der Versionskontrolle nachverfolgt und mit der Zielversion von AEM getestet werden. Wenn eine Datei (z. B. JS, JSP, HTL) überlagert wird, empfiehlt Adobe, dass Sie einen Kommentar dazu hinterlassen, welche Funktionen erweitert wurden, um Regressionstests in der Zielversion von AEM zu erleichtern. Allgemeine Informationen finden Sie unter Überlagerungen. Anweisungen zu bestimmten AEM-Überlagerungen finden Sie im Anschluss.

Upgrades von benutzerdefinierten Suchformularen upgrading-custom-search-forms

Benutzerdefinierte Suchfacetten erfordern nach dem Upgrade einige manuelle Anpassungen, um ordnungsgemäß zu funktionieren. Weitere Einzelheiten finden Sie unter Upgrades von benutzerdefinierten Suchformularen.

Anpassungen der Assets-Benutzeroberfläche assets-ui-customizations

Instanzen mit angepassten Asset-Bereitstellungen müssen für das Upgrade vorbereitet werden. Diese Aktion ist erforderlich, um sicherzustellen, dass alle angepassten Inhalte mit der neuen Knotenstruktur in 6.4 kompatibel sind.

Sie können die Assets-UI-Anpassungen wie folgt vorbereiten:

Generieren von Asset-IDs für vorhandene Assets generating-asset-ids-for-existing-assets

Um Asset-IDs für vorhandene Assets zu generieren, führen Sie für diese ein Upgrade durch, wenn Sie die AEM-Instanz auf AEM 6.5 aktualisieren. Dieser Schritt ist erforderlich, um die Funktion Assets Insights zu aktivieren. Weitere Einzelheiten finden Sie unter Hinzufügen von Einbettungs-Code.

Um Assets upzugraden, konfigurieren Sie das Paket „Associate Asset IDs“ in der JMX-Konsole. Je nach Anzahl der Assets im Repository kann das Ausführen von migrateAllAssets lange dauern. Interne Tests von Adobe gehen von etwa einer Stunde für 125.000 Assets auf TarMK aus.

Falls Sie Asset-IDs für eine Untermenge Ihrer gesamten Assets benötigen, verwenden Sie die API migrateAssetsAtPath.

Verwenden Sie für alle anderen Zwecke die API migrateAllAssets().

InDesign-Skript-Anpassungen indesign-script-customizations

Adobe empfiehlt, benutzerdefinierte Skripte unter /apps/settings/dam/indesign/scripts abzulegen. Weitere Informationen zu InDesign-Skript-Anpassungen finden Sie unter Integration von Adobe Experience Manager Assets mit Adobe InDesign Server.

Wiederherstellen von ContextHub-Konfigurationen recovering-contexthub-configurations

Upgrades wirken sich auf ContextHub-Konfigurationen aus. Anweisungen zum Wiederherstellen vorhandener ContextHub-Konfigurationen finden Sie unter Konfigurieren von ContextHub.

Workflow-Anpassungen workflow-customizations

Es ist gängige Praxis, vordefinierte Workflows zu bearbeiten, um nicht benötigte Funktionen hinzuzufügen oder zu entfernen. Der Workflow DAM-Update-Asset ist ein typischer Workflow, der häufig angepasst wird. Erstellen Sie eine Sicherungskopie aller für eine angepasste Implementierung erforderlichen Workflows und speichern Sie diese in der Versionskontrolle, da sie möglicherweise bei einem Upgrade überschrieben werden.

Bearbeitbare Vorlagen editable-templates

Die Struktur bearbeitbarer Vorlagen wurde zwischen AEM 6.2 und 6.3 geändert. Wenn Sie ein Upgrade von 6.2 oder früher durchführen und Ihr Site-Inhalt mithilfe bearbeitbarer Vorlagen erstellt wurde, müssen Sie das Bereinigungs-Tool für responsive Knoten verwenden. Das Tool muss nach einem Upgrade ausgeführt werden, um Inhalte zu bereinigen. Führen Sie sie sowohl auf der Authoring- als auch auf der Publishing-Ebene aus.

Änderungen an der CUG-Implementierung cug-implementation-changes

Die Implementierung von geschlossenen Benutzergruppen (Closed User Groups, CUG) hat sich erheblich geändert, um Leistungs- und Skalierbarkeitsbeschränkungen in früheren Versionen von AEM zu beheben. Die vorherige Version von CUG ist in 6.3 nicht mehr enthalten. Die neue Implementierung wird nur in der Touch-optimierten Benutzeroberfläche unterstützt.

Testverfahren testing-procedure

Zum Testen von Upgrades sollte ein umfassender Testplan erstellt werden. Das Testen der aktualisierten Code-Basis und Anwendung muss zunächst in niedrigeren Umgebungen erfolgen. Alle Fehler müssen iterativ korrigiert werden, bis die Code-Basis stabil ist. Führen Sie erst dann Upgrades für Umgebungen auf höherer Ebene durch.

Testen des Upgrade-Verfahrens testing-the-upgrade-procedure

Testen Sie das hier beschriebene Upgrade-Verfahren in Entwicklungs- und QA-Umgebungen, wie im benutzerdefinierten Runbook dokumentiert (siehe Planung des Upgrades). Das Upgrade-Verfahren muss wiederholt werden, bis alle Schritte im Upgrade-Runbook dokumentiert sind und das Upgrade-Verfahren reibungslos läuft.

Implementierungstestbereiche implementation-test-areas-

Im Folgenden sind wichtige Bereiche einer AEM-Implementierung genannt, die vom Testplan abgedeckt sein müssen, sobald die Umgebung upgegradet und die aktualisierte Code-Basis bereitgestellt wurde.

Dokumenttestplan und Ergebnisse document-test-plan-and-results

Es sollte ein Testplan erstellt werden, der die oben genannten Implementierungstestbereiche abdeckt. Oft ist es sinnvoll, den Testplan nach Aufgabenlisten für Authoring- und Publishing-Aufgaben zu trennen. Dieser Testplan muss auf Entwicklungs-, QA- und Staging-Umgebungen ausgeführt werden, bevor Produktionsumgebungen aktualisiert werden. Erfassen Sie die Testergebnisse und Leistungsmetriken aus Umgebungen niedrigerer Ebenen als Referenzwerte für das Upgrade der Staging- und Produktionsumgebungen.