Code en aanpassingen bijwerken upgrading-code-and-customizations

Bij het plannen van een upgrade moeten de volgende onderdelen van een implementatie worden onderzocht en aangepakt.

Overzicht overview

Voordat u verdergaat met een upgrade, moet u beschikken over een stabiele basis voor toepassingscode die grondig is getest op basis van de doelversie van AEM. Op basis van opmerkingen die tijdens het testen zijn gemaakt, kunnen er manieren zijn om de aangepaste code te optimaliseren. Het kan bijvoorbeeld het vernieuwen van de code omvatten om te voorkomen dat de gegevensopslagruimte wordt doorgedraaid, aangepaste indexering om de zoekopdracht te optimaliseren of het gebruik van niet-geordende knooppunten in onder andere JCR.

Naast naar keuze het bevorderen van uw codebasis en aanpassingen om met de nieuwe AEM versie te werken, helpt 6.5 ook uw aanpassingen efficiënter met de Achterwaartse eigenschap van de Verenigbaarheid beheren zoals die op Achterwaartse Verenigbaarheid in AEM 6.5wordt beschreven.

Zoals hierboven vermeld en in het hieronder diagram getoond, die de Detector van het Patroonin de eerste stap in werking stellen kan u helpen de algemene ingewikkeldheid van de verbetering beoordelen. Het kan u ook helpen besluiten of u op verenigbaarheidswijze wilt lopen of uw aanpassingen bijwerken om alle nieuwe AEM 6.5 eigenschappen te gebruiken. Zie de Achterwaartse Verenigbaarheid in AEM 6.5pagina voor meer details.

De basiscode bijwerken upgrade-code-base

Een specifieke vertakking maken voor 6.5-code in Versiebeheer create-a-dedicated-branch-for-6.5-code-in-version-control

Alle code en configuraties die voor uw AEM implementatie worden vereist, moeten worden beheerd met een of andere vorm van versiecontrole. Een specifieke tak in versiecontrole zou voor het beheren van om het even welke veranderingen nodig voor de codebasis in de doelversie van AEM moeten worden gecreeerd. Het iteratieve testen van de codebasis tegen de doelversie van AEM en verdere insectenmoeilijke situaties wordt beheerd in deze tak.

De versie AEM Uber Jar bijwerken update-the-aem-uber-jar-version

De AEM Uber jar omvat alle AEM APIs als één enkele gebiedsdeel in uw Maven project pom.xml. Het is altijd aan te raden de Uber Jar op te nemen als één afhankelijkheid in plaats van individuele AEM API-afhankelijkheden op te nemen. Wanneer het bevorderen van de codebasis, verander de versie van Uber Jar om aan de doelversie van AEM te richten. Als uw project op een versie van AEM vóór het bestaan van Uber Jar werd ontwikkeld, verwijder alle individuele AEM API gebiedsdelen. Vervang deze door één invoeging van Uber Jar voor de doelversie van AEM. Compileer de codebasis opnieuw tegen de nieuwe versie van Uber Jar. Vervangen API's of methoden bijwerken zodat deze compatibel zijn met de doelversie van AEM.

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

Fase-out gebruik van de Administratieve Resolver van Middelen phase-out-use-of-administrative-resource-resolver

Het gebruik van een beheersessie tot en met SlingRepository.loginAdministrative() en ResourceResolverFactory.getAdministrativeResourceResolver() vond plaats in de codebasis vóór AEM 6.0. Deze methoden zijn om veiligheidsredenen afgekeurd, omdat ze te ruim zijn voor toegang. in toekomstige versies van het Verdelen, zullen deze methodes worden verwijderd. Het wordt ten zeerste aangeraden om code te vervangen en in plaats daarvan servicegebruikers te gebruiken. Voor informatie over de Gebruikers van de Dienst en hoe te om administratieve zittingen uit te faseren zie Gebruikers van de Dienst in Adobe Experience Manager (AEM).

Vragen en Oak-indexen queries-and-oak-indexes

