Aggiornamento del codice e delle personalizzazioni

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

Panoramica

  1. Rilevatore pattern : esegui il rilevatore pattern come descritto nella pianificazione dell’aggiornamento e descritto in dettaglio in questa pagina per ottenere un rapporto del rilevatore di pattern contenente ulteriori dettagli sulle aree da risolvere, oltre alle API/bundle non disponibili nella versione di Target di AEM. Il rapporto di 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.4, è comunque possibile scegliere di effettuare nuovi sviluppi per utilizzare la funzionalità 6.4, ma non è necessaria solo per mantenere la compatibilità. In caso di incompatibilità segnalate, puoi scegliere di a) eseguire in modalità compatibilità e differire lo sviluppo per le nuove funzioni 6.4 o compatibilità, b) decidere di eseguire lo sviluppo dopo l'aggiornamento e passare al passaggio 2. Per ulteriori informazioni, consulta la sezione relativa alla Compatibilità con le versioni precedenti nella AEM 6.4 .

  2. Sviluppa una base di codice per la versione 6.4 : crea un ramo o un archivio dedicato per la base di codice per la versione di Target. Utilizza le informazioni della compatibilità pre-aggiornamento per pianificare le aree di codice da aggiornare.

  3. Compila con 6.4 Uber jar - Aggiorna POM della base di codice per puntare al 6.4 uber jar e compila il codice su questo.

  4. Aggiorna personalizzazioni AEM - Eventuali personalizzazioni o estensioni da AEM devono essere aggiornate/convalidate per funzionare in 6.4 e aggiunte alla base di codice 6.4. Include Forms per la ricerca nell’interfaccia utente, Personalizzazioni risorse, qualsiasi cosa che utilizzi /mnt/overlay

  5. Implementare in ambiente 6.4 - Un'istanza pulita di AEM 6.4 (Autore + Pubblicazione) deve essere visibile in un ambiente di sviluppo/controllo qualità. È necessario distribuire una base di codice aggiornata e un campione rappresentativo di contenuto (proveniente dalla produzione corrente).

  6. Convalida del controllo qualità e correzione bug : il controllo qualità deve convalidare l’applicazione sia nelle istanze Author che Publish della versione 6.4. Eventuali bug trovati devono essere corretti e impegnati nella base di codice 6.4. Ripetere Dev-Cycle se necessario fino a quando tutti i bug non sono corretti.

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 funzione di compatibilità con le versioni precedenti come descritto in questa pagina.

Come indicato sopra e mostrato nel diagramma seguente, l'esecuzione del 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 funzioni di AEM 6.4. Per ulteriori informazioni, consulta la pagina Compatibilità con le versioni precedenti in AEM 6.4 .
screen_shot_2018-03-30at175257

Aggiorna la base codici

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

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

Il jar Uber AEM include tutte le API AEM come una singola dipendenza nel pom.xml del progetto Maven. È 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

L'utilizzo 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. Maggiori informazioni sugli utenti del servizio e come eliminare gradualmente le sessioni amministrative sono disponibili qui.

Query e indici Oak

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

L’authoring con interfaccia classica è ancora disponibile in AEM 6.4 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 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. Ulteriori dettagli su come configurare questo elemento sono disponibili qui.

NOTA

Per allontanarti dall’interfaccia classica e sfruttare le tecnologie AEM più recenti, considera l’opportunità di sfruttare gli AEM strumenti di modernizzazione per semplificare la migrazione.

Allinea alla struttura dell'archivio 6.4

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'intero insieme di problemi di ristrutturazione dell'archivio che devono essere rivisti e sistemati nell'aggiornamento alla AEM 6.4, vedi Ristrutturazione dell'archivio in AEM 6.4.

Personalizzazioni AEM

È 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

È 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 Forms di ricerca personalizzata

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

NOTA

Questa procedura è necessaria solo per gli aggiornamenti da versioni precedenti alla AEM 6.2.

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:

  1. Nell’istanza da aggiornare, apri CRXDE Lite da https://server:port/crx/de/index.jsp

  2. Vai al seguente nodo:

    • /apps/dam/content
  3. Rinomina il nodo di contenuto in content_backup. Per eseguire questa operazione, fai clic con il pulsante destro del mouse sul riquadro dell'esploratore sul lato sinistro della finestra e scegli Rinomina.

  4. Una volta rinominato il nodo, crea un nuovo nodo denominato content sotto /apps/dam denominato content e imposta il relativo tipo di nodo su sling:Folder.

  5. Sposta tutti i nodi figlio di content_backup nel nodo di contenuto appena creato. Per farlo, fai clic con il pulsante destro del mouse su ciascun nodo figlio nel riquadro Esplora risorse e seleziona Sposta.

  6. Elimina il nodo content_backup .

  7. I nodi aggiornati sotto /apps/dam con il tipo di nodo corretto sling:Folder devono 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 gli ID risorsa per le risorse esistenti, aggiorna le risorse quando aggiorni l’istanza di AEM per eseguire AEM 6.4. Questo è necessario per abilitare la 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 nell’archivio, migrateAllAssets potrebbe richiedere molto tempo. I nostri test interni stimano circa un'ora per 125mila asset su TarMK.

1487758945977

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

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

Personalizzazioni degli script InDesign

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

Ripristino delle configurazioni ContextHub

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

Personalizzazioni del flusso di lavoro

È 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

NOTA

Questa procedura è necessaria solo per gli aggiornamenti di Sites che utilizzano modelli modificabili dalla AEM 6.2

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 lo strumento Pulizia dei nodi reattivi. Lo strumento deve eseguire dopo un aggiornamento per pulire il contenuto. Sarà necessario eseguirlo sia su livelli di authoring che di pubblicazione.

Modifiche all'implementazione del 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 è 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

È 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

La procedura di aggiornamento descritta qui deve essere testata sugli ambienti di sviluppo e controllo qualità come documentato nel manuale di esecuzione personalizzato (consulta 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

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.

Area di test funzionale Descrizione
Siti pubblicati Verifica dell'implementazione AEM e del codice associato sul livello di pubblicazione
tramite il dispatcher. Deve includere i criteri per gli aggiornamenti di pagina e l’annullamento della validità della cache
.
Authoring Verifica dell’implementazione AEM e del codice associato sul livello di authoring. Deve includere la pagina, l’authoring dei componenti e le finestre di dialogo.
Integrazioni con le soluzioni Marketing Cloud Convalida delle integrazioni con prodotti come Analytics, DTM e Target.
Integrazioni con sistemi di terze parti Eventuali integrazioni di terze parti devono essere convalidate sia sui livelli Author che Publish .
Autenticazione, sicurezza e autorizzazioni Eventuali meccanismi di autenticazione come LDAP/SAML devono essere convalidati.
Le autorizzazioni e i gruppi devono essere testati sia su Author che
Publishtiers.
Query Gli indici e le query personalizzati devono essere testati insieme alle prestazioni delle query.
Personalizzazioni dell’interfaccia utente Eventuali estensioni o personalizzazioni dell’interfaccia utente AEM nell’ambiente di authoring.
Flussi di lavoro Workflow e funzionalità personalizzati e/o predefiniti.
Test delle prestazioni Il test del carico deve essere eseguito sia sui livelli Author che Publish, in modo da simulare scenari reali.

Piano di test dei documenti e risultati

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.

In questa pagina