Uppgraderar kod och anpassningar

När man planerar en uppgradering måste man undersöka och åtgärda följande områden i en implementering.

Översikt

  1. Mönsteravkännare - Kör mönsteravkännaren enligt beskrivningen i uppgraderingsplaneringen och beskrivs i detalj i den här sidan för att få en mönsteravkännarrapport som innehåller mer information om områden som behöver åtgärdas utöver de otillgängliga API:erna/paketen i målversionen av AEM. Rapporten Mönsteridentifiering bör ge dig en indikation på eventuella inkompatibiliteter i koden, om det inte finns någon sådan, så är din distribution redan 6.5-kompatibel, du kan fortfarande välja att göra ny utveckling för att använda 6.5-funktionalitet, men du behöver den inte bara för att bibehålla kompatibiliteten. Om inkompatibiliteter rapporteras kan du välja att antingen a) köra i kompatibilitetsläge och skjuta upp utvecklingen för nya 6.5-funktioner eller kompatibilitet, b) välja att göra utvecklingen efter uppgraderingen och gå vidare till steg 2. Mer information finns i Bakåtkompatibilitet i AEM 6.5.

  2. Utveckla kodbas för 6.5 ​- Skapa en dedikerad gren eller databas för kodbasen för Target-versionen. Använd information från Kompatibilitet före uppgradering för att planera områden med kod att uppdatera.

  3. Kompilera med 6.5 Uber jar ​- Uppdatera källkodens POM till 6.5 uber jar och kompilera koden mot detta.

  4. Uppdatera AEM Anpassningar* - *Alla anpassningar eller tillägg som ska AEM ska uppdateras/valideras för att fungera i 6.5 och läggas till i 6.5-kodbasen. Innehåller användargränssnittssökning i Forms, anpassning av resurser, allt som använder /mnt/overlay

  5. Distribuera till 6.5-miljö - En ren instans av AEM 6.5 (Författare + Publicera) 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.

  6. QA-validering och felkorrigering - QA ska validera programmet både i Author- och Publish-instanser av 6.5. Eventuella fel som hittas ska korrigeras och implementeras i 6.5-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 målversionen av AEM. Baserat på observationer som gjorts i testningen kan det finnas sätt att optimera den anpassade koden. Detta kan innefatta omfaktorisering av koden för att undvika att gå igenom databasen, anpassad indexering för att optimera sökningen eller användning av osorterade noder i JCR, bland annat.

Förutom möjligheten att uppgradera din kodbas och anpassa den till den nya AEM kan 6.5 också hjälpa dig att hantera dina anpassningar effektivare med funktionen Bakåtkompatibilitet som beskrivs på den här sidan.

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 den övergripande komplexiteten i uppgraderingen och om du vill köra i kompatibilitetsläge eller uppdatera dina anpassningar till alla nya AEM 6.5-funktioner. Mer information finns på sidan Bakåtkompatibilitet i AEM 6.5.
opt_cropped

Uppgradera kodbasen

Skapa en dedikerad gren för 6.5-kod i versionskontrollen

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

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 bör versionen av Uber Jar ändras till en målversion av AEM. Om ditt projekt utvecklades på en version av AEM innan Uber Jar fanns bör alla enskilda AEM API-beroenden tas bort och ersättas med en enda inkludering av Uber Jar för målversionen av AEM. Kodbasen ska sedan kompileras om mot den nya versionen av Uber Jar. Alla inaktuella API:er eller metoder bör uppdateras 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>

Använd den administrativa resurslösaren fasas ut

Användning av en administrativ session via SlingRepository.loginAdministrative() och ResourceResolverFactory.getAdministrativeResourceResolver() var mycket 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 hur du fasar ut administrativa sessioner finns här.

Frågor och ekindexvärden

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 detta särskilt viktigt eftersom Oak inte indexerar innehåll automatiskt och anpassade index kan behöva skapas. Om du uppgraderar från en AEM 6.x-version kan indexdefinitionerna för "out of the box Oak" ha ändrats och kan påverka befintliga frågor.

Det finns flera verktyg för analys och granskning av frågeprestanda:

Klassisk gränssnittsredigering

Klassisk gränssnittsredigering är fortfarande tillgängligt i AEM 6.5, men är nu föråldrat. Mer information finns här. Om ditt program körs i den klassiska gränssnittets redigeringsmiljö rekommenderar vi att du uppgraderar till AEM 6.5 och fortsätter använda det klassiska användargränssnittet. Migrering till Touch-gränssnittet kan sedan planeras som ett separat projekt som ska slutföras under flera utvecklingscykler. För att kunna använda det klassiska användargränssnittet i AEM 6.5 måste flera OSGi-konfigurationer implementeras i kodbasen. Mer information om hur du konfigurerar detta finns här.

