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 de optioneel upgrade van uw codebasis en aanpassingen om met de nieuwe AEM te werken, helpt 6.5 u ook om uw aanpassingen efficiënter te beheren met de functie Achterwaartse compatibiliteit, zoals beschreven op deze pagina.

Zoals hierboven vermeld en in het onderstaande diagram wordt getoond, wordt de Patroondetector in de eerste stap kunt u de algemene complexiteit van de upgrade 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 compatibiliteit in AEM 6.5 voor meer informatie.

De basiscode bijwerken upgrade-code-base

Creeer een Specifieke Tak voor Code 6.5 in de Controle van de Versie 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 enkel 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 administratieve zitting door SlingRepository.loginAdministrative() en ResourceResolverFactory.getAdministrativeResourceResolver() voorkwam 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 Sling, zullen deze methodes worden verwijderd. Het wordt ten zeerste aangeraden om code te vervangen en in plaats daarvan servicegebruikers te gebruiken. Meer informatie over servicegebruikers en hier vindt u hoe u de beheersessies kunt afbouwen.

Vragen en eikindexen 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 van Jackrabbit 2 (versies van AEM ouder dan 6.0) bevorderen, is dit het testen vooral belangrijk aangezien het Eak geen inhoud automatisch indexeert en de douaneindexen zouden moeten worden gecreeerd. Als de bevordering van een versie van AEM 6.x, uit de de indexdefinities van het Eak van de doos 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. Meer informatie is beschikbaar op hier. 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 over hoe te om de configuratie te doen kunnen worden gevonden hier.

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 om niet langer onder te kunnen wonen /etc zoals in het verleden het geval was geweest . Om de volledige reeks problemen met de reorganisatie van opslagplaatsen te beoordelen die in de bijgewerkte versie tot AEM 6.4 moeten worden herzien en aangepakt, zie Herstructurering van de depositaris 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. Meer informatie over overlays vindt u in het algemeen hier. 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. Zie voor meer informatie Aangepast zoeken in Forms bijwerken.

UI-aanpassingen voor middelen assets-ui-customizations

De instanties die aangepaste plaatsingen van Activa hebben moeten voor de verbetering worden voorbereid. Deze actie is noodzakelijk om ervoor te zorgen dat alle aangepaste inhoud compatibel is met de nieuwe 6.4 knooppuntenstructuur.

U kunt aanpassingen aan de UI van Activa voorbereiden door het volgende te doen:

Element-id's genereren voor bestaande elementen 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 is vereist om de Assets Insights, functie. Zie voor meer informatie Insluitcode toevoegen.

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

Als u id's van elementen nodig hebt voor een subset van uw gehele elementen, gebruikt u de opdracht migrateAssetsAtPath API.

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

Scriptaanpassingen InDesign indesign-script-customizations

Adobe raadt u aan aangepaste scripts in te voeren /apps/settings/dam/indesign/scripts locatie. Meer informatie over de aanpassingen van het Manuscript van het InDesign kan worden gevonden hier.

ContextHub-configuraties herstellen recovering-contexthub-configurations

De configuraties van ContextHub worden beïnvloed door een verbetering. Instructies op hoe te om bestaande configuraties terug te krijgen ContextHub kunnen worden gevonden hier.

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 een upgrade uitvoert vanaf 6.2 of eerder en als uw site-inhoud is samengesteld met bewerkbare sjablonen, moet u de opdracht Reactieknooppunten opruimen. Het programma moet worden uitgevoerd na een upgrade uitvoeren om de inhoud op te schonen. Voer deze uit op zowel Auteur- als Publish-niveaus.

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. Als u van 6.2 of vroeger bevordert, dan kunnen de instructies om aan de nieuwe implementatie van CUG te migreren vinden hier.

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 hier geschetst zou op Dev en milieu's QA zoals die in uw aangepast loopboek worden gedocumenteerd (zie Uw upgrade plannen). 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 Auteur en Publiceren. 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.