Aggiornamento di codice e personalizzazioni upgrading-code-and-customizations

Quando si pianifica un aggiornamento, è necessario esaminare e risolvere i seguenti aspetti di un'implementazione.

Panoramica overview

Prima di procedere con un aggiornamento è necessario disporre di una base di codice dell'applicazione stabile che sia stata testata accuratamente sulla versione di destinazione di AEM. Sulla base delle osservazioni fatte durante il test potrebbero esserci modi per ottimizzare il codice personalizzato. Ciò potrebbe includere il refactoring del codice per evitare l’attraversamento dell’archivio, l’indicizzazione personalizzata per ottimizzare la ricerca o l’uso di nodi non ordinati in JCR, tra gli altri.

Oltre all'opzione di aggiornamento della base di codice e delle personalizzazioni per l'utilizzo con la nuova versione di AEM, la versione 6.4 consente anche di gestire le personalizzazioni in modo più efficiente con la funzionalità Compatibilità con le versioni precedenti descritta in questa pagina.

Come indicato sopra e mostrato nel diagramma seguente, eseguire il Rilevatore pattern nel primo passaggio ti aiuterà a valutare la complessità complessiva dell’aggiornamento e se desideri eseguire in modalità di compatibilità o aggiornare le tue personalizzazioni per utilizzare tutte le nuove funzionalità di AEM 6.4. Vedi la Compatibilità con le versioni precedenti in AEM 6.4 per ulteriori dettagli.

Aggiornare la base di codice upgrade-code-base

Creare un ramo dedicato per il codice 6.4 nel controllo delle versioni create-a-dedicated-branch-for-6-4-code-in-version-control

Tutti i codici e le configurazioni necessari per l’implementazione AEM devono essere gestiti utilizzando una qualche forma di controllo della versione. È necessario creare un ramo dedicato nel controllo della versione per gestire tutte le modifiche necessarie per la base di codice nella versione di destinazione di AEM. In questo ramo verrà gestito il test iterativo della base di codice rispetto alla versione di destinazione di AEM e successive correzioni di bug.

Aggiorna la versione AEM Uber Jar update-the-aem-uber-jar-version

Il jar Uber AEM include tutte le API AEM come una singola dipendenza nel progetto Maven pom.xml. È sempre consigliabile includere il Jar Uber come una singola dipendenza invece di includere singole dipendenze API AEM. Quando si aggiorna la base di codice, la versione del Jar Uber deve essere modificata in modo da puntare alla versione di destinazione di AEM. Se il progetto è stato sviluppato su una versione di AEM precedente all’esistenza del JAR Uber, tutte le singole dipendenze API AEM devono essere rimosse e sostituite da un’unica inclusione del JAR Uber per la versione di destinazione di AEM. La base di codice deve quindi essere ricompilata rispetto alla nuova versione del JAR Uber. Eventuali API o metodi obsoleti devono essere aggiornati per essere compatibili con la versione di destinazione di AEM.

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

Utilizzo del risolutore risorse amministrative in fase di abbandono phase-out-use-of-administrative-resource-resolver

L'uso di una sessione amministrativa attraverso SlingRepository.loginAdministrative() e ResourceResolverFactory.getAdministrativeResourceResolver() era piuttosto diffuso nelle basi di codice prima del AEM 6.0. Questi metodi sono stati dichiarati obsoleti per motivi di sicurezza in quanto offrono un livello di accesso troppo ampio. Nelle versioni future di Sling questi metodi verranno rimossi. È vivamente consigliato effettuare il refactoring di qualsiasi codice per utilizzare invece gli utenti del servizio. Ulteriori informazioni su Utenti del servizio e come eliminare gradualmente le sessioni amministrative è disponibile qui.

Query e indici Oak queries-and-oak-indexes

Qualsiasi utilizzo delle query nella base di codice deve essere testato accuratamente nell’ambito dell’aggiornamento della base di codice. Per i clienti che eseguono l’aggiornamento da Jackrabbit 2 (versioni AEM precedenti alla 6.0), questo è particolarmente importante in quanto Oak non indicizza automaticamente il contenuto e potrebbe essere necessario creare indici personalizzati. Se si esegue l'aggiornamento da una versione di AEM 6.x, le definizioni predefinite dell'indice Oak potrebbero essere cambiate e potrebbero influenzare le query esistenti.

