Show Menu
ARGOMENTI×

Aggiornamento di codice e personalizzazioni

Durante la pianificazione e l'aggiornamento, è necessario esaminare e affrontare i seguenti aspetti di un'implementazione.

Panoramica

  1. Rilevatore pattern - Eseguite il Rilevatore di pattern come descritto nella pianificazione dell'aggiornamento e descritto in dettaglio in questa pagina per ottenere un report del rilevatore di pattern che contenga ulteriori dettagli sulle aree da risolvere, oltre alle API/ai bundle non disponibili nella versione di AEM di Target. Il rapporto Rilevamento pattern deve fornire un'indicazione di eventuali incompatibilità nel codice; se non ne sono presenti altre, la distribuzione è già compatibile con la versione 6.5, è comunque possibile scegliere di eseguire un nuovo sviluppo per utilizzare la funzionalità 6.5, ma non è necessario solo per mantenere la compatibilità. In caso di incompatibilità segnalata, è possibile scegliere a) Eseguire in modalità compatibilità e posticipare lo sviluppo per le nuove funzionalità 6.5 o compatibilità, b) decidere di eseguire lo sviluppo dopo l'aggiornamento e passare al passaggio 2. Per ulteriori informazioni, consultate Compatibilità con versioni precedenti in AEM 6.5 .
  2. Sviluppare la base codici per la versione 6.5 - Creare un ramo o un repository dedicato per la base codice per la versione di Target. Utilizzate le informazioni provenienti dalla compatibilità pre-aggiornamento per pianificare aree di codice da aggiornare.
  3. Compilare con 6.5 Uber jar - Aggiornare i POM della base di codice in modo che puntino a 6.5 uber jar e compilare il codice in base a questo.
  4. Aggiorna personalizzazioni AEM* - *Eventuali personalizzazioni o estensioni di AEM devono essere aggiornate/convalidate per funzionare in 6.5 e aggiunte alla base di codici 6.5. Include moduli di ricerca per l’interfaccia utente, Personalizzazioni risorse con /mnt/overlay
  5. Implementazione in ambiente 6.5 - Un'istanza pulita di AEM 6.5 (Autore + Pubblicazione) dovrebbe essere presente in un ambiente Dev/QA. È necessario aggiornare la base di codice e distribuire un campione rappresentativo di contenuti (provenienti dalla produzione corrente).
  6. Convalida della qualità e correzione dei bug - QA deve convalidare l'applicazione sia nelle istanze Author che Publish di 6.5. Eventuali bug rilevati devono essere corretti e impegnati nella base di codici 6.5. Ripetere Dev-Cycle secondo necessità fino a risolvere tutti i bug.
Prima di procedere con l’aggiornamento, è necessario disporre di una base di codice applicazione stabile che sia stata completamente testata rispetto alla 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 del repository, l'indicizzazione personalizzata per ottimizzare la ricerca o l'uso di nodi non ordinati in JCR, tra gli altri.
Oltre all'opzione di aggiornare la base di codice e le personalizzazioni per l'utilizzo con la nuova versione di AEM, la versione 6.5 consente anche di gestire le personalizzazioni in modo più efficiente con la funzione Compatibilità con le versioni precedenti, come descritto in questa pagina .
Come indicato in precedenza e illustrato nel diagramma di seguito, l'esecuzione del Rilevatore pattern nel primo passaggio consente di valutare la complessità generale dell'aggiornamento e se si desidera eseguire in modalità di compatibilità o aggiornare le personalizzazioni per utilizzare tutte le nuove funzioni di AEM 6.5. Per ulteriori informazioni, consultate la pagina Compatibilità con le versioni precedenti di AEM 6.5 .

Aggiorna la base codici

Crea un ramo dedicato per il codice 6.5 nel controllo delle versioni

Tutti i codici e le configurazioni richiesti per l’implementazione di AEM devono essere gestiti tramite un controllo delle versioni. Per gestire le modifiche necessarie per la base di codice nella versione di destinazione di AEM è necessario creare un ramo dedicato nel controllo delle versioni. In questo ramo verrà gestito il test iterativo della base di codice rispetto alla versione di destinazione di AEM e delle correzioni di bug successive.

Aggiornamento della versione AEM Uber Jar

AEM Uber Jar include tutte le API AEM come singola dipendenza nel progetto Maven pom.xml . È sempre consigliabile includere Uber Jar come singola dipendenza invece di includere singole dipendenze API AEM. Quando si aggiorna la base di codice, la versione di Uber Jar deve essere modificata in modo da puntare alla versione di destinazione di AEM. Se il progetto è stato sviluppato su una versione di AEM prima dell’esistenza di Uber Jar, tutte le singole dipendenze API di AEM devono essere rimosse e sostituite da un’unica inclusione dell’Uber Jar per la versione di destinazione di AEM. La base di codice deve quindi essere ricompilata con la nuova versione di Uber Jar. 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.5.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Eliminazione graduale dell'utilizzo di Administrative Resource Resolver

