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

Innan du fortsätter med en uppgradering bör du ha en stabil programkodbas som har testats noggrant mot målversionen av AEM. Baserat på observationer från testningen kan det finnas sätt att optimera den anpassade koden. Det kan till exempel vara att omfaktorisera koden för att undvika att gå igenom databasen, anpassa indexeringen för att optimera sökningen eller använda osorterade noder i JCR, bland annat.

Förutom att du kan uppgradera din kodbas och anpassa den så att den fungerar med den nya AEM-versionen kan 6.5 även hantera dina anpassningar mer effektivt med funktionen Bakåtkompatibilitet som beskrivs i Bakåtkompatibilitet i AEM 6.5.

Som vi nämnt ovan och som visas i diagrammet nedan kan du genom att köra Mönsteravkännaren i det första steget utvärdera uppgraderingens totala komplexitet. Det kan också hjälpa dig att avgöra om du vill köra i kompatibilitetsläge eller uppdatera dina anpassningar så att de använder alla nya AEM 6.5-funktioner. Mer information finns på sidan Bakåtkompatibilitet i AEM 6.5.

Uppgradera kodbasen upgrade-code-base

Skapa en dedikerad gren för 6.5-kod i versionskontrollen create-a-dedicated-branch-for-6.5-code-in-version-control

All kod och alla konfigurationer som krävs för AEM ska 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 den AEM Uber Jar-versionen 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 ändrar du versionen av Uber Jar så att den pekar på målversionen av AEM. Om ditt projekt utvecklades på en version av AEM innan Uber Jar fanns, tar du bort alla enskilda AEM API-beroenden. Ersätt dem med en enda inkludering av Uber Jar för målversionen av AEM. Kompilera om kodbasen mot den nya versionen av Uber Jar. Uppdatera alla inaktuella API:er eller metoder så att de är kompatibla med målversionen av AEM.

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

Avveckla användningen av den administrativa resurslösaren phase-out-use-of-administrative-resource-resolver

Användning av en administrativ session via SlingRepository.loginAdministrative() och ResourceResolverFactory.getAdministrativeResourceResolver() var vanligt i kodbaser före AEM 6.0. Dessa metoder har tagits bort av säkerhetsskäl eftersom de ger för stor åtkomstnivå. I framtida versioner av Sling kommer dessa metoder att tas bort. Vi rekommenderar att du omfaktoriserar kod så att du kan använda tjänstanvändare i stället. Mer information om tjänstanvändare och om hur du fasar ut administrativa sessioner finns i Tjänstanvändare i Adobe Experience Manager (AEM).

Frågor och Oak Index queries-and-oak-indexes

All användning av frågor i kodbasen måste noggrant testas som en del av uppgraderingen av kodbasen. För kunder som uppgraderar från Jackrabbit 2 (versioner av AEM äldre än 6.0) är den här testningen särskilt viktig eftersom Oak inte indexerar innehåll automatiskt och anpassade index bör skapas. Om du uppgraderar från en AEM 6.x-version kan Oak indexdefinitioner ha ändrats utan att anges, vilket kan påverka befintliga frågor.

Följande verktyg är tillgängliga för att analysera och inspektera frågeprestanda:

Skapa klassiskt användargränssnitt classic-ui-authoring

Klassisk gränssnittsredigering är fortfarande tillgängligt i AEM 6.5, men är nu föråldrat. Mer information finns i Borttagna och borttagna funktioner. Om ditt program körs i den klassiska användargränssnittets redigeringsmiljö bör du uppgradera till AEM 6.5 och fortsätta använda det klassiska användargränssnittet. Migrering till Touch-gränssnittet kan sedan planeras som ett separat projekt som kan slutföras under flera utvecklingscykler. Om du vill använda det klassiska användargränssnittet i AEM 6.5 måste flera OSGi-konfigurationer implementeras i kodbasen. Mer information om hur du gör konfigurationen finns under Aktivera åtkomst till det klassiska gränssnittet.

Justera med 6.5-databasstruktur align-repository-structure

För att underlätta uppgraderingarna och säkerställa att konfigurationerna inte skrivs över under en uppgradering har databasen omstrukturerats i 6.4 för att skilja innehåll från konfiguration.

Därför måste flera inställningar flyttas så att de inte längre finns under /etc, vilket tidigare varit fallet. Om du vill granska alla omstruktureringsproblem i databasen som måste granskas och hanteras i den uppdaterade versionen till AEM 6.4, se Omstrukturering av databaser i AEM 6.4.