Sono disponibili diversi strumenti per l’analisi e l’analisi delle prestazioni delle query:

Authoring con interfaccia classica classic-ui-authoring

L’authoring con interfaccia classica è ancora disponibile in AEM 6.4 ma è obsoleto. Ulteriori informazioni sono disponibili qui. Se l’applicazione è attualmente in esecuzione nell’ambiente di authoring dell’interfaccia classica, si consiglia di effettuare l’aggiornamento a AEM 6.4 e continuare a utilizzare l’interfaccia classica. La migrazione all’interfaccia utente touch può quindi essere pianificata come progetto separato da completare in diversi cicli di sviluppo. Per utilizzare l’interfaccia classica in AEM 6.4 sono necessarie diverse configurazioni OSGi per eseguire il commit nella base di codice. Per ulteriori dettagli su come configurare questa funzionalità, consulta qui.

Allinea con la struttura dell’archivio 6.4 align-repository-structure

Per semplificare gli aggiornamenti e garantire che le configurazioni non vengano sovrascritte durante un aggiornamento, l’archivio viene ristrutturato in 6.4 per separare il contenuto dalla configurazione.

Pertanto, alcune impostazioni devono essere spostate per non risiedere più in /etc come in passato. Per esaminare l'intera serie di problemi di ristrutturazione dell'archivio che devono essere rivisti e accolti nell'aggiornamento al AEM 6.4, vedi Ristrutturazione dell’archivio in AEM 6.4.

Personalizzazioni AEM aem-customizations

È necessario identificare tutte le personalizzazioni dell’ambiente di authoring AEM nella versione sorgente di AEM. Una volta identificate, si consiglia di archiviare ogni personalizzazione nel controllo della versione o almeno eseguirne il backup come parte di un pacchetto di contenuti. Tutte le personalizzazioni devono essere distribuite e convalidate in un ambiente di controllo qualità o di staging che esegue la versione di destinazione di AEM prima di un aggiornamento della produzione.

Sovrapposizioni in generale overlays-in-general

È una pratica comune estendere AEM funzionalità predefinita sovrapponendo nodi e/o file sotto /libs con nodi aggiuntivi sotto /apps. Queste sovrapposizioni devono essere tracciate nel controllo della versione e testate rispetto alla versione di destinazione di AEM. Se un file (sia JS, JSP, HTL) è sovrapposto, si consiglia di lasciare un commento su quale funzionalità è stata aumentata per facilitare il test di regressione sulla versione di destinazione di AEM. Ulteriori informazioni sulle sovrapposizioni in generale sono disponibili qui. Di seguito sono riportate le istruzioni per specifiche sovrapposizioni di AEM.

Aggiornamento di Custom Search Forms upgrading-custom-search-forms

Per funzionare correttamente, i facet di ricerca personalizzati richiedono alcune regolazioni manuali dopo l’aggiornamento. Per ulteriori dettagli, consulta Aggiornamento di Custom Search Forms.

Personalizzazioni dell’interfaccia utente Assets assets-ui-customizations

Le istanze che dispongono di implementazioni personalizzate di Assets devono essere preparate per l’aggiornamento. Questo è necessario per garantire che tutto il contenuto personalizzato sia compatibile con la nuova struttura a nodi 6.4.

Per preparare le personalizzazioni all’interfaccia utente di Assets, effettua le seguenti operazioni:

Generazione degli ID risorsa per le risorse esistenti generating-asset-ids-for-existing-assets

Per generare gli ID risorsa per le risorse esistenti, aggiorna le risorse quando aggiorni l’istanza AEM per eseguire AEM 6.4. Questo è necessario per abilitare il Funzionalità Approfondimenti risorse. Per ulteriori dettagli, consulta Aggiunta di codice di incorporamento.