Om het even welk gebruik van vragen in de codebasis moet grondig worden getest als deel van het bevorderen van de codebasis. Voor klanten die vanaf Jackrabbit 2 (versies van AEM ouder dan 6.0) een upgrade uitvoeren, is dit testen vooral belangrijk omdat Oak inhoud niet automatisch indexeert en er aangepaste indexen moeten worden gemaakt. Als de bevordering van een versie van AEM 6.x, uit de doosOak indexdefinities kan veranderd zijn en bestaande vragen kon beïnvloeden.

De volgende hulpmiddelen zijn beschikbaar voor het analyseren van en het inspecteren van vraagprestaties:

Klassieke UI Authoring classic-ui-authoring

Klassieke UI-authoring is nog steeds beschikbaar in AEM 6.5, maar wordt afgekeurd. Zie Vervangen en verwijderde eigenschappenvoor meer informatie. Als uw toepassing op het Klassieke UI auteursmilieu loopt, wordt het geadviseerd om aan AEM 6.5 te bevorderen en het gebruik van Klassieke UI voort te zetten. De migratie naar Touch UI kan dan als afzonderlijk project worden gepland om over verscheidene ontwikkelingscycli te voltooien. Om Klassieke UI in AEM 6.5 te gebruiken, moeten verscheidene configuraties OSGi aan de codebasis worden geëngageerd. Meer details op hoe te om de configuratie te doen kunnen onder worden gevonden toelatend Toegang tot Klassieke UI.

Uitlijnen met 6.5 Repository Structure align-repository-structure

Om upgrades eenvoudiger te maken en ervoor te zorgen dat configuraties niet tijdens een upgrade worden overschreven, wordt de opslagplaats in 6.4 geherstructureerd om inhoud van configuratie te scheiden.

Daarom moeten verschillende instellingen worden verplaatst, zodat deze niet langer onder /etc staan, zoals in het verleden het geval was. Om de volledige reeks problemen van de bewaarplaatsherstructurering te herzien die in bijgewerkt aan AEM 6.4 moeten worden herzien en worden behandeld, zie Herstructurering van de Bewaarplaats in AEM 6.4.

AEM aem-customizations

Alle aanpassingen aan de AEM ontwerpomgeving in de bronversie van AEM moeten worden geïdentificeerd. Nadat elke aanpassing is geïdentificeerd, wordt aanbevolen deze in versiebeheer op te slaan of er minimaal een back-up van te maken als onderdeel van een inhoudspakket. Alle aanpassingen moeten worden geïmplementeerd en gevalideerd in een QA- of Staging-omgeving waarin de doelversie van AEM wordt uitgevoerd vóór een productieupgrade.

Bedekkingen in het algemeen overlays-in-general

Het is gebruikelijk om AEM uit de boxfunctionaliteit uit te breiden door knooppunten en/of bestanden onder /libs te bedekken met extra knooppunten onder /apps. Deze overlays moeten worden bijgehouden in versiebeheer en worden getest op basis van de doelversie van AEM. Als een bestand (zoals JS, JSP, HTL) wordt overlapt, wordt u door de Adobe aangeraden een opmerking te achterlaten over de functionaliteit die is verbeterd om de regressietests in de doelversie van AEM te vereenvoudigen. Zie Bedekkingenvoor generische informatie. Hieronder vindt u instructies voor specifieke AEM-overlays.

Aangepast zoeken in Forms bijwerken upgrading-custom-search-forms

Aangepaste zoekfactoren vereisen enkele handmatige aanpassingen na de upgrade om correct te werken. Voor meer details, zie Bevorderend het Onderzoek van de Douane Forms.

Assets UI-aanpassingen assets-ui-customizations

Exemplaren die aangepaste Assets-implementaties hebben, moeten worden voorbereid voor de upgrade. Deze actie is noodzakelijk om ervoor te zorgen dat alle aangepaste inhoud compatibel is met de nieuwe 6.4 knooppuntenstructuur.

U kunt aanpassingen aan Assets UI voorbereiden door het volgende te doen:

Element-id's genereren voor bestaande Assets generating-asset-ids-for-existing-assets

Als u element-id's voor bestaande elementen wilt genereren, moet u de elementen upgraden wanneer u uw AEM-instantie upgradet naar AEM 6.5. Deze stap wordt vereist om de eigenschap van de Inzichten van Assetstoe te laten. Voor meer details, zie inbedden codetoevoegen.

