Code en aanpassingen bijwerken upgrading-code-and-customizations

Bij de planning 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. Dit kan onder andere 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 optie om uw codebasis en aanpassingen te bevorderen om met de nieuwe AEM versie te werken, helpt 6.4 ook uw aanpassingen efficiënter beheren met de Achterwaartse eigenschap van de Verenigbaarheid zoals die op wordt beschreven deze pagina.

Zoals hierboven vermeld en in het onderstaande diagram wordt getoond, met behulp van de Patroondetector in de eerste stap kunt u de algemene complexiteit van de upgrade beoordelen en bepalen of u de upgrade wilt uitvoeren in de compatibiliteitsmodus of dat u de aanpassingen wilt bijwerken zodat alle nieuwe functies van AEM 6.4 worden gebruikt. Zie de Achterwaartse compatibiliteit in AEM 6.4 voor meer informatie.

De basiscode bijwerken upgrade-code-base

Creeer een Specifieke Tak voor 6.4 Code in de Controle van de Versie create-a-dedicated-branch-for-6-4-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 zullen in deze tak worden beheerd.

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 zou de versie van Uber Jar moeten worden veranderd om op de doelversie van AEM te richten. Als uw project op een versie van AEM vóór het bestaan van Uber Jar werd ontwikkeld zouden alle individuele AEM API gebiedsdelen moeten worden verwijderd en door één enkele opneming van Uber Jar voor de doelversie van AEM worden vervangen. De codebasis zou dan tegen de nieuwe versie van Uber Jar opnieuw moeten worden gecompileerd. Vervangen API's of methoden moeten worden bijgewerkt om compatibel te zijn met de doelversie van AEM.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.4.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() kwam voor AEM 6.0 vrij vaak voor in de codebasis. Deze methoden zijn om veiligheidsredenen afgekeurd, omdat ze te ruim zijn voor toegang. In toekomstige versies van Verdelen worden deze methoden 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 vooral belangrijk aangezien het Eak inhoud niet automatisch indexeert en de douaneindexen kunnen 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.

Er zijn verschillende gereedschappen beschikbaar voor het analyseren en inspecteren van queryprestaties:

Klassieke UI Authoring classic-ui-authoring

Klassieke UI-authoring is nog steeds beschikbaar in AEM 6.4, maar wordt afgekeurd. Meer informatie is beschikbaar op hier. Als uw toepassing momenteel op het Klassieke auteursmilieu van UI loopt, wordt het geadviseerd om aan AEM 6.4 te bevorderen en het gebruik van Klassieke UI voort te zetten. De migratie naar Touch UI kan dan als afzonderlijk project worden gepland dat over verscheidene ontwikkelingscycli wordt voltooid. Om Klassieke UI in AEM 6.4 te gebruiken zijn verscheidene configuraties OSGi nodig om aan de codebasis worden geëngageerd. Meer informatie over het configureren van dit bestand vindt u in hier.

Uitlijnen met 6.4 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 moet een aantal instellingen worden verplaatst om niet meer onder te kunnen wonen /etc zoals in het verleden het geval was geweest . Om de volledige reeks problemen met de reorganisatie van opslaglocaties te beoordelen die in de bijgewerkte versie tot AEM 6.4 moeten worden bekeken en opgenomen, raadpleegt u Herstructurering van de depositaris in AEM 6.4.

Aanpassingen 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 met de doelversie van AEM voorafgaand aan 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 (JS, JSP, HTL) wordt overschreven, wordt aanbevolen om een opmerking te laten over de functionaliteit die is uitgebreid voor het testen van de regressie op de doelversie van AEM. 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 na de upgrade enkele handmatige aanpassingen om goed te kunnen functioneren. Zie voor meer informatie Aangepast zoeken in Forms bijwerken.

UI-aanpassingen voor middelen assets-ui-customizations

Voor de upgrade moeten instanties worden voorbereid die aangepaste middelenimplementaties hebben. Dit is nodig om ervoor te zorgen dat alle aangepaste inhoud compatibel is met de nieuwe 6.4-knooppuntstructuur.

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 de AEM-instantie upgradet en AEM 6.4 uitvoert. Dit 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. Onze interne tests schatten ruwweg een uur voor 125.000 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.

InDesign Script-aanpassingen indesign-script-customizations

Adobe raadt u aan aangepaste scripts te plaatsen op /apps/settings/dam/indesign/scripts locatie. Meer informatie over InDesign Script-aanpassingen vindt u op hier.

ContextHub-configuraties herstellen recovering-contexthub-configurations

De configuraties ContextHub worden uitgevoerd 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 wijzigingen uit de vakworkflows bij te werken om niet-benodigde functionaliteit toe te voegen of te verwijderen. Een algemene workflow die wordt aangepast, is de workflow voor DAM Update Asset. 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 gereedschap is bedoeld om te worden uitgevoerd na een upgrade uitvoeren om de inhoud op te schonen. Deze moet zowel op Auteur- als op Publish-niveau worden uitgevoerd.

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 eerder bevordert, dan kan de Instructies om aan de nieuwe implementatie van de 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üpgraded codebasis en de toepassing zal eerst in lagere milieu's moeten worden gedaan. 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 vindt u een aantal belangrijke onderdelen van een AEM implementatie die onder uw testplan moeten vallen als 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. In veel gevallen is het zinvol om het testplan te scheiden van de taaklijsten Auteur en Publiceren. Dit testplan moet worden uitgevoerd in ontwikkelings-, QA- en Stage-omgevingen voordat de productieomgevingen worden bijgewerkt. Testresultaten en prestatiemetriek moeten in lagere omgevingen worden vastgelegd om vergelijkingen te kunnen maken bij het upgraden van de Stage- en Production-omgeving.