Code en aanpassingen upgraden

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

Overzicht

  1. Patroondetector - Voer de patroondetector uit zoals beschreven in upgradeplanning en gedetailleerd beschreven in deze pagina om een patroondetectorrapport te krijgen dat meer details bevat over gebieden die moeten worden behandeld naast de niet-beschikbare API's/bundels in de doelversie van AEM. Het rapport Patroondetectie moet u een indicatie geven van eventuele incompatibiliteiten in uw code. Als er geen is, is de implementatie al compatibel met 6.4, dan kunt u er nog steeds voor kiezen om nieuwe ontwikkeling uit te voeren voor het gebruik van de 6.4-functionaliteit, maar u hebt deze niet nodig alleen voor het onderhoud van de compatibiliteit. Als er incompatibiliteiten worden gemeld, kunt u kiezen om a) op verenigbaarheidwijze in werking te stellen en uw ontwikkeling voor nieuwe 6.4 eigenschappen of verenigbaarheid uit te stellen, b) besluit om ontwikkeling na verbetering te doen, en zich aan stap 2 te bewegen. Zie Achterwaartse compatibiliteit in AEM 6.4 voor meer informatie.

  2. Ontwikkel de Basis van de Code voor 6.4 - creeer een specifieke tak of bewaarplaats voor de codebasis voor de versie van het Doel. Gebruik info van Compatibiliteit vóór upgrade om gebieden met code te plannen die moeten worden bijgewerkt.

  3. Compileer met 6.4 Uber jar - werk codebasis POMs aan punt aan 6.4 uber jar bij en compileer code tegen dit.

  4. Bijwerken AEM Aanpassingen - Eventuele aanpassingen of uitbreidingen die moeten worden AEM, moeten worden bijgewerkt/gevalideerd om in versie 6.4 te kunnen werken en aan de basis van de 6.4-code worden toegevoegd. Bevat UI Search Forms, Assets Customizations, alles wat gebruikmaakt van /mnt/overlay

  5. Implementeren in 6.4-omgeving - Een schoon exemplaar van AEM 6.4 (Auteur + Publiceren) moet worden gebruikt in een Dev/QA-omgeving. De bijgewerkte codebasis en een representatieve steekproef van inhoud (van huidige productie) zouden moeten worden opgesteld.

  6. QA-validatie en opgeloste problemen - QA moet de toepassing valideren op zowel auteur- als publicatieinstanties van 6.4. Alle gevonden fouten moeten worden gecorrigeerd en vastgelegd in de 6.4-codebasis. Herhaal indien nodig de Dev-Cycle totdat alle bugs zijn opgelost.

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 deze pagina wordt beschreven.

Zoals hierboven vermeld en getoond in het hieronder diagram, zal het runnen van Patroondetector in de eerste stap u helpen de algemene ingewikkeldheid van de verbetering beoordelen en of u op verenigbaarheidswijze wilt lopen of uw aanpassingen bijwerken om alle nieuwe AEM 6.4 eigenschappen te gebruiken. Raadpleeg de pagina Achterwaartse compatibiliteit in AEM 6.4 voor meer informatie.
screen_shot_2018-03-30at175257

De Basis van de Code bevorderen

Creeer een Specifieke Tak voor 6.4 Code in de Controle van de Versie

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 AEM Uber Jar-versie bijwerken

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

Het gebruik van een administratieve zitting door SlingRepository.loginAdministrative() en ResourceResolverFactory.getAdministrativeResourceResolver() was vrij overheersend in codebasen voorafgaand aan AEM 6.0. Deze methoden zijn om veiligheidsredenen afgekeurd, omdat ze te ruim zijn voor toegang. In toekomstige versies van Verkopen worden deze methoden verwijderd. Het wordt ten zeerste aangeraden om code te vervangen en in plaats daarvan servicegebruikers te gebruiken. Meer informatie over de Gebruikers van de Dienst en hoe te om administratieve zittingen uit te faseren kan hier worden gevonden.

Vragen en eikindexen

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

Klassieke UI-authoring is nog steeds beschikbaar in AEM 6.4, maar wordt afgekeurd. Meer informatie vindt u 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 details over hoe te om dit te vormen kunnen hier worden gevonden.

OPMERKING

Om u te helpen zich van klassieke UI bewegen en uit de recentste AEM technologieën voordeel halen, denk leveraging de AEM Moderniseringshulpmiddelen om uw migratie gemakkelijker te maken.

Uitlijnen met 6.4 Repository Structuur

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 montages worden bewogen om niet meer onder /etc te verblijven zoals in het verleden het geval was geweest. Zie Herstructurering van de opslagplaats in AEM 6.4 voor een overzicht van alle problemen met betrekking tot de herstructurering van de opslagplaats die in de bijgewerkte versie tot AEM 6.4 moeten worden beoordeeld en opgenomen.