Als u elementen wilt bijwerken, configureert u het pakket Id's van bijbehorende elementen in de JMX-console. Afhankelijk van het aantal elementen in de gegevensopslagruimte kan migrateAllAssets lang duren. De interne tests van de Adobe schatten ongeveer een uur voor 125000 activa op TarMK.

Gebruik de API migrateAssetsAtPath als u id's van elementen nodig hebt voor een subset van uw gehele elementen.

Voor alle andere doeleinden gebruikt u de migrateAllAssets() API.

Scriptaanpassingen InDesign indesign-script-customizations

Adobe raadt u aan aangepaste scripts op /apps/settings/dam/indesign/scripts -locatie te plaatsen. Meer informatie over de aanpassingen van het Manuscript van het InDesign kan onder worden gevonden integreer Adobe Experience Manager Assets met Adobe InDesign Server.

ContextHub-configuraties herstellen recovering-contexthub-configurations

De configuraties van ContextHub worden beïnvloed door een verbetering. Zie het Vormen ContextHubvoor instructies op hoe te om bestaande configuraties terug te krijgen ContextHub.

Workflowaanpassingen workflow-customizations

Het is gebruikelijk om werkstromen uit het vak te bewerken om overbodige functionaliteit toe te voegen of te verwijderen. Een algemene workflow die wordt aangepast, is de DAM Update Asset -workflow. Van alle workflows die vereist zijn voor een aangepaste implementatie, moet een back-up worden gemaakt en worden opgeslagen in versiebeheer, aangezien deze tijdens een upgrade kunnen worden overschreven.

Bewerkbare sjablonen editable-templates

De structuur voor bewerkbare sjablonen is gewijzigd tussen AEM 6.2 en 6.3. Als u van 6.2 of vroeger bevordert, en als uw plaatsinhoud gebruikend editable malplaatjes wordt gebouwd, moet u het Responsieve Hulpmiddel van de Opruimen van Knoop gebruiken. Het hulpmiddel moet in werking stellen na een verbetering om inhoud op te schonen. Voer de bewerking uit op zowel Auteur- als Publish-lagen.

Wijzigingen in CUG-implementatie cug-implementation-changes

De implementatie van Gesloten Gebruikersgroepen is aanzienlijk gewijzigd om de beperkingen van prestaties en schaalbaarheid in eerdere versies van AEM aan te pakken. De vorige versie van CUG is afgekeurd in 6.3 en de nieuwe implementatie wordt alleen ondersteund in de aanraakinterface.

Testprocedure testing-procedure

Er moet een uitgebreid testplan worden opgesteld voor het testen van upgrades. Het testen van de geüpgrade codebasis en de toepassing moet eerst in lagere omgevingen worden uitgevoerd. Eventuele fouten moeten op iteratieve wijze worden gecorrigeerd totdat de basis van de code stabiel is. Dit geldt alleen als omgevingen op een hoger niveau worden bijgewerkt.

De upgradeprocedure testen testing-the-upgrade-procedure

De verbeteringsprocedure zoals die hier wordt geschetst zou op Dev en milieu's QA zoals die in uw aangepast in werking gesteld boek worden gedocumenteerd (zie plannend Uw Verbetering). De verbeteringsprocedure zou moeten worden herhaald tot alle stappen in het verbeteringsloopboek worden gedocumenteerd en het verbeteringsproces is vlot.

Testgebieden voor de implementatie implementation-test-areas-

Hieronder volgen enkele belangrijke gebieden van elke AEM implementatie die onder uw testplan moeten vallen zodra de omgeving is bijgewerkt en de geüpgrade codebasis is geïmplementeerd.

Testplan en resultaten document document-test-plan-and-results

Er moet een testplan worden opgesteld dat de bovengenoemde testgebieden voor de implementatie bestrijkt. Het is vaak zinvol om het testplan te scheiden van de taaklijsten van Auteur en Publish. Dit testplan zou op Dev, QA, en de milieu's van het Stadium moeten worden uitgevoerd alvorens de milieu's van de Productie te bevorderen. Testresultaten en prestatiemetriek moeten in lagere omgevingen worden vastgelegd om vergelijkingen te kunnen maken bij het upgraden van de Stage- en Production-omgeving.