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 fortfahren, sollten Sie über eine stabile Anwendungs-Code-Basis verfügen, die sorgfältig gegen AEM 6.5 LTS getestet wurde.

Upgrade der Code-Basis upgrade-code-base

Erstellen einer dedizierten Verzweigung für 6.5 LTS-Code in der Versionskontrolle create-a-dedicated-branch-for-6.5-lts-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. Ändern Sie beim Upgrade der Code-Basis die Version von Uber Jar so, dass sie auf die Version 6.5 LTS von AEM verweist. Aktualisieren Sie alle veralteten APIs oder Methoden, damit sie mit der Zielversion von AEM kompatibel sind. Kompilieren Sie die Code-Basis neu mit der neuen Version von UberJar.

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

Uber Jars für AEM 6.5

Uber Jars für AEM 6.5 LTS

Für AEM 6.5 LTS gibt es wieder zwei Arten von Uber Jars:

Hauptunterschied: AEM 6.5 vs. AEM 6.5 LTS Uber Jars

Maven-Koordinaten für veraltete APIs in Jar

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

Hinweise für Entwickler developer-notes

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-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.