Aggiornamento del codice e delle personalizzazioni
Durante la pianificazione di un aggiornamento, è necessario esaminare e risolvere le seguenti aree di un’implementazione.
Panoramica
-
Rilevatore pattern - Eseguire il rilevatore pattern come descritto nella pianificazione dell'aggiornamento e descritto in dettaglio nella pagina Valutazione della complessità dell'aggiornamento con il rilevatore pattern. Ottieni un report del rilevatore pattern che contiene più dettagli sulle aree che devono essere trattate oltre alle API/bundle non disponibili nella versione Target dell’AEM. Il rapporto Pattern Detection (Rilevamento pattern) fornisce un’indicazione di eventuali incompatibilità nel codice. Se non ne esiste alcuna, la distribuzione è già compatibile con la versione 6.5. Puoi comunque scegliere di eseguire un nuovo sviluppo per l’utilizzo della funzionalità 6.5, ma non è necessario solo per mantenere la compatibilità. Se vengono segnalate incompatibilità, puoi scegliere di eseguire in modalità di compatibilità e posticipare lo sviluppo per le nuove funzioni 6.5 o per la compatibilità. In alternativa, puoi decidere di eseguire lo sviluppo dopo l’aggiornamento e passare al passaggio 2. Per ulteriori dettagli, vedere Compatibilità con le versioni precedenti in AEM 6.5.
-
Develop Code Base for 6.5 - Crea un ramo o archivio dedicato per la base di codice per la versione di Target. Utilizza le informazioni di Compatibilità pre-aggiornamento per pianificare le aree di codice da aggiornare.
-
Compilare con file jar 6.5 Uber - Aggiornare i POM della base di codice in modo che puntino al file jar 6.5 Uber e compilare il codice in base a esso.
-
Aggiorna personalizzazioni AEM* - *Tutte le personalizzazioni o estensioni dell'AEM devono essere aggiornate/convalidate per funzionare nella versione 6.5 e aggiunte alla base di codice della versione 6.5. Include UI Search Forms, Personalizzazioni Assets, qualsiasi cosa utilizzi /mnt/overlay
-
Implementa nell'ambiente 6.5 - Un'istanza pulita di AEM 6.5 (Author + Publish) deve trovarsi in un ambiente di sviluppo/controllo qualità. È necessario distribuire una base di codice aggiornata e un campione rappresentativo di contenuti (dalla produzione corrente).
-
Convalida QA e correzione bug - Il controllo qualità deve convalidare l'applicazione di 6.5 sia nell'istanza Author che in quella Publish. Eventuali bug rilevati devono essere corretti e inseriti nella base di codice 6.5. Ripeti Dev-Cycle secondo necessità fino a quando tutti i bug non vengono risolti.
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 Compatibilità con le versioni precedenti in AEM 6.5.
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
Creare un ramo dedicato per il codice 6.5 nel controllo della versione
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
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
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. Per informazioni sugli utenti del servizio e su come eliminare gradualmente le sessioni amministrative, vedere Utenti del servizio in Adobe Experience Manager (AEM).
Query e indici Oak
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
L’authoring dell’interfaccia classica è ancora disponibile in AEM 6.5 ma è ora obsoleto. Per ulteriori informazioni, vedere Funzioni obsolete e rimosse. 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 in Abilitazione dell'accesso all'interfaccia utente classica.
Allinea alla struttura dell’archivio 6.5
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
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
È 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. Consulta Sovrapposizioni per informazioni generiche. Le istruzioni per specifiche sovrapposizioni AEM sono riportate di seguito.
Aggiornamento del Forms di ricerca personalizzato
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
NOTALe 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:
-
Nell'istanza che viene aggiornata, apri CRXDE Lite da https://server:port/crx/de/index.jsp
-
Vai al seguente nodo:
/apps/dam/content
-
Rinomina il nodo di contenuto in content_backup facendo clic con il pulsante destro del mouse sul riquadro dell'elenco delle cartelle nella parte sinistra della finestra e scegliendo Rinomina.
-
Una volta rinominato il nodo, creare un nodo denominato content in
/apps/damdenominato content e impostarne il tipo su sling:Folder. -
Spostare tutti i nodi figlio di content_backup nel nodo di contenuto appena creato facendo clic con il pulsante destro del mouse su ogni nodo figlio nel riquadro dell'elenco delle cartelle e selezionando Sposta.
-
Elimina il nodo content_backup.
-
I nodi aggiornati al di sotto di
/apps/damcon il tipo di nodo corretto disling:Folderdovrebbero idealmente essere salvati nel controllo della versione e distribuiti con la base di codice o almeno con il backup come pacchetto di contenuto.
Generazione degli ID risorsa per Assets esistenti
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
L'Adobe consiglia di inserire script personalizzati nel percorso /apps/settings/dam/indesign/scripts. Ulteriori informazioni sulle personalizzazioni degli script InDesign sono disponibili in Integrare Adobe Experience Manager Assets con Adobe InDesign Server.
Ripristino configurazioni ContextHub
Un aggiornamento influisce sulle configurazioni ContextHub. Per istruzioni su come ripristinare le configurazioni ContextHub esistenti, consulta Configurazione di ContextHub.
Personalizzazioni flusso di lavoro
È 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
NOTALa 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
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.