Aggiornamento del codice e delle personalizzazioni upgrading-code-and-customizations

Durante la pianificazione di un aggiornamento, è necessario esaminare e risolvere le seguenti aree di un’implementazione.

Panoramica overview

Prima di procedere con un aggiornamento, è necessario disporre di una base di codice dell’applicazione stabile che sia stata accuratamente testata rispetto alla versione di destinazione dell’AEM. In base alle osservazioni effettuate nei test, ci potrebbero essere modi per ottimizzare il codice personalizzato. Ad esempio, potrebbe includere il refactoring del codice per evitare l’attraversamento dell’archivio, l’indicizzazione personalizzata per ottimizzare la ricerca o l’utilizzo di nodi non ordinati in JCR, tra gli altri.

Oltre ad aggiornare facoltativamente la base di codice e le personalizzazioni per lavorare con la nuova versione dell'AEM, 6.5 consente anche di gestire le personalizzazioni in modo più efficiente con la funzione di compatibilità con le versioni precedenti, come descritto in questa pagina.

Come accennato in precedenza e mostrato nel diagramma seguente, l'esecuzione del rilevatore pattern nel primo passaggio può essere utile per valutare la complessità complessiva dell'aggiornamento. Può anche aiutarti a decidere se desideri eseguire in modalità di compatibilità o aggiornare le personalizzazioni per utilizzare tutte le nuove funzioni di AEM 6.5. Per ulteriori dettagli, vedere la pagina Compatibilità con le versioni precedenti in AEM 6.5.

Aggiorna base codice upgrade-code-base

Creare un ramo dedicato per il codice 6.5 nel controllo della versione create-a-dedicated-branch-for-6.5-code-in-version-control

Tutto il codice e le configurazioni necessari per l’implementazione dell’AEM devono essere gestiti utilizzando una qualche forma di controllo della versione. È necessario creare un ramo dedicato nel controllo della versione per gestire eventuali modifiche necessarie per la base di codice nella versione di destinazione dell’AEM. In questo ramo vengono gestiti i test iterativi della base di codice rispetto alla versione di destinazione dell’AEM e le successive correzioni di bug.

Aggiornare la versione del file JAR Uber dell’AEM update-the-aem-uber-jar-version

Il file jar Uber dell’AEM include tutte le API AEM come una singola dipendenza in pom.xml del progetto Maven. È sempre consigliabile includere il file JAR di Uber come una singola dipendenza invece di includere singole dipendenze API dell’AEM. Quando si aggiorna la base di codice, modifica la versione del file JAR Uber in modo che punti alla versione di destinazione dell’AEM. Se il progetto è stato sviluppato su una versione dell’AEM prima dell’esistenza del file JAR Uber, rimuovi tutte le dipendenze API dell’AEM. Sostituiscili con una singola inclusione del JAR Uber per la versione di destinazione dell’AEM. Ricompila la base di codice rispetto alla nuova versione del file JAR Uber. Aggiorna eventuali API o metodi obsoleti in modo che siano compatibili con la versione di destinazione dell’AEM.

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

Eliminazione graduale dell'utilizzo di Risolutore risorse amministrative phase-out-use-of-administrative-resource-resolver

L'utilizzo di una sessione amministrativa tramite SlingRepository.loginAdministrative() e ResourceResolverFactory.getAdministrativeResourceResolver() era prevalente nelle basi di codice prima di AEM 6.0. Questi metodi sono stati dichiarati obsoleti per motivi di sicurezza in quanto concedono un livello di accesso troppo ampio. Nelle versioni future di Sling questi metodi verranno rimossi. Si consiglia vivamente di eseguire il refactoring del codice per utilizzare al suo posto gli utenti del servizio. Ulteriori informazioni sugli utenti dei servizi e su come eliminare gradualmente le sessioni amministrative sono disponibili qui.

Query e indici Oak queries-and-oak-indexes

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

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

Authoring con interfaccia classica classic-ui-authoring

L’authoring dell’interfaccia classica è ancora disponibile in AEM 6.5 ma è ora obsoleto. Ulteriori informazioni sono disponibili qui. Se l’applicazione è in esecuzione nell’ambiente di authoring dell’interfaccia classica, si consiglia di eseguire l’aggiornamento a AEM 6.5 e continuare a utilizzare tale interfaccia. 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.5, è necessario eseguire il commit di diverse configurazioni OSGi nella base di codice. Ulteriori dettagli su come eseguire la configurazione sono disponibili qui.

Allinea alla struttura dell’archivio 6.5 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 i contenuti dalla configurazione.

Pertanto, è necessario spostare diverse impostazioni per non risiedere più in /etc come in passato. Per esaminare l'insieme completo dei problemi di ristrutturazione dell'archivio che devono essere esaminati e risolti nell'aggiornamento a AEM 6.4, vedere Ristrutturazione dell'archivio nell'AEM 6.4.

Personalizzazioni AEM aem-customizations

