Uppgradera kod och anpassningar upgrading-code-and-customizations
När man planerar en uppgradering måste man undersöka och åtgärda följande områden i en implementering.
Ökning overview
- AEM Analyzer - Kör AEM Analyzer enligt beskrivningen i uppgraderingsplaneringen och beskrivs i detalj på sidan Utvärdera uppgraderingskomplexiteten med AEM Analyzer. Du får en AEM Analyzer-rapport som innehåller mer information om områden som måste åtgärdas utöver de otillgängliga API:erna/paketen i målversionen av AEM. AEM Analyzer-rapporten ger dig en indikation på eventuella inkompatibiliteter i koden. Om det inte finns någon är din distribution redan 6.5 LTS-kompatibel. Du kan fortfarande välja att skapa nya funktioner för 6.5 LTS, men du behöver dem inte bara för att bibehålla kompatibiliteten.
- Utveckla kodbas för 6.5 LTS- Skapa en dedikerad gren eller databas för kodbasen för målversionen. Använd information från Kompatibilitet före uppgradering för att planera områden med kod att uppdatera.
- Kompilera med 6.5 LTS Uber jar - Uppdatera kodbas-POM så att de pekar på 6,5 LTS uber jar och kompilera kod mot den.
- Distribuera till 6.5 LTS-miljö - en ren instans av AEM 6.5 LTS (författare + publicering) bör ställas upp i en Dev/QA-miljö. Uppdaterad kodbas och ett representativt urval av innehåll (från aktuell produktion) bör distribueras.
- QA-validering och felkorrigering - QA ska validera programmet både i Author- och Publish-instanser av 6.5 LTS. Eventuella buggar som hittas ska vara åtgärdade och implementerade i 6.5 LTS-kodbasen. Upprepa Dev-Cycle tills alla fel är åtgärdade.
Innan du fortsätter med en uppgradering bör du ha en stabil programkodbas som har testats noggrant mot AEM 6.5 LTS.
Uppgradera kodbasen upgrade-code-base
Skapa en dedikerad gren för 6.5 LTS-kod i versionskontrollen create-a-dedicated-branch-for-6.5-lts-code-in-version-control
All kod och alla konfigurationer som krävs för din AEM-implementering bör hanteras med någon form av versionskontroll. En dedikerad gren i versionskontrollen bör skapas för att hantera ändringar som behövs för kodbasen i målversionen av AEM. Interaktiv testning av kodbasen mot målversionen av AEM och efterföljande felkorrigeringar hanteras i den här grenen.
Uppdatera JAR-versionen av AEM Uber update-the-aem-uber-jar-version
AEM Uber jar innehåller alla AEM API:er som ett enda beroende i Maven-projektets pom.xml. Det är alltid en god vana att inkludera Uber Jar som ett enda beroende i stället för att inkludera enskilda AEM API-beroenden. När du uppgraderar kodbasen ska du ändra versionen av Uber Jar till att peka på 6.5 LTS-versionen av AEM. Uppdatera alla inaktuella API:er eller metoder så att de är kompatibla med målversionen av AEM. Kompilera om kodbasen mot den nya versionen av Uber Jar.
<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-jar-6.5.x.jar- Innehåller alla offentliga API:er för AEM 6.5.uber-jar-6.5.x-apis-with-deprecations.jar- Innehåller både publika API:er och inaktuella API:er från AEM 6.5.
Uber Jars för AEM 6.5 LTS
För AEM 6.5 LTS finns det ytterligare två typer av Uber Jars:
uber-jar-6.6.x-apis.jar- Innehåller alla publika API:er för AEM 6.5 LTS.uber-jar-6.6.x-deprecated-apis.jar- Inkluderar endast inaktuella API:er från AEM 6.5 LTS.
Viktig skillnad: AEM 6.5 vs. AEM 6.5 LTS Uber Jars
- Om både publika och inaktuella API:er behövs i AEM 6.5 kan du använda en enda behållare,
uber-jar-6.5.x-apis-with-deprecations.jar, ipom.xml-filen. - Om du behöver både publika och inaktuella API:er i AEM 6.5 LTS måste du inkludera två separata anrop,
uber-jar-6.6.x-apis.jarför publika API:er ochuber-jar-6.6.x-deprecated-apis.jarför inaktuella API:er.
Maven-koordinater för borttagna API:er Jar
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>uber-jar</artifactId>
<version>6.6.0</version>
<classifier>deprecated-apis</classifier>
<scope>provided</scope>
</dependency>
Utvecklaranteckningar developer-notes
- AEM 6.5 LTS innehåller inte Google guava-bibliotek som är körklart. Den version som krävs kan installeras enligt önskemål.
- Sling XSS-paket använder nu Java HTML Sanitizer-biblioteket, och metoden
XSSAPI#filterHTML()bör användas för att återge HTML-innehåll på ett säkert sätt och inte för att skicka data till andra API:er.
Testförfarande testing-procedure
En omfattande testplan bör utarbetas för testning av uppgraderingar. Testning av den uppgraderade kodbasen och programmet måste göras i lägre miljöer först. Alla buggar som hittas bör fixeras på ett iterativt sätt tills kodbasen är stabil, men endast då bör högnivåmiljöer uppgraderas.
Testa uppgraderingsproceduren testing-upgrade-procedure
Uppgraderingsproceduren som beskrivs här bör testas i Dev- och QA-miljöer så som de beskrivs i din anpassade körbok (se Planera din uppgradering). Uppgraderingsproceduren bör upprepas tills alla steg har dokumenterats i uppgraderingsboken och uppgraderingsprocessen är smidig.
Implementeringstestområden implementation-test-areas-
Nedan visas viktiga delar av alla AEM-implementeringar som ska ingå i testplanen när miljön har uppgraderats och den uppgraderade kodbasen har driftsatts.
Dokumenttestplan och resultat document-test-plan-and-results
En testplan bör skapas som omfattar de ovannämnda testområdena för implementering. Det är ofta klokt att separera testplanen med uppgiftslistorna Skapat av och Publicera. Testplanen bör köras i Dev-, QA- och Stage-miljöer innan du uppgraderar produktionsmiljöer. Testresultat och prestandamått bör samlas in i lägre miljöer för att ge en jämförelse när du uppgraderar scen- och produktionsmiljöer.