Prima di AEM 6.0, l’utilizzo di una sessione amministrativa SlingRepository.loginAdministrative() e ResourceResolverFactory.getAdministrativeResourceResolver() era piuttosto diffuso nelle basi di codice. Tali metodi sono stati dichiarati obsoleti per motivi di sicurezza, in quanto forniscono un livello di accesso troppo ampio. Nelle versioni future di Sling questi metodi verranno rimossi . Si consiglia vivamente di rigenerare il codice in modo da utilizzare gli utenti del servizio. Maggiori informazioni sugli utenti dei servizi e come eliminare gradualmente le sessioni amministrative sono disponibili qui .

Query e indici Oak

Qualsiasi utilizzo di query nella base di codici deve essere accuratamente testato nell'ambito dell'aggiornamento della base di codice. Per i clienti che effettuano l’aggiornamento da Jackrabbit 2 (versioni di 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 effettua l’aggiornamento da una versione di AEM 6.x, le definizioni dell’indice Oak potrebbero essere cambiate e avere effetti sulle query esistenti.
Sono disponibili diversi strumenti per l’analisi e l’analisi delle prestazioni delle query:

Classic UI Authoring

L’authoring con l’interfaccia classica è ancora disponibile in AEM 6.5 ma è diventato 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 ad AEM 6.5 e continuare a utilizzare l’interfaccia classica. La migrazione all'interfaccia utente touch può essere pianificata come progetto separato da completare in diversi cicli di sviluppo. Per utilizzare l’interfaccia classica in AEM 6.5, sono necessarie diverse configurazioni OSGi per il commit nella base di codice. Per ulteriori dettagli su come configurare questa funzione, consulta qui .

Allinea con struttura archivio 6.5

Per semplificare gli aggiornamenti e garantire che le configurazioni non vengano sovrascritte durante un aggiornamento, il repository viene ristrutturato in 6.4 per separare il contenuto dalla configurazione.
Pertanto, alcune impostazioni devono essere spostate per non risiedere più /etc come in passato. Per esaminare l’intera serie di problemi di ristrutturazione dell’archivio che devono essere esaminati e inseriti nell’aggiornamento ad AEM 6.4, consultate Ristrutturazione dell’ archivio in AEM 6.4 .

Personalizzazioni AEM

Tutte le personalizzazioni all’ambiente di authoring AEM nella versione sorgente di AEM devono essere identificate. Una volta identificati, si consiglia di memorizzare ciascuna personalizzazione nel controllo della versione o almeno di eseguire il backup come parte di un pacchetto di contenuti. Tutte le personalizzazioni devono essere distribuite e convalidate in un ambiente di controllo qualità o gestione temporanea che esegue la versione di destinazione di AEM prima di un aggiornamento della produzione.

Sovrapposizioni in generale

È pratica comune estendere AEM oltre la funzionalità box sovrapponendo nodi e/o file in /libs con nodi aggiuntivi in /apps. Queste sovrapposizioni devono essere tracciate nel controllo della versione e verificate in base alla versione di destinazione di AEM. Se un file (sia JS, JSP, HTL) è sovrapposto, si consiglia di lasciare un commento su quale funzionalità è stata incrementata per semplificare i 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 AEM.

Aggiornamento di moduli di ricerca personalizzati

I facet di ricerca personalizzati richiedono alcune regolazioni manuali dopo l'aggiornamento per funzionare correttamente. Per ulteriori dettagli, vedere Aggiornamento dei moduli di ricerca personalizzati.

Personalizzazioni interfaccia utente Risorse

Questa procedura è necessaria solo per gli aggiornamenti da versioni precedenti a AEM 6.2.
Le istanze che dispongono di distribuzioni di risorse personalizzate devono essere preparate per l’aggiornamento. Ciò è necessario per garantire che tutto il contenuto personalizzato sia compatibile con la nuova struttura di nodi 6.4.
Per preparare le personalizzazioni all’interfaccia utente delle risorse, effettua le seguenti operazioni:
  1. Nell’istanza che deve essere aggiornata, aprite CRXDE Lite accedendo a https://server:port/crx/de/index.jsp
  2. Vai al nodo seguente:
    • /apps/dam/content
  3. Rinominare il nodo di contenuto in content_backup . Per eseguire questa operazione, fare clic con il pulsante destro del mouse sul riquadro dell'elenco delle cartelle nella parte sinistra della finestra e scegliere Rinomina .
  4. Dopo aver rinominato il nodo, crea un nuovo nodo denominato content in /apps/dam named content e imposta il tipo di nodo su sling:Folder .
  5. Sposta tutti i nodi figlio di content_backup nel nodo di contenuto appena creato. A tale scopo, fare clic con il pulsante destro del mouse su ciascun nodo figlio nel riquadro di esplorazione e selezionare Sposta .
  6. Eliminate il nodo content_backup .
  7. I nodi aggiornati sotto /apps/dam con il tipo di nodo corretto di sling:Folder dovrebbero idealmente essere salvati nel controllo della versione e distribuiti con la base di codice o almeno sottoposti a backup come pacchetto di contenuto.

Generazione degli ID risorsa per le risorse esistenti

Per generare ID di risorse per le risorse esistenti, aggiornate le risorse quando aggiornate l’istanza di AEM per l’esecuzione di AEM 6.5. Questa funzione è necessaria per abilitare la funzione Risorse approfondite . Per ulteriori dettagli, consultate Aggiungere il codice da incorporare.
Per aggiornare le risorse, configura il pacchetto Associate Asset ID (ID risorsa associati) nella console JMX. A seconda del numero di risorse presenti nella directory archivio, migrateAllAssets potrebbe essere necessario molto tempo. I nostri test interni stimano circa un'ora per 125mila asset su TarMK.
Se avete bisogno di ID risorsa per un sottoinsieme di tutte le risorse, utilizzate l' migrateAssetsAtPath API.
Per tutti gli altri scopi, utilizzate l' migrateAllAssets() API.

Personalizzazioni di script InDesign

Adobe consiglia di inserire script personalizzati in /apps/settings/dam/indesign/scripts loco. Ulteriori informazioni sulle personalizzazioni degli script InDesign sono disponibili qui .

Ripristino delle configurazioni ContextHub

Le configurazioni ContextHub sono interessate da un aggiornamento. Le istruzioni su come recuperare le configurazioni ContextHub esistenti sono disponibili qui .

Personalizzazioni flusso di lavoro

È pratica comune aggiornare i flussi di lavoro di modifica 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 memorizzati nel controllo delle versioni, in quanto possono essere sovrascritti durante un aggiornamento.

Modelli modificabili

Questa procedura è necessaria solo per gli aggiornamenti di Siti che utilizzano Modelli modificabili da AEM 6.2
La struttura dei modelli modificabili è cambiata tra AEM 6.2 e 6.3. Se state effettuando l'aggiornamento dalla versione 6.2 o precedente e se il contenuto del sito è generato utilizzando modelli modificabili, dovrete utilizzare lo strumento Pulizia nodi reattivi. Lo strumento deve essere eseguito dopo un aggiornamento per ripulire il contenuto. Dovrà essere eseguito su livelli Autore e Pubblica.

Modifiche all’implementazione CUG

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 era obsoleta in 6.3 e la nuova implementazione era supportata solo nell’interfaccia touch. Se state effettuando l’aggiornamento dalla versione 6.2 o precedente, le istruzioni per effettuare la migrazione alla nuova implementazione CUG sono disponibili qui .

Procedura di prova

Dovrebbe essere preparato un piano di test completo per gli aggiornamenti di test. La verifica della base di codice aggiornata e dell’applicazione dovrà essere eseguita innanzitutto in ambienti più bassi. Eventuali bug rilevati devono essere corretti in modo iterativo fino a quando la base del codice non è stabile, solo allora gli ambienti di livello superiore dovrebbero essere aggiornati.

Verifica della procedura di aggiornamento

La procedura di aggiornamento come illustrato di seguito deve essere testata sugli ambienti Dev e QA come documentato nel manuale di esecuzione personalizzato (vedere 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 è uniforme.

Aree di test di implementazione

Di seguito sono riportate le aree critiche di qualsiasi implementazione di AEM che dovrebbe essere inclusa nel piano di test una volta che l’ambiente è stato aggiornato e la base di codice aggiornata è stata implementata.
Area di prova funzionale Descrizione
Siti pubblicati Verifica dell’implementazione di AEM e del codice associato sul livello di pubblicazione tramite il dispatcher. Deve includere criteri per gli aggiornamenti delle pagine e per l’annullamento della validità della cache.
Authoring Verifica dell’implementazione di AEM e del codice associato sul livello Autore. Deve includere finestre di dialogo e di authoring delle pagine e dei componenti.
Integrazioni con le soluzioni Marketing Cloud Convalida delle integrazioni con prodotti come Analytics, DTM e Target.
Integrazioni con i sistemi di terze parti Le eventuali integrazioni di terze parti devono essere convalidate sia sui livelli Autore che Pubblica.
Autenticazione, sicurezza e autorizzazioni Eventuali meccanismi di autenticazione come LDAP/SAML devono essere convalidati. Le autorizzazioni e i gruppi devono essere testati sia sui livelli Autore che Pubblica .
Query Gli indici e le query personalizzati devono essere testati insieme alle prestazioni delle query.
Personalizzazioni interfaccia utente Eventuali estensioni o personalizzazioni dell’interfaccia utente di AEM nell’ambiente di authoring.
Flussi di lavoro Flussi di lavoro e funzionalità personalizzati e/o non inclusi.
Test delle prestazioni Il test del carico deve essere eseguito sia sui livelli Autore che Pubblica per simulare scenari reali.

Piano di test del documento e risultati

Occorre creare un piano di prova che copra le aree di prova di attuazione sopra indicate. In molti casi sarà utile separare il piano di test dagli elenchi delle attività Autore e Pubblica. Questo piano di test deve essere eseguito negli ambienti Dev, QA e Stage prima di aggiornare gli ambienti Produzione. I risultati dei test e le metriche delle prestazioni devono essere acquisiti in ambienti inferiori per fornire un confronto quando si aggiornano gli ambienti Stage e Produzione.