Devono essere identificate tutte le personalizzazioni dell’ambiente di authoring AEM nella versione sorgente dell’AEM. Una volta identificate, si consiglia di archiviare ogni personalizzazione nel controllo della versione o almeno di 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 dell’AEM prima di un aggiornamento della produzione.

Sovrapposizioni in generale overlays-in-general

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

Aggiornamento del Forms di ricerca personalizzato upgrading-custom-search-forms

I facet di ricerca personalizzati richiedono alcune regolazioni manuali dopo l’aggiornamento per funzionare correttamente. Per ulteriori dettagli, vedere Aggiornamento di Forms per la ricerca personalizzata.

Personalizzazioni dell’interfaccia utente di Assets assets-ui-customizations

Le istanze con distribuzioni Assets personalizzate devono essere preparate per l’aggiornamento. Questa azione è necessaria per garantire che tutto il contenuto personalizzato sia compatibile con la nuova struttura a 6,4 nodi.

Puoi preparare le personalizzazioni per l’interfaccia utente di Assets effettuando le seguenti operazioni:

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

Per generare ID risorsa per le risorse esistenti, aggiorna le risorse quando aggiorni l’istanza AEM per eseguire AEM 6.5. Questo passaggio è necessario per abilitare la funzionalità Informazioni su Assets. Per ulteriori dettagli, vedere Aggiungi codice di incorporamento.

Per aggiornare le risorse, configura il pacchetto Associa ID risorse nella console JMX. A seconda del numero di risorse nell'archivio, migrateAllAssets potrebbe richiedere molto tempo. I test interni di Adobe stimano circa un’ora per 125000 risorse su TarMK.

Se hai bisogno degli ID risorsa per un sottoinsieme di tutte le risorse, usa l'API migrateAssetsAtPath.

Per tutti gli altri scopi, utilizzare l'API migrateAllAssets().

Personalizzazioni degli script InDesign indesign-script-customizations

L'Adobe consiglia di inserire script personalizzati nel percorso /apps/settings/dam/indesign/scripts. Ulteriori informazioni sulle personalizzazioni degli script InDesign sono disponibili qui.

Ripristino configurazioni ContextHub recovering-contexthub-configurations

Un aggiornamento influisce sulle configurazioni ContextHub. Le istruzioni su come ripristinare le configurazioni ContextHub esistenti sono disponibili qui.

Personalizzazioni flusso di lavoro workflow-customizations

È prassi comune modificare i flussi di lavoro preconfigurati per aggiungere o rimuovere funzionalità non necessarie. Un flusso di lavoro comune personalizzato è il flusso di lavoro Risorsa di aggiornamento DAM. Tutti i flussi di lavoro necessari per un’implementazione personalizzata devono essere sottoposti a backup e memorizzati nel controllo della versione, in quanto potrebbero essere sovrascritti durante un aggiornamento.

Modelli modificabili editable-templates

La struttura dei modelli modificabili è cambiata tra AEM 6.2 e 6.3. Se si esegue l'aggiornamento da 6.2 o versioni precedenti e il contenuto del sito viene creato utilizzando modelli modificabili, è necessario utilizzare lo strumento di pulizia dei nodi reattivi. Lo strumento deve eseguire dopo un aggiornamento per pulire il contenuto. Eseguirlo sia sul livello Author che su quello Publish.

Modifiche all’implementazione CUG cug-implementation-changes

L’implementazione di gruppi chiusi di utenti è cambiata in modo significativo per affrontare i limiti di prestazioni e scalabilità delle versioni precedenti dell’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 eseguendo l'aggiornamento da 6.2 o versioni precedenti, le istruzioni per la migrazione alla nuova implementazione CUG sono disponibili qui.

Procedura di prova testing-procedure

Per testare gli aggiornamenti è necessario preparare un piano di test completo. Il test della base di codice e dell’applicazione aggiornate deve essere eseguito prima in ambienti inferiori. Eventuali bug trovati devono essere corretti in modo iterativo fino a quando la base di codice non è stabile, solo in questo caso gli ambienti di livello superiore dovrebbero essere aggiornati.

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

La procedura di aggiornamento qui descritta deve essere testata in 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 registro di esecuzione dell'aggiornamento e il processo di aggiornamento non è graduale.

Aree di prova dell’implementazione implementation-test-areas-

Di seguito sono riportate le aree critiche di qualsiasi implementazione AEM che devono essere coperte dal piano di test dopo l’aggiornamento dell’ambiente e la distribuzione della base di codice aggiornata.

Documenta piano di test e risultati document-test-plan-and-results

È necessario creare un piano di test che copra le aree di test di implementazione di cui sopra. Spesso è utile separare il piano di test dagli elenchi delle attività Autore e Publish. Questo piano di test deve essere eseguito sugli ambienti di sviluppo, controllo qualità e staging prima dell’aggiornamento degli ambienti di produzione. I risultati dei test e le metriche delle prestazioni devono essere acquisiti in ambienti inferiori per fornire confronti durante l’aggiornamento degli ambienti di staging e produzione.