Per aggiornare le risorse, configura il pacchetto Associa ID risorsa nella console JMX. A seconda del numero di risorse presenti nell’archivio, migrateAllAssets può richiedere molto tempo. I nostri test interni stimano circa un'ora per 125mila asset su TarMK.

Se hai bisogno di ID risorsa per un sottoinsieme di tutte le risorse, utilizza migrateAssetsAtPath API.

Per tutti gli altri scopi, utilizza migrateAllAssets() API.

Personalizzazioni degli script di InDesign indesign-script-customizations

Adobe consiglia di inserire script personalizzati in /apps/settings/dam/indesign/scripts posizione. Sono disponibili ulteriori informazioni sulle personalizzazioni degli script di InDesign qui.

Ripristino delle configurazioni ContextHub recovering-contexthub-configurations

Le configurazioni di ContextHub vengono eseguite da un aggiornamento. È possibile trovare istruzioni su come recuperare le configurazioni esistenti di ContextHub qui.

Personalizzazioni dei flussi di lavoro workflow-customizations

È prassi comune aggiornare i flussi di lavoro di modifica predefiniti per aggiungere o rimuovere funzionalità non necessarie. Un flusso di lavoro comune personalizzato è il flusso di lavoro Aggiorna risorsa DAM . Tutti i flussi di lavoro necessari per un’implementazione personalizzata devono essere sottoposti a backup e archiviati nel controllo della versione, in quanto possono essere sovrascritti durante un aggiornamento.

Modelli modificabili editable-templates

La struttura dei modelli modificabili è stata modificata tra AEM 6.2 e 6.3. Se si esegue l'aggiornamento da 6.2 o versioni precedenti e se il contenuto del sito è generato utilizzando modelli modificabili, sarà necessario utilizzare la Strumento Pulizia nodi reattivi. Lo strumento deve essere eseguito dopo un aggiornamento per pulire il contenuto. Sarà necessario eseguirlo sia su livelli di authoring che di pubblicazione.

Modifiche all’implementazione del CUG cug-implementation-changes

L’implementazione dei gruppi di utenti chiusi è cambiata notevolmente per risolvere i limiti di prestazioni e scalabilità delle versioni precedenti di AEM. La versione precedente di CUG è stata dichiarata obsoleta nella versione 6.3 e la nuova implementazione è supportata solo nell’interfaccia utente touch. Se stai effettuando l’aggiornamento da 6.2 o versioni precedenti, puoi trovare le istruzioni per eseguire la migrazione alla nuova implementazione CUG qui.

Procedura di prova testing-procedure

È necessario preparare un piano di prova completo per gli aggiornamenti dei test. Prima di eseguire il test della base di codice e dell’applicazione aggiornata in ambienti inferiori, è necessario eseguire il test. Eventuali bug rilevati devono essere corretti in modo iterativo fino a quando la base del codice non è stabile, solo in questo caso gli ambienti di livello superiore devono essere aggiornati.

Verifica della procedura di aggiornamento testing-the-upgrade-procedure

La procedura di aggiornamento descritta qui deve essere testata sugli ambienti di sviluppo e controllo qualità come documentato nel manuale di esecuzione personalizzato (vedi Pianificazione dell'aggiornamento). La procedura di aggiornamento deve essere ripetuta fino a quando tutti i passaggi non sono documentati nel manuale di esecuzione dell'aggiornamento e il processo di aggiornamento non è scorrevole.

Aree di test di implementazione implementation-test-areas-

Di seguito sono elencate le aree critiche di qualsiasi implementazione AEM che devono essere coperte dal piano di test una volta che l’ambiente è stato aggiornato e la base di codice aggiornata è stata distribuita.

Piano di test dei documenti e risultati document-test-plan-and-results

Occorre creare un piano di test che copra le aree di test di attuazione sopra indicate. In molti casi sarà utile separare il piano di test dagli elenchi di attività Autore e Pubblica . Questo piano di test deve essere eseguito in ambienti di sviluppo, controllo qualità e stage prima di aggiornare gli ambienti di produzione. I risultati dei test e le metriche delle prestazioni devono essere acquisiti in ambienti inferiori per fornire un confronto durante l’aggiornamento degli ambienti Stage e Production.