AEM aem-customizations

Alla anpassningar av AEM redigeringsmiljö i källversionen av AEM måste identifieras. När du har identifierat dem rekommenderar vi att du lagrar alla anpassningar i versionskontrollen eller åtminstone säkerhetskopierar dem som en del av ett innehållspaket. Alla anpassningar bör driftsättas och valideras i en QA- eller mellanlagringsmiljö som kör målversionen av AEM före en produktionsuppgradering.

Övertäckningar i allmänhet overlays-in-general

Det är vanligt att utöka AEM genom att lägga över noder och/eller filer under /libs med ytterligare noder under /apps. Dessa övertäckningar bör spåras i versionskontroll och testas mot målversionen av AEM. Om en fil (till exempel JS, JSP och HTL) överlappas rekommenderar Adobe att du lämnar en kommentar om vilken funktion som utökats för enklare regressionstestning i målversionen av AEM. Se Övertäckningar för allmän information. Instruktioner för specifika AEM finns nedan.

Uppgraderar Forms för anpassad sökning upgrading-custom-search-forms

Anpassade sökytor kräver vissa manuella justeringar efter uppgraderingen för att fungera korrekt. Mer information finns i Uppgradera Forms för anpassad sökning.

Assets gränssnittsanpassningar assets-ui-customizations

Instanser som har skräddarsydda Assets-driftsättningar måste förberedas för uppgraderingen. Den här åtgärden är nödvändig för att säkerställa att allt anpassat innehåll är kompatibelt med den nya 6.4-nodstrukturen.

Du kan förbereda anpassningar av användargränssnittet i Assets genom att göra följande:

Genererar resurs-ID:n för befintlig Assets generating-asset-ids-for-existing-assets

Om du vill generera resurs-ID:n för befintliga resurser ska du uppgradera resurserna när du uppgraderar din AEM så att AEM 6.5 körs. Det här steget krävs för att aktivera Assets Insights-funktionen. Mer information finns i Lägg till inbäddningskod.

Om du vill uppgradera resurser konfigurerar du paketet Associate Asset IDs i JMX-konsolen. Beroende på antalet resurser i databasen kan migrateAllAssets ta lång tid. Adobe interna tester beräknar ungefär en timme för 125000 resurser på tarMK.

Om du behöver resurs-ID:n för en delmängd av hela dina resurser använder du migrateAssetsAtPath-API:t.

Använd API:t migrateAllAssets() för alla andra syften.

Anpassa InDesign-skript indesign-script-customizations

Adobe rekommenderar att du skickar anpassade skript på /apps/settings/dam/indesign/scripts-platsen. Mer information om anpassning av InDesign Script finns under Integrera Adobe Experience Manager Assets med Adobe InDesign Server.

Återställer ContextHub-konfigurationer recovering-contexthub-configurations

ContextHub-konfigurationer påverkas av en uppgradering. Mer information om hur du återställer befintliga ContextHub-konfigurationer finns i Konfigurera ContextHub.

Anpassningar av arbetsflöden workflow-customizations

Det är vanligt att du redigerar direkt i arbetsflödet för att lägga till eller ta bort funktioner som inte behövs. Ett vanligt arbetsflöde som är anpassat är arbetsflödet DAM Update Asset. Alla arbetsflöden som krävs för en anpassad implementering bör säkerhetskopieras och lagras i versionskontroll eftersom de kan skrivas över under en uppgradering.

Redigerbara mallar editable-templates

Strukturen för redigerbara mallar har ändrats mellan AEM 6.2 och 6.3. Om du uppgraderar från 6.2 eller tidigare, och om webbplatsinnehållet byggs med redigerbara mallar, måste du använda rensningsverktyget för responsiva noder. Verktyget ska köras efter en uppgradering för att rensa upp innehåll. Kör på både författarnivå och Publish-nivå.

Ändringar av CUG-implementering cug-implementation-changes

Implementeringen av stängda användargrupper har ändrats avsevärt för att åtgärda prestandabegränsningar och skalbarhetsbegränsningar i tidigare versioner av AEM. Den tidigare versionen av CUG har tagits bort i 6.3 och den nya implementeringen stöds bara i Touch-gränssnittet.

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-the-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 AEM implementering som ska ingå i testplanen när miljön har uppgraderats och den uppgraderade kodbasen har distribuerats.

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 från författare och Publish. 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.