Aanpassingen AEM

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

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 hier. Hieronder vindt u instructies voor specifieke AEM-overlays.

Forms voor aangepaste zoekopdrachten upgraden

Aangepaste zoekfactoren vereisen na de upgrade enkele handmatige aanpassingen om goed te kunnen functioneren. Zie Aangepast zoeken in Forms upgraden voor meer informatie.

UI-aanpassingen

OPMERKING

Deze procedure is alleen vereist voor upgrades vanaf versies ouder dan AEM 6.2.

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:

  1. Voor de instantie die moet worden bevorderd, open CRXDE Lite door naar https://server:port/crx/de/index.jsp te gaan

  2. Ga naar het volgende knooppunt:

    • /apps/dam/content
  3. Wijzig de naam van het inhoudsknooppunt in content_backup. U kunt dit doen door met de rechtermuisknop op het verkendervenster in de linkerkant van het venster te klikken en Naam wijzigen te kiezen.

  4. Als de naam van het knooppunt is gewijzigd, maakt u een nieuw knooppunt met de naam inhoud onder /apps/dam met de naam content en stelt u het knooppunttype in op sling:Folder.

  5. Verplaats alle onderliggende knooppunten van content_backup naar het nieuwe inhoudsknooppunt. U kunt dit doen door elke kindknoop in de exploratieruit met de rechtermuisknop aan te klikken en Beweging te selecteren.

  6. Verwijder het knooppunt content_backup.

  7. De bijgewerkte knopen onder /apps/dam met het correcte knooptype van sling:Folder zouden idealiter in versiecontrole moeten worden bewaard en met de codebasis of bij een minimum worden opgesteld gesteund als inhoudspakket.

Element-id's genereren voor bestaande elementen

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 eigenschap van Inzichten van Activa toe te laten. Zie Code insluiten toevoegen voor meer informatie.

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 repository kan migrateAllAssets lang duren. Onze interne tests schatten ruwweg een uur voor 125.000 activa op TarMK.

1487758945977

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

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

InDesign Script-aanpassingen

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

Het terugkrijgen van Configuraties ContextHub

De configuraties ContextHub worden uitgevoerd door een verbetering. De instructies op hoe te om bestaande configuraties terug te krijgen ContextHub kunnen hier worden gevonden.

Workflowaanpassingen

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

OPMERKING

Deze procedure is alleen vereist voor Sites-upgrades die Bewerkbare sjablonen uit AEM 6.2 gebruiken

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 het gereedschap Opruimen voor responsieve knooppunten gebruiken. Het hulpmiddel is bedoeld om na een verbetering in werking te stellen om inhoud schoon te maken. Deze moet zowel op Auteur- als op Publish-niveau worden uitgevoerd.

Wijzigingen in CUG-implementatie

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 kunnen de Instructies om aan de nieuwe implementatie van de KUG hier te migreren worden gevonden.

Testprocedure

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.

Upgradeprocedure testen

De verbeteringsprocedure zoals hier geschetst zou op Dev en milieu's QA zoals gedocumenteerd in uw aangepast loopboek (zie Planning van Uw Verbetering) moeten worden getest. De verbeteringsprocedure zou moeten worden herhaald tot alle stappen in het verbeteringsloopboek worden gedocumenteerd en het verbeteringsproces is vlot.

Testgebieden implementeren

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.

Functioneel testgebied Beschrijving
Gepubliceerde sites Testen van de AEM implementatie en bijbehorende code op de publicatielaag
door de verzender. Neem criteria op voor pagina-updates en
cachevalidatie.
Authoring Testen van de AEM implementatie en de bijbehorende code op de laag Auteur. Dit moet pagina, componentontwerp en dialoogvensters bevatten.
Integratie met Marketing Cloud-oplossingen Integraties met producten als Analytics, DTM en Target valideren.
Integratie met systemen van derden Integraties van derden moeten zowel op Auteur- als op Publish-niveau worden gevalideerd.
Verificatie, beveiliging en machtigingen Eventuele verificatiemechanismen zoals LDAP/SAML moeten worden gevalideerd.
Machtigingen en groepen moeten op zowel Auteur- als
Publishers worden getest.
Zoekopdrachten De indexen en de vragen van de douane zouden samen met vraagprestaties moeten worden getest.
UI-aanpassingen Extensies of aanpassingen van de AEM-gebruikersinterface in de ontwerpomgeving.
Workflows Aangepast en/of uit de vakworkflows en -functionaliteit.
Prestatietesten Het testen van de lading zou op zowel auteur als Publish rijen moeten worden uitgevoerd die real-world scenario's simuleren.

Testplan document en resultaten

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.

Op deze pagina