Justera med 6.5-databasstruktur

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 ett antal inställningar flyttas så att de inte längre finns under /etc, vilket tidigare varit fallet. För att se över alla omstruktureringsproblem i databasen som måste granskas och anpassas i uppdateringen till AEM 6.4, se Repository-omstrukturering i AEM 6.4.

AEM

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 innan en produktionsuppgradering.

Övertäckningar i allmänhet

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 (oavsett om den är JS, JSP eller HTL) är överlagrad bör du lämna en kommentar om vilka funktioner som har förbättrats för enklare regressionstestning i målversionen av AEM. Mer information om övertäckningar finns i allmänhet här. Instruktioner för specifika AEM finns nedan.

Uppgraderar Forms för anpassad sökning

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

Användargränssnittsanpassningar för resurser

OBSERVERA

Den här proceduren krävs endast för uppgraderingar från versioner som är äldre än AEM 6.2.

Instanser som har anpassade Assets-distributioner måste förberedas för uppgraderingen. Detta krävs 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 resursgränssnittet genom att göra följande:

  1. Öppna CRXDE Lite på den instans som ska uppgraderas genom att gå till https://server:port/crx/de/index.jsp

  2. Gå till följande nod:

    • /apps/dam/content
  3. Byt namn på innehållsnoden till content_backup. Du kan göra detta genom att högerklicka på utforskarrutan till vänster i fönstret och välja Byt namn.

  4. När noden har bytt namn skapar du en ny nod med namnet /apps/dam under content och anger dess nodtyp till sling:Folder.

  5. Flytta alla underordnade noder för content_backup till den nya innehållsnoden. Du kan göra detta genom att högerklicka på varje underordnad nod i utforskarrutan och välja Flytta.

  6. Ta bort noden content_backup.

  7. De uppdaterade noderna under /apps/dam med rätt nodtyp sling:Folder bör helst sparas i versionskontrollen och distribueras med kodbasen eller åtminstone säkerhetskopieras som innehållspaket.

Genererar resurs-ID:n för befintliga resurser

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. Detta krävs för att aktivera funktionen Resursinsikter. 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 det ta lång tid att migrateAllAssets. Våra interna tester beräknar cirka en timme för 125 000 tillgångar på TjärMK.

1487758945977

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

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

Anpassa InDesign-skript

Adobe rekommenderar att du placerar egna skript på /apps/settings/dam/indesign/scripts plats. Mer information om anpassning av InDesign Script finns här.

Återställer ContextHub-konfigurationer

ContextHub-konfigurationer påverkas av en uppgradering. Instruktioner om hur du återställer befintliga ContextHub-konfigurationer finns här.

Anpassningar av arbetsflöden

Det är vanligt att uppdatera ändringar som görs direkt i arbetsflöden 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

OBSERVERA

Den här proceduren krävs endast för webbplatsuppgraderingar som använder Redigerbara mallar från AEM 6.2

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 ditt webbplatsinnehåll 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ållet. Den måste köras på både författarnivå och publiceringsnivå.

Ändringar av CUG-implementering

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. Om du uppgraderar från 6.2 eller tidigare finns instruktioner för att migrera till den nya CUG-implementeringen här.

Testprocedur

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ögre nivåmiljöer uppgraderas.

Testa uppgraderingsproceduren

Uppgraderingsproceduren som beskrivs här bör testas i Dev- och QA-miljöer så som den 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

Nedan visas viktiga delar av AEM implementering som ska ingå i testplanen när miljön har uppgraderats och den uppgraderade kodbasen har distribuerats.

Funktionellt testområde Beskrivning
Publicerade webbplatser Testa AEM implementering och associerad kod på publiceringsnivån
via dispatchern. Bör innehålla kriterier för siduppdatering och
cacheogiltigförklaring.
Redigering Testar AEM implementering och associerad kod på författarnivån. Bör innehålla sidor, komponentredigering och dialogrutor.
Integrering med Marketing Cloud Solutions Validera integreringar med produkter som Analytics, DTM och Target.
Integrering med system från tredje part Alla integreringar från tredje part ska valideras på både författarnivå och publiceringsnivå.
Autentisering, säkerhet och behörigheter Alla autentiseringsmekanismer som LDAP/SAML bör valideras.
Behörigheter och grupper ska testas både i författare och
publiceringsnivåer.
Frågor Anpassade index och frågor bör testas tillsammans med frågeprestanda.
Anpassningar av användargränssnitt Alla tillägg eller anpassningar av det AEM användargränssnittet i författarmiljön.
Arbetsflöden Anpassade arbetsflöden och funktioner och/eller inte.
Prestandatestning Belastningstestning bör utföras på både författarnivå och publiceringsnivå som simulerar verkliga scenarier.

Dokumenttestplan och resultat

En testplan bör skapas som omfattar de ovannämnda testområdena för implementering. I många fall är det bra att separera testplanen med uppgiftslistorna Skapat av och Publicera. Testplanen ska 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.

På denna sida